Supplier 360 Intake Design and Regional Steward Scoping
Helio Chemicals receives about 2,400 new supplier requests per year from 14 countries, submitted by procurement staff through email and spreadsheets. Legal entity names vary, such as 'Helio Logistics GmbH' versus 'Helio Logistics', and 30% of requests are duplicates. The company is implementing Supplier 360 and debating two designs: allow requesters to create Supplier records directly, or create a separate Supplier Request entity that is approved before promotion to Supplier. Three regional data steward teams cover EMEA, APAC, and Americas; a global admin handles cross-region cases. Procurement needs fast turnaround, with a target of two business days, but compliance requires approval evidence and audit. Regional stewards should only see and act on their region; requesters should see only their own requests.
1. Which entity and workflow design would you recommend: direct Supplier creation or a separate Supplier Request entity? Justify your choice.
Read the worked answer
Recommend a separate Supplier Request entity, or an equivalent intake object, that captures requester, country, legal name, tax ID, bank details, and supporting evidence, then promotes an approved request into the Supplier golden record. Direct creation in Supplier would let unapproved data enter the master and make it hard to distinguish pending from approved suppliers; it also weakens audit evidence. The request entity gives a clear state model: submitted, dedupe check, regional review, compliance approval, promoted, rejected. Use search-before-create at intake to show possible matches; if a likely match exists, attach the request to the existing supplier instead of creating a new one. Promotion should call the business entity service so the Supplier record is created with proper validation and lineage back to the request. Trade-off: two entities add configuration and integration work, but compliance and duplicate control justify it.
2. How would you configure roles, scoping, task assignment, and duplicate prevention at intake, and what would you test?
Read the worked answer
Use role-based access with record scoping by region. Regional stewards get edit and approve rights only for their region; the global admin gets cross-region rights and a queue for escalations. Requesters get create and read on their own requests only, not on Supplier. Task assignment should route by the request's country-to-region mapping, with a fallback queue for unmatched countries. Test with users in each region: confirm a steward cannot see another region's request by search, direct URL, or API. Also test task reassignment, delegation during absence, and the global admin's cross-region view. For intake, expose a search API on the request form and log whether the requester accepted a suggested match; measure duplicate rate before and after. Trade-off: strict scoping may slow cross-region cases, so define an escalation path rather than widening steward access.