Each supplier onboarding and each subsequent change — bank account, legal representative, legal entity or expired documentation — follows a case-based workflow, with requirements set out up front, a reviewer for each one, the applicable authorization and an outcome recorded by the agreed system or authorized owner.
01 · The problem
Supplier onboarding is not a one-time event. Once a supplier is on the register, a certificate expires, the signing representative changes, another group company joins, a service condition is amended, or an instruction arrives to change the bank account. Each of those events opens work at the same time in procurement, in the team that maintains supplier master data, and in the functions that must review their own requirement.
The file gets pulled together from whatever is already in use: a Microsoft Excel form the supplier emails back, attachments dropped into Microsoft SharePoint under whatever name the uploader picked, and a side spreadsheet where someone tracks expiry dates. Each of those does a useful job on its own, and not one of them records which requirement was missing, who reviewed it, or under whose authority the change was posted.
The supplier ends up sending the same document twice, the buyer cannot tell whose review is holding things up, and the change gets posted because someone asked for it by email.
The risk is not the missing document. It is the change already sitting on the register that no one can account for: who reviewed it, who authorized it, and how its origin was verified.
02 · The solution
Every onboarding and every change runs as a case on a defined workflow: the request comes in, the requirements that apply by category and by legal entity are identified, each accountable function reviews its own, the supplier answers what was raised, the authorization that applies is signed, and the change is confirmed on the record.
That workflow builds on what the Operational Graph already holds about each supplier: the legal entities it trades with, the category that drives its requirements, the expiry date on each document, the master data owner and the related contracts where they exist. The same supplier can be approved for one legal entity and under review for another, and that difference is in plain view instead of living in someone’s memory. BPMflow orchestrates that workflow — requests, reviews, deadlines, authorizations and evidence — so the process runs off the graph rather than off a standalone form.
On an active relationship, the outcome can also be a restriction of scope, a temporary suspension or supplier deactivation. Each has its own authorizer and its own confirmation, returned by the system where the measure is recorded or by the authorized owner responsible for it, as agreed.
Supplier Service Desk for Shared Services is the supplier’s front door and handles its day-to-day queries; it is not where an onboarding or a master data change gets resolved. When a query turns out to be a missing requirement, the onboarding or change case is what carries it to a decision. Contract terms, validity dates and accountable owners come from Vendor, SLA & Contract Intelligence. And when an approved supplier is about to start work on sites or assets, the requirements for that intervention are coordinated in Contractors, Assets and Interventions.
03 · Capabilities
Onboardings and changes sit in one queue, with case type, legal entity, outstanding requirement, age and authorization all in plain view. Max answers questions about the file within the authorized context: which requirement is missing, what evidence is on record and who the next owner is.
Opens the case from a sourcing need, an expiry date coming up, an instruction from the supplier, or the periodic review of the relationship.
Builds the list of documents and checks that apply: what each legal entity asks for, what the supplier category adds, and what carries over from an earlier onboarding instead of being requested twice.
The supplier submits what it has been asked for and tracks its own case, with no access to other suppliers’ files or to the internal review.
Tax, legal, finance, risk and safety each review the requirement that falls to them and leave either a query or a sign-off, with author and timestamp.
A change of bank account, legal representative or invoicing entity triggers the verification the organization has defined, and the case stays pending until that verification returns a recorded result.
The authorization that applies is signed, and the case keeps the confirmation that the change is on the record — returned by the system of record for supplier master data or by the authorized owner, whichever was agreed for that event, with its date and its source.
04 · Roles
Opens the case and keeps it moving.
What they see
The onboardings and changes in their category, with the outstanding requirement, the legal entities affected and the date they have committed to.
What they do
Starts the case, sets out the need, works with the supplier and records the agreed outcome.
Maintains the supplier master record and its data quality.
What they see
The complete file, the requirements reviewed, the signed authorizations and the status of the record in each legal entity.
What they do
Checks that the file is complete, creates or updates the supplier record in the system of record, and brings the confirmation back to the case.
Reviews the requirement that falls to their function.
What they see
The cases waiting on their review, with the document provided, its validity and the supplier’s history.
What they do
Signs off on the requirement, asks for a specific correction, or states why the case cannot move forward.
Supplies what is missing and tracks its own case.
What they see
What is being asked, why, by when, and where its request stands — in its own case.
What they do
Completes the form, attaches current documentation, answers the query, and confirms the data the organization verifies through its own channel.
05 · Implementation
Implementation starts from the process as it runs today. The first workflow needs only its own context — one supplier category, the legal entities that use it and their requirements — and no master data cleanup project up front.
1 · Agree on the outcome
Which onboardings and which changes are in scope, what each legal entity and each category requires, which extra verification a sensitive data change triggers, who authorizes each type, and what counts as confirmation.
2 · Gather the context, connect the sources
Pulls the supplier’s current record, its legal entities and its document expiry dates from the system of record for supplier master data and from the procurement platform, and uses the organization’s document repository where that is the authorized source.
3 · Run it on live cases, then hand it over
The workflow is tested on onboardings and changes already in flight, including at least one sensitive data verification. Requirements, owners and deadlines are refined from what that shows, and day-to-day operation stays with the client team.
06 · Typical scenarios
Several legal entities with different requirements, one master record shared across countries, and procurement teams spread over sites: this is work that recurs throughout the year, not only when a new supplier arrives.
A supplier onboarding or change ends well when someone can show what was reviewed, who authorized it and where it was recorded. Starting from a single case type is the practical way in: a bank account change is a useful first case, because it requires a verification of its own.
Supplier Onboarding and Changes is an EAFlow cross-industry solution on the Operational Graph, supported by BPMflow’s automation capabilities. Supplier Service Desk for Shared Services handles the supplier’s queries, and Vendor, SLA & Contract Intelligence provides contractual context. The files and workflows described on this page are illustrative: the requirements, the verifications, the authorizers and whoever confirms the record are agreed with each organization.
