{ "schema": "aaes/capability-pack/1", "provider": "workday", "version": "1.1.0", "description": "Workday HCM: read worker records and supervisory organization structure. Draft package; provider endpoint verification and live tenant testing remain outstanding.", "notes": "Draft package. Two common/v1 collection reads remain registered: workers and supervisoryOrganizations. Workday's public REST Services Directory publishes the common v1 OpenAPI file, which on 2026-10-22 documented both as GET operations with limit (default 20, maximum 100) and offset paging. Neither read has been tested against a live tenant. Confirm each resource and version in the tenant's REST API Explorer before enabling; availability varies by tenant.\n\nReplace workday-datacenter.invalid with the reviewed tenant hostname in every endpoint, resource locator and network allowlist. Replace TENANT in the endpoint paths and resource locator before enabling. The tenant's View API Clients report supplies these values and the token endpoint, https://{host}/ccx/oauth2/{tenant}/token. The reserved .invalid host cannot resolve; provider rejection of a placeholder is not a substitute for reviewed setup.\n\nDocumentation review on 2026-10-22: the REST Services Directory page (community.workday.com/sites/default/files/file-hosting/restapi/index.html) is a JavaScript application, but the common v1 specification it loads, common_v1_20261003_oas2.json in the same directory, is publicly retrievable. It documents GET /workers (scope Staffing; secured by the FLW Service, Self-Service: Current Staffing Information and Worker Data: Public Worker Reports domains) and GET /supervisoryOrganizations (scope Organizations and Roles; secured by the FLW Service and Reports: Organization domains). The specification gives the host as and the base path as /api/common/v1. The 2026-10-29 review retrieved the Workers reference through web search: it gives the traditional tenant base as https:///api/common//. Both registrations now use /api/common/v1/TENANT, replacing the unsupported /ccx/api prefix. This tenant form is distinct from the gateway form, which omits the tenant segment. Confirm the substituted destination in the tenant Explorer before enabling. The Workday Data Lake guide on doc.workday.com documents the token endpoint form https://{HOST}/ccx/oauth2/{TENANT}/token. The 2026-09-21 review found that developer.workday.com offered no open operation reference without an account.\n\nThe review could not establish these exact operations against provider-hosted documentation: GET /ccx/api/recruiting/v4/{tenant}/jobPostings; GET /ccx/api/absenceManagement/v1/{tenant}/balances; and POST /ccx/api/absenceManagement/v1/{tenant}/workers/{id}/requestTimeOff. Third-party vendors and practitioners describe these or similar paths, and search snippets mention an absence-balances GET under absenceManagement v5, but none supplies the required provider reference. Consequently workday.job-postings.read, workday.absence-balances.read, and workday.time-off-requests.create were removed on 2026-09-21. They remain excluded until the tenant Explorer or another dated provider document verifies each exact method, path, and version. This disposition is specific to this package; other drafts may retain unverified operations with explicit blockers.\n\nAlso excluded: payroll execution or mutation, offer-letter generation, job-requisition creation, worker hire, compensation changes, and business-process approvals. These exclusions make no claim about whether Workday supports those operations. Legacy SOAP services under /ccx/service/{tenant}/... require separate review of WS-Security Integration System User (ISU) credentials and tenant WSDL versions. This package does not assert that hire is SOAP-only or that payroll REST is read-only.\n\nAbsence balances and time-off data can reveal health-related information. Any future registration needs a fresh review of data classification and handling, in addition to its risk tier.\n\nThe credential is an externally refreshed OAuth token held in the customer's vault. Before promotion, confirm tenant issuance authority and delegation, functional scopes and ISU security-domain mapping for each capability, audience, actual token lifetime, executor access, and bypass paths. Review these against the credential-custody requirements in docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4. The credential note states deployment requirements and open questions; it establishes no completed deployment custody assessment.\n\nSources: the common v1 specification and the Data Lake guide (both retrieved 2026-10-22) and the Workday Education page (retrieved 2026-09-21) are substantive provider documents; the REST Services Directory page returned a shell; developer.workday.com supplied indexed Workers documentation on 2026-10-29 despite returning a shell on direct open. The package is not provider-certified or endorsed; the custody questions above still need owner disposition, and current full operation specifications must be retrieved before promotion.\n\nRe-review on 2026-10-29: Workday's Web Services and API Integrations course confirms GET /supervisoryOrganizations, and its Data Lake guide still documents the token endpoint form. The current common v1 specification and the standalone Supervisory Organizations Markdown reference could not be retrieved through the web reader; the earlier specification findings retain their 2026-10-22 date. Both URL registrations and this pack move to version 1.1.0. The pack remains HELD pending a complete current contract comparison and the owner's custody review; no approval is recorded. The Workers reference also supports the timeOffSummary view on the collection. This pack does not constrain query parameters: a deployment must restrict permitted views or review the resulting absence-data classification before enabling.", "credential": { "secret_ref_id": "secret-ref-workday-oauth", "custody": "customer_vault", "inject": "header", "inject_name": "Authorization", "note": "Store the complete Authorization header value for a tenant OAuth2 access token in the customer's secret manager. The executor injects that value; this reference must not contain a client secret or refresh token in place of an access token.\n\nAn external deployment process must own token issuance and renewal. Workday's Data Lake guide retrieved 2026-10-29 documents https://{HOST}/ccx/oauth2/{TENANT}/token. That guide does not establish the full Common v1 token contract. Before enabling, confirm the appropriate API client and ISU, grant, audience, functional scopes, security domains, token lifetime and revocation behavior against the tenant's reference. The 2026-10-22 common v1 specification review named Staffing for workers and Organizations and Roles for supervisory organizations; those scope findings were not freshly verified against the specification on 2026-10-29.\n\nThe external process must renew before the confirmed expiry and stop renewal when access is revoked. Reject expired or rejected material. Do not assume non-expiring refresh tokens or immediate invalidation of captured access tokens without vendor documentation and tenant confirmation.\n\nThe custody review awaits the owner's disposition. Issuance authority and delegation, scope and ISU domain mapping, audience, observed TTL, revocation, executor access and bypass paths remain deployment checks. An architectural requirement is not evidence that a deployment meets it.\n\nExecutor hygiene requirements: restrict vault access to this reference, resolve the header only for the call, and keep it out of logs, diagnostics and crash reports. The deployment must verify these controls before enabling." }, "capabilities": [ { "capability_id": "workday.workers.read", "version": "1.1.0", "kind": "tool", "risk_tier": "R0", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "pii", "egress_allowlist": [ "workday-datacenter.invalid" ], "endpoint": "https://workday-datacenter.invalid/api/common/v1/TENANT/workers", "method": "GET", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-workday-oauth", "inject": "header", "inject_name": "Authorization", "actions": [ "read" ], "resource_id": "workday-tenant", "description": "Read the workers collection (GET /workers in common v1; limit default 20, maximum 100, with offset paging, optional search and includeTerminatedWorkers): paginated worker summaries such as names, work emails, titles and organization assignments, which are personal data. This registration covers the collection endpoint only; instance reads such as /workers/WORKER_ID are not registered and would require a separately reviewed capability. An R0 read classified as pii (personal data) is still a serious confidentiality risk — the tier is a minimum requirement, rather than a business-risk assessment.", "requires_review": true }, { "capability_id": "workday.supervisory-orgs.read", "version": "1.1.0", "kind": "tool", "risk_tier": "R0", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "internal", "egress_allowlist": [ "workday-datacenter.invalid" ], "endpoint": "https://workday-datacenter.invalid/api/common/v1/TENANT/supervisoryOrganizations", "method": "GET", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-workday-oauth", "inject": "header", "inject_name": "Authorization", "actions": [ "read" ], "resource_id": "workday-tenant", "description": "Read the supervisory organization collection (GET /supervisoryOrganizations in common v1; limit default 20, maximum 100, with offset paging): the tenant's supervisory organization hierarchy entries. This registration covers the collection endpoint only; instance reads and membership subpaths such as /supervisoryOrganizations/ORG_ID/workers are not registered and would require a separately reviewed capability. Organization structure is internal data, though descriptors can name the manager; classify differently in the deployment if it does.", "requires_review": true } ], "resources": [ { "resource_id": "workday-tenant", "kind": "api", "locator": "https://workday-datacenter.invalid/api/common/v1/TENANT", "data_class": "pii", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN" } ], "review": { "state": "draft", "date": "2026-10-29", "sources": [ "https://doc.workday.com/workday-education/en-us/course-manuals/workday-extend-for-developers/relationships-between-business-objects.html (retrieved 2026-09-21)", "https://community.workday.com/sites/default/files/file-hosting/restapi/index.html (retrieved 2026-09-21)", "https://developer.workday.com/ (retrieved 2026-09-21)", "https://community.workday.com/sites/default/files/file-hosting/restapi/common_v1_20261003_oas2.json (retrieved 2026-10-22)", "https://doc.workday.com/admin-guide/en-us/workday-data-cloud/data-out/workday-data-lake/workday-data-lake.html (retrieved 2026-10-22)", "https://developer.workday.com/documentation/dan1370797991225/ (retrieved 2026-10-29)", "https://doc.workday.com/workday-education/en-us/course-manuals/creating-integrations-using-workday-orchestrate/web-services-and-api-integrations.html (retrieved 2026-10-29)", "https://doc.workday.com/admin-guide/en-us/workday-data-cloud/data-out/workday-data-lake/workday-data-lake.html (retrieved 2026-10-29)" ], "reviewer_id": "aaes-eng" } }