Study guide
13.2 Integration Security: ISUs, ISSGs & Web Services
Workday Human Capital Management HCM
Track your progress as you read
Finished sections get a check mark.
1 Foundation & Navigation
1.1 Workday Cloud Architecture, Tenants & Navigation 1.2 Business Objects, Data Model & Related Actions 1.3 Worker Types, My Tasks & Delegation
2 Organizations & Hierarchies
2.1 Supervisory Organizations & Hierarchy Structure 2.2 Matrix, Location & Custom Organizations 2.3 Cost Centers & Financial Organization Hierarchies 2.4 Reorganizations, Effective Dating & Inactivation
3 Staffing Models & Worker Lifecycle
3.1 Staffing Models: Position Management vs Job Management 3.2 The Hire Process & Contingent Worker Contracting 3.3 Job Changes: Transfers, Promotions & Lateral Moves 3.4 Terminations, Separations & Staffing Audit Trails
4 Jobs, Positions & Headcount Management
4.1 Job Profiles, Families & Management Levels 4.2 Position Creation, Restrictions & Availability Dates 4.3 Managing Positions: Close, Freeze & Requisitions
5 Business Process Framework Fundamentals
5.1 Business Process Definitions & Flow Architecture 5.2 Step Types: Actions, Approvals & Approval Chains 5.3 To-Do Steps, Checklists & Integration Steps 5.4 Completion Order, Parallel vs Serial Routing, Conditions & Advanced Routing
6 Advanced Business Process Administration
6.1 Event Operations: Rescind, Cancel, Correct & Mass Operations 6.2 Effective Dates vs Entry Moments & Subprocess Execution 6.3 Service Center Routing & Workday Illuminate AI for BP Intelligence
7 Configurable Security Architecture
7.1 Security Fundamentals: Domains, Functional Areas & Domain Security Policies 7.2 Role-Based Security Groups: Constrained vs Unconstrained 7.3 User-Based, Job-Based, Segment-Based & Workday-Assigned Security Groups 7.4 Security Policy Activation, Role Assignment & Security Audit
8 Compensation Structure & Plan Design
8.1 Compensation Packages, Grades & Grade Profiles 8.2 Base Pay, Allowance Plans & Period Salary Plans 8.3 Bonus Plans, Merit Plans, Commission Plans & Stock Grants 8.4 Compensation Eligibility Rules, Defaulting Logic & Merit Review Cycles
9 Talent, Performance & Skills Management
9.1 Talent Profiles, Competencies & Certifications 9.2 Skills Cloud, Machine Learning Taxonomy & Skill Matching 9.3 Performance Review Cycles, Goals & Anytime Feedback 9.4 Succession Planning, Talent Pools & 9-Box Matrix
10 Absence Management & Time Off
10.1 Absence & Time-Off Plans, Types & Accruals 10.2 Absence Eligibility Rules, Validation Rules & Calendars 10.3 Leave of Absence (LOA) Types, Pay Status & Return to Work
11 Recruiting & Candidate Lifecycle
11.1 Job Requisitions, Postings & Career Sites 11.2 Candidate Pipelines, Stage Progression & Screening Workflows 11.3 Employment Offers, eSignatures & Ready for Hire Transition
12 Report Writer & Data Visualization
12.1 Building Custom Reports: Types, Columns, Sorting, Filters & Prompts 12.2 Primary Data Sources, Indexed Data Sources & Business Objects 12.3 Calculated Fields: Text, Date, Arithmetic, Logic & Lookup Related Value 12.4 Discovery Boards, Dashboards & Prism Analytics Integration
13 Workday Integrations & Enterprise Interface Builder
13.1 Integration Architecture: Core Connectors, Studio, REST & SOAP APIs 13.2 Integration Security: ISUs, ISSGs & Web Services 13.3 Enterprise Interface Builder (EIB): Outbound Integrations & Transformations 13.4 Enterprise Interface Builder (EIB): Inbound Integrations & Spreadsheet Templates
14 Release Management, Ecosystem & Workday AI
14.1 Semi-Annual Release Cadence, Preview Tenants & Feature Opt-In 14.2 Workday Illuminate AI, AI Assistant & Generative Productivity 14.3 Agent System of Record, AI Governance & Workday Extend
13.2 Integration Security: ISUs, ISSGs & Web Services
Key Takeaways Explain This Topic AI
Integrations must never execute under individual human user accounts; they require a dedicated Integration System User (ISU) flagged with 'Do Not Allow Direct Login'.
Integration System Users acquire permissions exclusively through membership in Integration System Security Groups (ISSG), which can be constrained or unconstrained.
Integration security groups must be granted explicit Get (read) and/or Put (write) permissions on specific Domain Security Policies, followed by executing the Activate Pending Security Policy Changes task.
Modern integration authentication mandates deprecating basic username/password credentials in favor of X.509 Public Key Certificates or OAuth 2.0 Client Credentials grants.
Report-as-a-Service (RaaS) dynamically evaluates the invoking ISU's domain security policies; unauthorized fields return blank/null values rather than throwing fatal authorization errors.
Last updated: September 2026
13.2 Integration Security: ISUs, ISSGs & Web Services
Quick Answer: All Workday integrations must execute under non-human service accounts known as Integration System Users (ISUs) . To protect the tenant, ISUs must be flagged with Do Not Allow Direct Login , preventing interactive browser-based sessions. Permissions are granted by placing the ISU into an Integration System Security Group (ISSG) , which is then assigned Get (read) or Put (write) permissions on the necessary Domain Security Policies . Changes take effect only after running Activate Pending Security Policy Changes . External systems authenticate using X.509 digital certificates or OAuth 2.0 Client Credentials . When exposing custom reports via Report-as-a-Service (RaaS) , data visibility is strictly bounded by the invoking ISU's security context.
Integration System Users (ISU): Non-Human Service Identities
In an enterprise production environment, running an automated integration under an employee's personal user account creates severe operational, security, and compliance risks. If the employee changes roles, takes a leave of absence, or terminates employment, their account is locked or reassigned, causing mission-critical interfaces to fail immediately. Furthermore, human accounts often possess broad, unneeded permissions across multiple functional domains, violating the principle of least privilege .
The Role of the Integration System User (ISU)
An Integration System User (ISU) is a specialized, non-human service account created via the Create Integration System User task. ISUs exist exclusively to execute scheduled integrations, process API requests, and establish web service connections. +---------------------------------------------------------------------------------------+
- | CREATE INTEGRATION SYSTEM USER |
- +---------------------------------------------------------------------------------------+
- | User Name: ISU_Payroll_Outbound_ADP |
- | Password / Confirm: [ Encrypted / Managed Key ] |
- | [X] Do Not Allow Direct Login <-- CRITICAL EXAM WATCHPOINT (Blocks Web UI Access) |
- | Session Timeout Minutes: 30 |
- | Password Never Expires: [ Configurable per corporate security policy ] |
- +---------------------------------------------------------------------------------------+
- Critical ISU Configuration Attributes
Do Not Allow Direct Login (Mandatory Audit Rule): This checkbox is a fundamental security safeguard. Enabling it blocks the ISU from logging into the Workday graphical user interface (UI) through a web browser. The account can only authenticate via web service APIs, EIB launches, and Studio endpoints. This prevents malicious actors from hijacking service account credentials to access interactive screens.
Exemption from Multi-Factor Authentication (MFA): Automated background scripts and external middleware (e.g., MuleSoft, Boomi) cannot respond to interactive MFA prompts. ISUs are exempted from browser-based MFA policies, necessitating robust alternative controls such as certificate authentication, OAuth 2.0, or strict IP whitelisting.
Session Timeout Tuning: Integration processes often transfer extensive datasets requiring sustained execution times. Administrators tune the session timeout setting on the ISU to accommodate long-running batch jobs without premature termination.
Enterprise Naming Standards: Certified administrators enforce clear naming conventions reflecting purpose, direction, and target system: ISU_<Direction>_<TargetSystem>_<Function> (e.g., ISU_Outbound_ADP_Payroll , ISU_Inbound_Cornerstone_LMS ).
Integration System Security Groups (ISSG) & Domain Policy Assignment
In Workday's security model, users do not receive permissions directly. An ISU has zero access upon creation. To grant access, the administrator assigns the ISU to an Integration System Security Group (ISSG) . +-----------------------+ Member Of +-------------------------------------+
- | INTEGRATION | --------------------> | INTEGRATION SYSTEM |
- | SYSTEM USER (ISU) | | SECURITY GROUP (ISSG) |
- +-----------------------+ +-------------------------------------+
- |
- | Assigned To
- v
- +-------------------------------------+
- | DOMAIN SECURITY POLICIES |
- | - Worker Data: Public Worker |
- | - Worker Data: Current Staffing |
- | - Worker Data: Base Pay |
- +-------------------------------------+
- |
- +--------------------------+--------------------------+
- | |
- v (Read Operations) v (Write Operations)
- +-------------------------------+ +-------------------------------+
- | GET PERMISSIONS | | PUT PERMISSIONS |
- | - View fields in RaaS reports | | - Inbound EIB data load |
- | - Extract data via SOAP/WWS | | - Execute web service updates |
- +-------------------------------+ +-------------------------------+
- Creating and Populating the ISSG
Execute the Create Security Group task.
Select the type: Integration System Security Group (Unconstrained) or Integration System Security Group (Constrained) .
Unconstrained ISSG: Grants access across all organizations and populations in the tenant. Typical for enterprise-wide outbound feeds (e.g., corporate payroll or 401(k) benefit files).
Constrained ISSG: Restricts the integration's visibility to specific organizations, locations, or companies. Used when an integration should only access records within a specific subsidiary or region.
Add the target ISU to the security group's membership list.
Domain Security Policies: Get vs. Put Permissions
Every functional attribute and web service operation in Workday is governed by a Domain Security Policy residing within a specific Functional Area. The administrator must explicitly configure access rules:
Get Access: Grants read-only authority. Required for outbound integrations, custom report queries (RaaS), and data extraction web services.
Put Access: Grants write, update, and creation authority. Required for inbound integrations loading external records, modifying worker data, or executing business process web service transactions.
The Mandatory Activation Step ( Activate Pending Security Policy Changes )
Modifying a domain security policy places the tenant into a pending security state. Changes do NOT take effect immediately.
Exam Trap: A common exam scenario describes an administrator creating an ISU, configuring an ISSG, and granting Get access to the Worker Data: Personal Info domain. However, when the integration executes, it fails with an HTTP 403 Forbidden or authorization error. The missing step is executing the Activate Pending Security Policy Changes task and confirming the changes with an electronic signature comment.
Authentication Protocols: Certificates & OAuth 2.0
Securing integration transport involves transitioning away from legacy basic authentication toward modern cryptographic standards.
1. Basic Authentication (Legacy)
Basic authentication transmits the ISU username and password within the HTTP authorization header (base64 encoded) over TLS/SSL. While supported, enterprise governance policies strongly discourage basic authentication due to credential leakage risks and password rotation maintenance.
2. X.509 Digital Public Key Certificates
Workday supports certificate-based authentication for web services:
The administrator or integration developer generates an RSA public/private key pair.
The X.509 Public Key Certificate is uploaded directly to the ISU record in Workday via the Maintain Integration System User related actions menu.
The client application signs outgoing SOAP requests or presents the client certificate during mutual TLS (mTLS) handshakes. Workday validates the signature against the registered certificate, authenticating the request without transmitting passwords.
3. OAuth 2.0 Framework
For modern REST APIs and enterprise API gateways (e.g., Apigee, MuleSoft), Workday supports OAuth 2.0 utilizing the Client Credentials Grant flow:
API Client Registration: Administrators execute the Register API Client task, defining client name, client type (Non-Public), and assigned scopes.
Token Generation: The external system requests a short-lived Bearer token from the Workday OAuth token endpoint ( /oauth2/token ) using its client_id and client_secret .
API Invocations: Subsequent REST or WQL requests supply the Bearer token in the Authorization: Bearer <token> header, ensuring high-security, time-bounded access.
Report-as-a-Service (RaaS): Turning Reports into APIs
Report-as-a-Service (RaaS) is one of the most widely deployed integration patterns in the Workday ecosystem. It allows administrators to build an Advanced Report using the graphical Report Writer and expose it instantaneously as a secure web service endpoint. +---------------------------------------------------------------------------------------+
- | RAAS CONFIGURATION STEPS |
- +---------------------------------------------------------------------------------------+
- | 1. CREATE ADVANCED REPORT | Build report with required fields and calculated fields|
- | 2. ENABLE AS WEB SERVICE | Flag 'Enable as Web Service' on the Advanced tab |
- | 3. WEB SERVICE ALIASES | Assign clean XML element names to each column |
- | 4. COPY REST/WSDL URL | Retrieve endpoint URL from Report > Web Services menu |
- | 5. ASSIGN ISU SECURITY | Ensure invoking ISU has 'Get' access to all domains |
- +---------------------------------------------------------------------------------------+
- RaaS Endpoint Formats
RaaS automatically renders report data in multiple output formats based on the requested endpoint URL:
Workday XML ( /wd:Report_Data ): Standard hierarchical XML preserving Workday schema structures and sub-element collections.
Simple XML: Stripped XML format eliminating internal namespace wrappers, optimized for legacy middleware parsers.
JSON ( format=json ): Clean JavaScript Object Notation, ideal for modern web portals, cloud microservices, and mobile applications.
CSV ( format=csv ): Delimited plain text for direct consumption by spreadsheets or flat-file ETL pipelines.
Security Evaluation in RaaS: The "Silent Omission" Phenomenon
When an external system invokes a RaaS endpoint, Workday evaluates the security context of the authenticating user (the ISU) in real time:
Field-Level Security Suppression: If the report definition includes 15 columns, but the ISU belongs to an ISSG that lacks Get permissions on the Worker Compensation domain, the report does not fail . Instead, it executes successfully, but the compensation columns return completely empty/null!
Exam Watchpoint: If an integration developer reports that an outbound RaaS integration runs without errors but output files are missing salary numbers, the issue is security domain authorization , not a broken report filter or failed calculation.
Integration Security Governance Matrix
The following table contrasts human user security with integration security architecture:
- Governance Dimension Human User Account Integration System User (ISU)
- Primary Purpose Interactive employee/manager self-service Automated system-to-system data interchange
- Direct UI Login Allowed (Username + Password / SSO) Strictly Forbidden ( Do Not Allow Direct Login )
- MFA Requirements Enforced via tenant authentication policies Exempt (Secured via Certificates or OAuth 2.0)
- Security Group Type Role-Based, User-Based, Job-Based Integration System Security Group (ISSG)
- Domain Permissions View and Modify tasks in UI Get (Read) and Put (Write) API operations
Policy Activation Requires activating pending security policies Requires Activate Pending Security Policy Changes
Credential Lifecycle Subject to password expiration & corporate SSO Managed API keys, X.509 certs, or OAuth client secrets
Certification Pitfalls & Common Exam Traps
The "Do Not Allow Direct Login" Misconception: Exam questions often test whether checking "Do Not Allow Direct Login" prevents an ISU from executing integrations. Candidates must remember: it only blocks interactive browser UI logins . It has zero negative impact on API, SOAP, REST, or EIB executions.
The Missing Security Activation Trap: When configuring integration security, adding domains to an ISSG does not take effect until an administrator runs Activate Pending Security Policy Changes . Questions describing an integration that fails with authorization errors immediately after security assignment are testing this exact requirement.
Silent Data Omission in RaaS: When an ISU lacks permissions for a field exposed in a RaaS report, the web service call does not throw an HTTP error or crash . Workday returns an HTTP 200 OK status code with an XML/JSON payload where the unauthorized fields are silently omitted or empty.
Constrained vs. Unconstrained ISSG for Global Integrations: If an outbound benefits integration must extract all global employees, placing the ISU in a Constrained ISSG tied to the US Subsidiary will result in non-US workers being omitted from the file. Global feeds require an Unconstrained ISSG .