Domain catalogue Parties on Workday

Supplier on Workday

One record per vendor, with the legal entity, the sites that ship, the bank details that are verified and the terms that apply.

SOURCES, READ IN PLACEWorkdayHCM · financeASSEMBLED1 · standardise2 · match on the domain keys3 · survive field by field4 · place in the hierarchies5 · run the column and row rules6 · publish the golden viewGOLDEN SUPPLIERSupplierone id · every source key keptREAD BYGrids, pivots and drill-downswith the transactionsAPIs, SQL and agentsone policyWrite-back to the systemsacknowledged
The objects the domain reads in place on Workday, the assembly steps, and who reads the result. Writes go through web-service Put operations.
2
objects read in place from Workday
catalogue
6
attribute groups assembled
catalogue
4 days
to production-grade
estimate
1
write path, acknowledged and logged
catalogue
0
rows copied to start
product
What the domain reads

The Workday objects behind the golden record

Objects are read through Workday web services and RaaS reports; the rows stay in Workday.

ObjectRead fromFields the domain usesFreshness
SupplierGet_Suppliers (Resource Management)Supplier_ID · Supplier_Name · Tax_ID · Supplier_Categorylive through web services; reports on schedule
Supplier invoicesGet_Supplier_InvoicesSupplier_Reference · Total_Amount · Due_Datelive through web services; reports on schedule
The keys

How supplier records match, in this system's fields

VAT ID or tax numberDUNS or LEIIBAN (verified)legal name and country (fuzzy)address (standardised)portal user domain

The first object above carries the strong keys; the standardised attributes come from the same rows. A verified IBAN is a strong key; a name match with a different verified IBAN opens a review; the merge waits for a person.

What is written back

Through the interfaces Workday supports

Writes go through the Workday web services (Put operations) with the reference id; each call returns the id or the error, logged beside the change.

InterfaceUsed forResult
Put_Supplier with the golden id as Supplier_Reference_IDgolden values approved for write-back: identity; sites; bank and paymentthe id or error Workday returns, stored beside the change

Write-back is off per object until a test write succeeds, and approval rules can require a person per object. Reconciliation compares the source row with the golden value on a schedule.

Access and prerequisites

What is in place before the first build

Workday security groups are mapped to Lima policies once; personal data stays under the HR policy.

Register the objects2 objects from the connector catalogue; each shows its rows at once.
Nearby

This domain on other systems, and other domains on Workday

Supplier on

Other domains on Workday

Terms on this page

Remit-toThe address and bank account a payment goes to; a verified value wins survivorship.
ScreeningThe check of a legal entity against sanctions and watch lists, stored with its date.
Read in placeThe rows stay in Workday; Lima sends the filter and the columns and Workday returns the matching rows.
Questions

Does this domain copy data out of Workday?

The golden record reads the objects above in place. History the pivot needs at scale is landed in your lake by the Backbone, under the same keys, security and audit.

What does the Workday team need to do?

Grant the read access and the write interfaces listed above and agree the refresh method. Nothing is installed in Workday.

Can we start with reads only?

Yes. Write-back stays off per object until a test write succeeds; the golden view, the API and the pivots work from day one on reads.

See your first domain built on your data

Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.