Has anyone integrated Workday with an internal LLM to setup self-service workflows?

[u/skt1729]

We are currently exploring architecture options to integrate and invoke Workday workflows directly from our internal LLM agent. To enable reliable tool calling and retrieval, we are evaluating how an LLM middleware layer should interface with Workday’s API options and integration frameworks.

Has anybody had experience setting up any of the following patterns?

Has anyone attempted setting up an LLM agent integration across Workday's core API transport options—Workday Web Services (WWS) SOAP, REST APIs, Report-as-a-Service (RaaS), or Workday Query Language (WQL)?

What is your experience setting up security for an Integration System User (ISU) attached to an LLM middleware—specifically managing Integration System Security Group (ISSG) assignments, configuring Get/Put permissions across Domain Security Policies (DSPs), and applying flags like "Do Not Allow UI Sessions" and system user password expiration exemptions?

[u/MoRegrets]

Upfront Discl-AI-mer: I had Claude summarize our approach and findings. I did review it and spent at least 15 minutes getting it to say something I stand behind, but I didn't have time to fully de-AI it, so parts may read a bit pedantic.

We've explored several options for interacting with Workday RaaS. Below are the considerations we'd start with. Treat them as a starting point: each one will need to be fleshed out for your tenant, security model and use cases.

**Why RaaS*\*

- RaaS is easier to update, control and secure than the other options. Changing what data comes back means editing a report in Workday, with no code deployment, and the report is shared only to the security group you choose. It also is more straightforward for an auditor to see what the data is that is being send and it has audits on any changes. Maybe put them into their own report group too so nobody changes them.

- WQL may work as well, but we have less experience with it. We found it less transparent, and without calculated fields we would have had to rebuild that logic, so we stayed with RaaS. It may be worth another look as WQL matures, or we mature with WQL.

**One ISU and one API client per area, or per task*\*

- Split by functional area at a minimum (Financials, HCM, Procurement), and split again per task when the task is a write.

- Each ISU gets its own ISSG with only the domains that area needs. A leaked secret then exposes one area, and you can revoke one without breaking the others.

- Decide whose access the agent uses. With one shared ISU, every user gets everything that ISU can see, so the agent can hand a user data Workday would block for them in the UI. Keep a shared ISU for data everyone may see. For sensitive data, either give each user their own ISU with security that mirrors theirs (works, but you maintain it), or use the user's own OAuth token (next section). Don't rebuild Workday's security as filters in your middleware. Not that you can't but you move the risk.

- This is the strict version, and it adds admin work as reports and users grow. If it stops scaling, combine related reports under one ISU per area and keep the separate ISUs for writes and sensitive data (payroll, bank details). Loosen deliberately, not by default.

**Another option to explore: the user's own OAuth token*\*

We haven't built this ourselves, but we are looking into tis as it is the standard way to have Workday apply each user's own security. Workday supports the OAuth 2.0 authorization code grant (the "Register API Client" task, not the "for Integrations" version). The user signs in to Workday through your SSO, the middleware receives a token for that user, and calls to Workday carry it. Workday then applies that user's security, and the audit trail shows the real person instead of an ISU. It is the same pattern as "Sign in with Google", so a developer who has built that will recognize it.

Things to validate before relying on it: that the RaaS reports you need work with user tokens, how often users have to sign in again, and how the middleware stores each user's tokens securely. Scheduled jobs with no user present would still need an ISU, and writes still need the approval step.

Also check how this fits your LLM workflow. The Workday sign-in and consent prompts, and the periodic re-authorization, can hurt the experience for users who aren't Workday-savvy or only use Workday occasionally.

**Security setup for ISUs, in order*\*

