The account that reads and nothing else
Every extract runs as a service account, and that account’s security decides what leaves the tenant. Configured wrong, nothing fails: the pull succeeds, rows are quietly missing, and the warehouse is confidently incomplete.
◆ The silent omissionthe failure mode that makes this page necessary.
Workday security does not throw errors at readers who lack access. It filters. An integration account missing one domain policy, or excluded from one security group, receives the rows it is entitled to and no complaint about the rest. The job logs success. The counts are plausible. A population is simply absent.
Teams meet this failure late, usually when a reconciliation against payroll or finance comes up short, and the search for a pipeline bug ends at a permissions screen. The fix is boring and absolute: treat extraction security as part of the data contract, and verify completeness on every run rather than assuming it.
◆ The setup, least privilege throughoutan account that can read what the pipeline needs and do nothing else.
| Step | What to configure | Why it matters |
|---|---|---|
| The account | A dedicated integration system user per pipeline. No human login, no shared credentials, password never used interactively. | Blast radius and auditability. One pipeline, one identity, one revocation. |
| The group | An integration system security group holding that account alone, unconstrained only if the pipeline truly needs all populations. | Groups are where access is granted. A group per pipeline keeps grants legible. |
| The domains | Get access, read only, on exactly the domain policies covering extracted objects. No modify anywhere. | Each missing domain is a silent trim. Each surplus one is unnecessary exposure. |
| Authentication | Token-based authorization for the report and query endpoints. Retire basic passwords where the tenant allows. | Credentials that expire and scope beat credentials that neither expire nor scope. |
| Activation | Security policy changes take effect on activation, not on save. | The classic dry-run confusion: configured correctly, activated never, trimmed anyway. |
◆ Proving completenessthe control that turns silent trims into loud ones.
The control is one comparison. Inside the tenant, a trivial count the account can always see: how many active workers exist right now. In the warehouse, the same count on what actually landed. Equal means complete; unequal means trimmed, and the run says so before anyone reports from it.
-- the landing check: tenant count vs landed count, every run
SELECT t.pulled_at,
t.tenant_active_workers,
COUNT(w.worker_id) AS landed_workers,
t.tenant_active_workers - COUNT(w.worker_id) AS missing
FROM raw_worker w
CROSS JOIN raw_extract_control t
WHERE w.extract_batch = t.batch_id
GROUP BY 1, 2
HAVING t.tenant_active_workers <> COUNT(w.worker_id)
Zero rows back is the good news. Anything else halts the load with a number attached: how many are missing, which batch, pulled when. The same discipline that makes the payroll module tie to the ledger starts here, one hop earlier, at the door of the tenant.
- ISU
- Integration system user. The service account an extraction pipeline runs as.
- security group
- The container access is granted to. The account gets access through it.
- domain security policy
- Workday’s per-domain access rule deciding who reads what.
- least privilege
- Granting exactly the access needed and nothing beyond it.
- token authorization
- Authentication with expiring, scoped tokens instead of passwords.
- activation
- The step that makes saved security changes take effect.
- completeness check
- A count comparison proving an extract landed everything it should.
- control table
- A small table carrying each run’s expected totals for reconciliation.