Workday setup and credentials

What the app can and cannot do in Workday

The app cannot create anything inside Workday's security configuration. An administrator there grants the integration system user what each operation needs. What the app does is make that exact: for every business object switched on, it lists the securable item, the domain, the permission and the business process policy to touch, in the order the administrator runs them, and tests each operation afterwards without creating anything.

The integration user

Create an Integration System User (ISU) and put it in an Integration System Security Group. The group is what receives the grants; the user is what signs in. Exempt the user from password expiry so a scheduled extract does not stop one morning, and from session timeouts if your tenant enforces them for integrations.

Two Admin settings make the setup steps concrete: wd_security_group, the group that holds the integration user, so each step says which group to add, and wd_ui_url, the tenant's browser address, so the steps link straight to the report, the domain's permissions page, the business process policy editor and the activation task.

The steps, per operation

The moment a business object is switched on, its Setup tab opens a Workday setup panel. The Operation page shows the same panel for its object in any state, and Admin offers the whole guide as a download for the Workday administrator. For each part it lists numbered steps:

1. View Security for Securable Item with the operation's securable item. The report names the domain that secures it.
2. Edit Security Policy Permissions on that domain: add the integration group with the permission required, Get for an extract, Put for a submit, as the panel says.
3. For a submit, Edit Business Process Security Policy on the business process, adding the group to the initiating action.
4. Activate Pending Security Policy Changes.
5. Test from the app.

Every panel starts with two implementer-only rows, iLoad Web Services and Special OX Web Services; the rows after them are the domains to grant. Extracts are secured by a View sub-domain, such as Process: Journals - View or Process: Supplier Invoice - View, that the parent domain does not reach. Most submits are secured by their business process's initiating action alone, with no domain of their own. Where a live tenant has shown the exact domain or action the step says so; elsewhere it names the usual one and defers to the panel.

The grant for Workday's bulk import is listed as optional. Without it, batches go one record at a time; with it, large batches go through the import.

Test, without creating anything

Test beside an operation runs it once with the stored credentials. An extract asks for one record. A submit sends an empty request that Workday refuses only after it has checked authorization, so nothing is created and nothing is changed. The result is one of three words: authorized, not authorized, or error with the message. Not authorized names the operation to fix before anyone drops a file. The Operations page shows a business object as set up once every part has passed.

Make the grants in the sandbox tenant first and prove them with Test. Workday's Object Transporter carries security policy changes to production, and a tenant refresh copies them back, so the grants are made once.

Credentials

The app signs in to Workday with the secret bound at install. Two authentication methods are supported and the choice is a setting on Admin.

Basic, the default, uses the integration user's name and password. The secret holds them as JSON; the user name is stored bare and the app appends the tenant. Different web services may use different users.

{"default": {"username": "ISU_wdops", "password": "..."},
 "services": {"Human_Resources": {"username": "ISU_wdops_hcm", "password": "..."}}}

OAuth uses an API client registered in the tenant for integrations, with the web service scopes the operations need. The access token is fetched at first use, cached until a minute before it expires, and refreshed after a rejection.

{"oauth": {"client_id": "...", "client_secret": "...", "refresh_token": "..."}}

Keep the default user name and password beside oauth if large batches should go through Workday's bulk import. The import process signs in again as the integration user and no scope makes it accept a token; without those credentials, every batch goes one record at a time.

Rotating credentials

Replace the secret's value in Snowflake; the app reads it on the next call. Alter the secret rather than recreating it, so the reference the app holds and the grants on it survive. Admin's Connection tab runs the connection test against the new value.

Entitlements

Within the app, entitlements say which scopes, the companies or agencies named by the submit's scope field, a user may submit for and see. Admin lists who may submit for which scope; * means every one. With the entitlement source set to Workday roles, the heartbeat derives entitlements from role assignments in your tenant on a schedule, so a person who gains or loses a company in Workday gains or loses it here without anyone editing a list. That sync needs the Get Workers operation authorized with role data.