9.3 Integration System Users & Integration System Security Groups

Why integrations need their own accounts

An integration must authenticate. Running one under a named person's account is a governance failure on several axes at once: the integration breaks when that person leaves, the audit trail attributes machine activity to a human, and the account's permissions are almost certainly wider than the integration needs.

Workday's answer is the Integration System User (ISU) - a dedicated account that exists solely for an integration to run as.

Creating an Integration System User

Use the Create Integration System User task.

Password expiration is the classic outage. ISUs are subject to the tenant password policy unless excluded from expiration. An integration that has run for months and suddenly fails authentication has usually hit a password expiry, not a permissions change. Exclude ISU accounts from password expiration or track their renewal deliberately.

Integration System Security Groups

An ISU is an account; an Integration System Security Group (ISSG) is what carries the permissions. From the advanced security group types in section 3.3:

Two properties carry exam weight. Membership is manually assigned - nothing derives it, so you add the ISU to the ISSG by hand. And both variants exist - an ISSG is not automatically unconstrained, which is a common misconception. When an integration should only extract one region's workers, a constrained ISSG is the mechanism.

Get and Put: the integration permission model

Domain security policies express permissions in two registers, and this is where integration security most often goes wrong.

• Get - the integration-side read permission. An outbound integration needs Get on the domains securing the data it extracts.
• Put - the integration-side write permission. An inbound integration needs Put on the domains securing the data it creates or updates.

The misconfiguration to recognize instantly: an ISSG granted View and Modify instead of Get and Put. The account authenticates successfully and the integration fails with an access error, which sends administrators hunting for a password problem. Grant the integration register.

Configuring ISSG access

1. Create the ISU with Create Integration System User.
2. Create the ISSG with Create Security Group, choosing Integration System (Constrained) or (Unconstrained) according to whether the integration should be scoped to particular organizations.
3. Add the ISU to the ISSG. Membership is manually assigned, and membership changes do not require activation.
4. Add the ISSG to each domain security policy the integration needs, granting Get for reads and Put for writes.
5. Run Activate Pending Security Policy Changes. The policy edits are pending until you do.
6. Test by launching the integration, not by signing in as the ISU - which you cannot do anyway if Do Not Allow UI Sessions is set.

   ISU  ──manually assigned──►  ISSG  ──added to──►  Domain Security Policy
  (who the                    (what the             (Get for reads,
   integration                 permissions           Put for writes)
   runs as)                    attach to)                  │
                                                    ACTIVATE PENDING
                                                    SECURITY POLICY CHANGES

Step 5 is the single most common cause of a brand-new integration failing its first run. The ISU exists, the ISSG exists, the domains are granted - and none of it is live. Recall the rule from section 3.1: membership changes need no activation; policy changes always do.

Determining which domains an integration needs

An integration touches the same securable items a user would.

1. Identify the data the integration reads or writes.
2. For each field, data source, or task, run View Security for Securable Item to find the securing domains.
3. Grant the ISSG Get on read domains and Put on write domains.
4. Grant only what the integration actually uses.

For an integration built on Reporting as a Service, this reduces neatly: the ISSG needs access to the domains securing the report's data source and report fields - exactly the same list a human would need to run it, expressed as Get. That is why a RaaS integration failing on a field the file does not visibly contain has the same cause as the reporting error in section 8.4: a field used in a filter is still a securable item.

Least privilege in practice

• One ISU per integration. Shared service accounts make it impossible to tell which integration did what, and force every integration to carry the union of all their permissions.
• Constrained by default. Choose a constrained ISSG unless the integration genuinely needs tenant-wide reach.
• Get before Put. Most outbound integrations only need Get; there are a few occasions that require Put. Grant Put deliberately, not by default - adding a group to an existing row that already carries both Get and Put can give it more access than necessary, in which case add a new row configured as Get only.
• Review periodically. Integrations are decommissioned more often than their ISUs are disabled. Orphaned accounts with live credentials are a real risk.
• Set Do Not Allow UI Sessions on every ISU, so a leaked credential cannot be used to browse the tenant.