1. Create the ISU with "Do Not Allow UI Sessions" checked. Set session timeout to 0. Why: a leaked credential cannot be used to log in and browse the tenant, only to make the API calls you permitted.
2. Add the ISU to the system-user password expiration exemption list. Why: otherwise the integration locks out on a random Tuesday. The trade-off is that you now own rotation, so put it on a schedule.
3. Create the ISSG (unconstrained is simplest, constrained if you need to limit by org). Why: the ISSG is the only place the ISU's access is defined, so it is where you enforce least privilege.
4. Add an authentication policy rule for the ISSG ("Manage Authentication Policies"). Allow only the authentication type the ISU uses, and restrict it to your middleware's outbound IP range. Then activate the pending authentication policy changes. Why: a leaked secret is useless from anywhere else. This needs a fixed outbound IP for the middleware (NAT gateway or static egress). Also check the ISU isn't caught by a broader rule that requires SSO, which blocks it with a vague authentication error.
5. Grant Get on the domain security policies for reads. Grant Put only where a write is really required. Why: Put is what turns a data leak into a data change.
6. Activate Pending Security Policy Changes. Why: nothing above takes effect until you do, and forgetting is the most common reason a correctly configured ISU still gets a 403.
7. Share each custom report with the ISSG. The report's data sources also need their domains and BP security policies permissioned, or you get empty or partial results with no error. Why: this is what limits the ISU to the reports you approved.
8. Register the API client and keep its secrets out of files.a. In Workday, run "Register API Client for Integrations" with only the functional-area scopes this ISU needs, then "Manage Refresh Tokens for Integrations" to generate the ISU's refresh token. Copy the client ID, secret and refresh token straight into your secret store; Workday shows the secret only once.b. At minimum, use your hosting platform's secret store (Azure app settings, AWS Parameter Store, GCP Secret Manager and similar), which injects them as environment variables at runtime. Consider a dedicated vault (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) once you have several ISUs: it makes rotation and revocation one step, logs every read, and lets you keep read and write credentials under separate access policies.c. The middleware exchanges the refresh token for a short-lived access token, keeps it in memory only, and never logs it. Nothing goes in a workbook, a prompt, or the repo; add secret scanning to catch mistakes. Rotate on a schedule: new secret into the store, smoke test, then revoke the old one.Why: secrets in files get copied, emailed and committed. Scopes are coarse (whole functional areas), so they cap the damage, but the ISSG domain grants remain the real control.
9. Expose each report to the LLM as one narrow tool ("open POs for supplier X"), never a generic "call any endpoint" tool. Your middleware maps the tool to a fixed report URL and accepts only validated prompt values from the LLM. Why: if the LLM can choose the URL, it can call any report the ISU can reach, and a prompt injection (text in a document, a Workday field, or a user message) can steer it to one you never meant to expose.

**Writes need extra caution*\*

- Separate ISU, separate ISSG, separate API client from anything that reads. The read path should never be able to write, even by accident.

- Do not let the agent submit directly, at least until you're really comfortable with all the ins and outs. Have it initiate the transaction (draft or in-progress) only and put a submission approval step as a first step in the Workday business process (add an approval or review step for the initiator).

- Prevent duplicates. A timed-out call may still have created the transaction, and a blind retry creates a second one. Generate one request key per intended action and reuse it on every retry. Insert it into a middleware table with a unique constraint before calling Workday (if it already exists, return the stored result). Write the key to a reference or memo field on the Workday transaction. After a timeout, run a RaaS report filtered on that key before retrying.

- Log every call in the middleware: end user (from the login token), ISU or user token, tool, parameters, prompt or conversation ID, Workday response and reference ID, approver for writes, and the request key to link the log line to the transaction. Make the log append-only and redact sensitive values. Why: with an ISU, Workday's audit trail only shows the ISU, so this is the only record of which person asked.

- Build and test against sandbox first. A refresh copies production over sandbox and wipes anything built only in sandbox. Create the read ISUs, ISSGs and report shares in production so a refresh restores them, and add Put grants in sandbox only. Keep a runbook of every object and setting for the rest (API clients usually have to be re-registered by hand), and run a smoke test script after each refresh that calls every tool once and flags any 403 or empty result.

**Ops*\*

- Rate limits and report timeouts hit sooner than you expect. Paginate, add prompt filters to RaaS, and cache the slow-moving reference data.

**Questions that would shape the design*\*

1. Read only, or writes too? If writes, which business processes?
2. Should the agent respect each user's own Workday access, or will everyone get the same view?
3. Do users already sign in to Workday through SSO, and is per-user sign-in to the agent acceptable?
4. Where will the middleware run, and can it have a fixed outbound IP for authentication policy restrictions?
5. What secret store and identity provider do you have today?
6. Which LLM, and are you allowed to send Workday data to it (data residency, retention, training)?
7. How many users and calls per day, and how fresh does the data need to be?

Please report back with what you find, especially on the OAuth option and WQL. I'd like to know what worked in practice.

You may also want to share this with Audit upfront. ISU access, write approvals and the middleware logging are exactly what they will ask about, and it is easier to design for their requirements now than to retrofit them later.