Vendor Master Data Change Workflow

What happens if the independent verifier can't confirm the bank details with the vendor?

The request is routed to a rejected status specifically flagged as a verification failure, and the requester receives an email with the verifier's notes explaining why the change could not be confirmed. The verification result, method and notes are saved to the record's timeline, so there's a clear account of why the change didn't proceed. The request does not reach finance approval in this case.

Can this handle change types other than bank details, like address or payment terms?

Yes. The workflow checks the Change Type field on submission and routes anything other than bank detail changes directly to finance approval, skipping the independent verification step. Address, contact detail, payment terms and other change types all follow the same acknowledgement, approval and completion path.

What if finance rejects the change after verification has already passed?

If the independent verifier confirms the bank details but finance still rejects the request, the workflow sets the status to a finance-specific rejected state and emails the requester to let them know finance did not approve the change. The verification result and finance's decision are both kept on the record's timeline, so the full sequence of events is visible.

Who is responsible for verifying bank detail changes and who approves the request?

An independent verifier is assigned to confirm the bank detail change directly with the vendor using contact details on file, separate from whoever submitted the request. Finance is then assigned to review and approve the change before any update, and finance is also assigned to make the actual update in the source system.

Can we customise which change types require verification or how approval works?

Yes, workflows can be adjusted by describing the change in plain English or editing the steps directly in the workflow editor, and earlier versions are kept. This means the routing logic, such as which change types trigger independent verification, can be adapted to match a workspace's own risk approach.

What does the requester actually see throughout the process?

The requester submits the request through a public form and receives an acknowledgement email with their reference number as soon as it's logged. Depending on the outcome, they then receive an email at rejection (with verifier notes if applicable) or at completion confirming the vendor record was updated — they never need an account to follow this.

What gets recorded once the vendor record is actually updated in the source system?

Finance is assigned a task to update the vendor record in the source system and record the date it was updated; because the workflow waits for this task, that date is saved to the record. The status then changes to Completed and the requester is emailed confirmation, giving a clear timeline of submission, approval and update dates on the record.

Is Supporting Evidence collected on the request form reviewed by anyone specific?

Supporting Evidence is captured on the initial request form alongside details like Current Value and New Value, and it stays on the record from submission. It's visible on the record's timeline for whoever handles verification or approval to reference, though each workspace decides how it factors that evidence into its own verification and approval decisions.

What if a business needs to keep this process compliant with internal audit requirements?

The workflow records each status change, the verification result and method entered by the verifier, the finance approval decision, and the date the vendor record was updated, all visible in the record's timeline. Each business should confirm with its own compliance or audit function whether this level of record-keeping meets its specific obligations.