Build vendor onboarding as two connected surfaces: a vendor-facing portal for requested information and an internal workflow for review, decisions, and system hand-offs. Vendors should not see internal notes or choose their approvers. Reviewers should not have to rekey every submission before they can assess it.
KasiLabs can create this tailored workflow from your rules and records, then let your team test it privately. It does not ship a ready-made supplier network, verification service, or procurement suite.
The short answer
A minimum useful vendor onboarding app needs eight record types:
- invitation and intended vendor category;
- vendor organisation and contacts;
- questionnaire version and answers;
- evidence item and its current status;
- internal review task and owner;
- decision, reason, actor, and time;
- approved downstream hand-off;
- later update, renewal, suspension, or closure.
That structure answers a question a shared folder cannot: which version of which evidence supported which decision?
If you are building an ongoing portal for agency or consultancy clients, use the client portal guide. Vendor onboarding has a different boundary: external registration, sensitive supplier information, internal risk and commercial review, and an authorised route into the supplier master or payment process.
Define the boundary before the form
Write down where onboarding starts and ends. A practical route might be:
invited → registration started → submitted → information requested → under review → approved or rejected → hand-off pending → active
Do not use “onboarded” as one vague status. Registration, qualification, approval, spend authorisation, payment setup, contract completion, and system access can be separate decisions.
Oracle's current supplier registration documentation makes that separation visible. A company can be reviewed as a prospective supplier before it is authorised for purchasing transactions, and external submissions go through collaborative review and duplicate checks. Oracle supplier registration process
Your first workflow contract should answer:
| Decision | What to define |
|---|---|
| Entry | Who may invite a vendor, and may vendors self-register? |
| Category | Which customer-defined vendor type controls the questions and reviewers? |
| Identity | Which organisation and contact fields are required? |
| Evidence | Which documents or attestations are needed, and when do they expire? |
| Sensitive data | Which fields need narrower access or a different collection method? |
| Review | Which teams assess commercial, operational, legal, security, or finance matters? |
| Return | Can a reviewer request more information without rejecting the vendor? |
| Decision | Who may approve, reject, suspend, or reopen? |
| Handoff | Which system or owner receives an approved record? |
| Change | What happens when the vendor later changes material information? |
The answers depend on vendor type, geography, risk, and your organisation's policy. Do not copy a universal checklist from a template.
Treat every submission as a version
A vendor may replace a certificate, change a legal name, add a bank account, or correct a questionnaire answer. If the latest file silently overwrites the old one, reviewers cannot show what they assessed.
Keep the current answer and its review status together. A material change should create a new review event for the affected fields, not make the whole vendor appear unreviewed or leave the old approval attached to new information.
SAP's supplier registration guidance lets reviewers compare updated questionnaire answers with previous versions and request more information. The useful principle is broader than SAP: preserve the submitted version and give the reviewer an explicit return loop. SAP questionnaire approval
Use distinct outcomes:
- Request information returns named questions or evidence while preserving the submission.
- Reject ends the current registration with a reason.
- Approve authorises only the next defined stage.
- Suspend blocks new activity while preserving the relationship record.
- Close ends access or the relationship through an owned process.
Keep external and internal permissions separate
The portal should expose only the vendor's own invitation, fields, requests, and status information that your policy permits. It should not reveal another vendor, internal comparison, the name of a reviewer when that should remain private, risk notes, or credentials for connected systems.
Internally, roles should remain narrow too. Procurement may validate company and category details. Security may see evidence relevant to access risk. Finance may handle payment setup. The requester may see progress without seeing restricted fields. No single “vendor admin” role should exist merely because it is convenient unless that breadth is intentionally approved.
OWASP recommends least privilege, default denial, and an authorization check on every request. A hidden field is not a permission boundary. Test whether a vendor can retrieve or change another vendor's record by altering a URL or request, and whether an internal reviewer can access categories outside their assignment. OWASP Authorization Cheat Sheet
Sensitive banking, tax, identity, or security information needs an explicit collection and storage decision. A generic file upload is not automatically an appropriate channel. KasiLabs does not perform bank verification, tax validation, sanctions screening, KYC, AML, or legal review by default. Verify any required service and connection for the specific implementation.
Route evidence by risk instead of asking everyone everything
A low-risk office supplier and a technology vendor with logical access may not need the same questionnaire. Start with customer-defined vendor categories and map each to evidence, reviewers, and review frequency.
CISA provides an SMB-oriented vendor assessment guide for ICT supply-chain risks. It organises practical questions around physical or logical access, cloud-hosted services, and managed service providers, with documented answers and evidence rather than a universal pass mark. Use guidance appropriate to the supplier and your jurisdiction; do not convert a security questionnaire into a universal onboarding form. CISA vendor assessment fact sheet
A useful route matrix might contain these columns:
| Vendor signal | Additional decision to define |
|---|---|
| Access to facilities or systems | Security/operations evidence and approval owner |
| Handling personal or confidential information | Privacy, contract, and access review |
| Payment-detail change | Independent verification route outside an email reply |
| Critical service dependency | Continuity evidence and escalation owner |
| New geography or legal entity | Customer-defined legal, tax, and commercial review |
These are prompts for your policy owner, not claims that every vendor needs every review.
Build the hand-off as its own controlled step
Approval does not mean the supplier record already exists in an accounting or procurement system. Keep the hand-off visible:
approved → queued for hand-off → accepted by destination → active
If the destination rejects the record, store the error in an operational queue without exposing credentials or sensitive payloads. Let an authorised person correct or retry the hand-off. Do not resend the entire onboarding route or create a duplicate vendor automatically.
If no verified integration exists, use an owned manual hand-off with a completion check. Honest manual work is safer than an assumed connection.
Test ten cases before release
Run these in the private working version:
- A normal invited vendor completes every required item.
- An expired or reused invitation is rejected.
- A likely duplicate is held for internal review.
- The reviewer requests one missing item and receives a new version.
- A vendor tries to open another vendor's record.
- An internal reviewer tries to access a restricted field.
- Payment details change after initial approval.
- The vendor withdraws before a decision.
- Approval succeeds but the downstream hand-off fails.
- A material update arrives after the vendor becomes active.
Include failure wording in the test. A vendor should know what to correct without seeing private review notes. An internal owner should know what needs action without receiving sensitive content in an ordinary notification.
In KasiLabs, you describe these records, roles, questions, transitions, and failure cases in plain language. The plan becomes a private working version. Selected vendors can be represented with synthetic test accounts, and internal users can test their real responsibilities. Owners choose access and paid-action limits, then an authorised reviewer approves the exact version that goes live. See the five-step process.
Choose a suite when the wider supplier lifecycle matters
Use the supplier module in your ERP or procurement suite when it already manages registration, qualification, spend authorisation, contracts, purchasing, payment setup, supplier performance, and the integrations your team needs. Adding a separate portal can create another unofficial supplier master.
A focused tailored workflow makes more sense when a stable onboarding process falls between existing systems and the organisation is prepared to own the questions, roles, sensitive-data boundary, and hand-offs. It is not a fit when the requirement depends on unverified screening, banking, tax, signature, identity, or ERP functions.
KasiLabs lets customers create software around this process; it does not deliver a preconfigured vendor-onboarding product. Review the current security and access position and the working-copy release boundary before exposing a portal to real vendors.
Describe one vendor category in KasiLabs. Map its invitation, evidence, return loop, decision, and hand-off, then keep it private until the duplicate, wrong-role, changed-data, and failed-handoff tests pass.