Onboarding a supplier without letting unchecked data into the master record
Onboarding is where bad data enters an organization. A supplier sends documents in whatever form suits them, several people check different things at different times, and the vendor record is often created before the checks finish. Modeled as one orchestrated process, nothing reaches the master record until the checks that policy requires have actually passed — and the record of who approved what survives the run.
A reference architecture: how RoboAgentix would model this process on UiPath. It is not a description of a delivered project, and no client, result or metric is implied.
What starts it
A supplier submits registration documents through a portal, a shared mailbox, or a procurement system.
Why it is orchestrated rather than scripted
- The process waits on people and on external registries, sometimes for days — a script would have to hold that state itself.
- The approval threshold changes with category and spend, and belongs in one editable rule rather than in several robots.
- An auditor will ask who approved this supplier and on what evidence, which means the trail has to outlive the run.
How it runs on UiPath Maestro
The process is defined in BPMN and Maestro runs it across agents, robots and people, holding its state for as long as the work takes — including while it waits on an approver.
Step by step
- 01
Submission receivedSystem
Registration documents and company details arrive from the portal or a monitored mailbox.
- 02
Read the submissionAgent
Trade license, tax registration, bank details and contact records are classified and extracted, each field carrying a confidence score.
- 03
Screen against policyAgent
The extracted entity is checked for duplicates in the vendor master, completeness against the category's requirements, and any list your policy obliges you to screen.
- 04
Clears policy?Maestro
The orchestrator routes on the screening result, the category, and the approval threshold that applies to it.
- 05
Procurement reviewPerson
Anything failing a check, or above the threshold, reaches a named approver with the findings and the source documents attached.
- 06
Create the vendor recordRobot
A robot writes the approved supplier into the ERP vendor master under its own least-privilege credentials.
- 07
Approved and recordedSystem
The supplier is active, and the decision, the evidence and the approver are written to the audit record.
What each agent is allowed to decide
An agent is only useful in a governed process if its authority is written down. Each one below has a defined input, a decision it may make on its own, and the condition that obliges it to hand over.
Intake Agent
Turns an unstructured submission into a structured supplier record.
Reads
- Submitted documents
- The category's required-document list
- Existing vendor master entries
Decides on its own
Must escalate when
Screening Agent
Checks the structured record against the policy that governs onboarding.
Reads
- Procurement policy, indexed for retrieval
- Vendor master for duplicates
- Registry and list checks your policy requires
Decides on its own
Must escalate when
What the robots do
Deterministic steps stay with robots — the same action every time, including in systems that never exposed a usable API.
Vendor master robot
Creates the supplier, its bank details and its payment terms in the system of record.
Runs in
Clears policy?
Every required check passed, no near-duplicate found, and the category's spend threshold not exceeded.
- Passes
- Straight to vendor creation.
- Does not pass
- Held for procurement review, with the process kept open until a decision comes back.
Modeled as a decision table, so the threshold can be changed by the people who own the policy without redeploying an automation.
The human step
Who
What they see
What they decide
People are in this process because judgment or authority belongs to them — not as a fallback for a step that failed.
What this design deliberately does not do
An automation is only trustworthy if its limits are written down as plainly as its capabilities.
- It does not adjudicate a screening hit. Where a name matches a list your policy obliges you to check, the agent attaches the hit and the source it came from; whether the match is the same entity is a person's call, recorded against the instance.
- It does not treat a submitted trade license or tax registration as verified because it was readable. Extraction establishes what the document says. Where policy requires the number to be confirmed at the issuing authority, that step stays with the person the policy names.
- It does not amend an existing supplier. Bank details, payment terms and legal name changes on a live vendor belong to a separate process with its own verification, and this design refuses instances that would use onboarding as the route to change a record that already exists.
- It does not judge commercial suitability. Whether the supplier is the right one to buy from — capacity, price, past performance — is the buyer's decision. The process only settles whether the record may exist and on what evidence.
Failure has a defined path
Systems go down, confidence drops, approvers go on leave. Each of these is a modeled branch rather than a stuck instance.
- A registry or list-check service the policy requires is unreachable, or returns an error rather than a result.
- The check is recorded as not obtained, which is not the same value as passed. The gate fails closed and the instance goes to the procurement approver, who sees which check is missing and decides whether to hold the submission until the service returns or proceed on the evidence in front of them. The reason is stored with the instance either way.
- A field comes back below its confidence threshold — an account number, a license expiry, a legal name that does not match the letterhead.
- That value is not carried forward. The instance routes to review with the document open at the page the value was read from, and the reviewer's corrected value is what the vendor master robot writes. The original extraction and the correction are both kept.
- The named approver does not act on the Action Center task.
- The task stays open and the process stays open with it. Reminders go out on the schedule the process defines, and after the interval the policy sets the task reassigns to the delegate or role queue named for that category. There is no approval on timeout and no silent close — an onboarding nobody decided remains an unclosed instance.
- The approval is given but the ERP rejects the write, or the vendor master is unavailable.
- The instance holds at that step and the write retries from its Orchestrator queue under the same credentials. The approval is not re-requested. The supplier is not reported as active until the ERP returns a vendor number, and a write that keeps failing surfaces as an operational exception rather than as a rejected supplier.
Data, rollout, and what to watch
Data it touches
- The submission carries identity and banking data — account and IBAN details, trade license and tax registration numbers, and named owners or signatories. Documents stay in the document store and the process instance in the region the environment is deployed to. The approver opens them from the task rather than being sent a copy, so review does not put the file in a mailbox.
- Bank details are the field most worth containing. The screening agent works on the identity and registration fields and is not given the account number, because nothing in the screening decision depends on it. In the approval task the account is masked unless the approver's role covers payment details, with the source document reachable for anyone who needs to check the digits.
- Agents have no standing access to the vendor master. The duplicate check is a scoped lookup that answers whether a close match exists and which record it is; it does not return the supplier base, and it does not return the bank details of the record it matched.
- Retention follows the record rather than the run. Submitted documents and the extraction behind them are kept as long as the vendor record they justify is kept. A rejected or abandoned submission is held for the shorter period your policy sets for applicants who were not onboarded, then removed with its instance.
How it goes live
- 01
Shadow
The process runs alongside the team on submissions they are already handling. Documents are read, checks run, and the gate is evaluated — but no task is raised and nothing is written to the vendor master. Each instance records what the process would have done, next to what procurement actually did. The phase ends when every disagreement is explained: not when there are none, but when each one traces to a requirement list, a threshold or an extraction model that can be corrected.
- 02
Supervised
Every instance reaches a procurement approver, including the ones that cleared every check, and the task shows what the gate would have decided on its own. Overrides at this stage are the evidence for the settings — per-field confidence, how close a near-duplicate has to be to hold, where each category's threshold sits. The gate out of this phase is per category, not for the process: unattended creation opens for one category whose required-document list and threshold have stopped moving.
- 03
Unattended with exceptions
Submissions that clear every check go straight to the vendor master robot; failed checks, near-duplicates and anything above threshold route to the approver as designed. Further categories are added one at a time through the same gate. Reverting a category to supervised stays available and is used deliberately — a new required document or a moved threshold puts that category back through supervised before it runs unattended again.
Signals worth watching
- The share of submissions held at the gate, split by which check held them. Movement concentrated in one check usually means the requirement list or a reference service changed, not that suppliers did.
- How often an approver dismisses a near-duplicate flag, read against how often a duplicate is found in the vendor master after the fact. The two move in opposite directions and together they say whether the matching is set too loose or too tight.
- Per-field extraction confidence for the fields the process depends on — account number, license number, expiry date — tracked by document layout. A supplier that changed its template shows up here before it shows up as a failed check.
- Vendor records edited by hand in the ERP soon after the robot created them, and which fields are being edited. That is where the process wrote something the team did not treat as final.
Named without target values. What good looks like depends on your volumes and your risk appetite, and is set with you rather than asserted here.
The UiPath components this design uses
UiPath Maestro
Runs the BPMN process and holds its state for as long as the work takes, including while it waits on a person or a system that is down.
UiPath Agent Builder
Where each agent is defined — its instructions, its tools, its inputs and outputs, and the escalation that sends work to a person.
UiPath Document Understanding
Classification and field extraction, returning a confidence score per field that the policy gate can route on.
Context Grounding
A retrieval index over your own policies and reference data, so an agent cites the rule it applied instead of recalling it.
UiPath Action Center
Where a human step actually lands. The approver gets a task with the agent's reasoning and sources attached, and the process resumes on their decision.
UiPath Orchestrator
Schedules the robots, holds queues and retries, and issues the least-privilege credentials each automation runs under.
UiPath Integration Service
Connectors to the systems of record, so the process talks to them through a maintained integration rather than a bespoke script.
Systems it touches
- ERP vendor master
- Procurement or supplier portal
- Document store
- Registry and list check services
What the run leaves behind
- Every document as submitted, and the values extracted from it
- Each check, its result, and the policy clause applied
- The approver, their decision, their reason and the time
- What the robot wrote to the vendor master, field by field
Other representative workflows
Talk to us about a process like this.
The most useful first conversation is about a real process — where it stalls, who approves what, and which systems it touches.