7.1 Security Fundamentals: Domains, Functional Areas & Domain Security Policies

7.1 Security Fundamentals: Domains, Functional Areas & Domain Security Policies

Quick Answer: Workday enforces a declarative, metadata-driven security framework organized into Functional Areas, Domains, and Domain Security Policies (DSP). Rather than securing physical database tables or hardcoding screen access, Workday secures collections of items—securable report fields, operational tasks, and web services—within delivered domains. A Domain Security Policy defines which security groups hold View (read-only) or Modify (read-write) permissions for end users, and Get (read) or Put (write) permissions for programmatic web service integrations. Access across multiple security groups on a policy is additive (logical OR), unless an Intersection Security Group (ISG) is deliberately configured to enforce a logical AND constraint. Customers cannot create custom domains; they configure access rules on Workday-delivered domains.

---

The Workday Configurable Security Architecture

In traditional relational database management systems (RDBMS) and legacy ERP software, security models are frequently fragmented. Table-level database permissions, application-level page security, procedural scripts, and custom API authorization layers often operate in disconnected silos. This legacy architecture results in security drift, complex maintenance, and severe audit vulnerabilities during system upgrades.

Workday replaces this fragmented paradigm with the Configurable Security Framework—a unified, in-memory, metadata-driven architecture. In Workday:

• Security is declarative: administrators configure rules defining who can access what data and execute what actions, and the in-memory kernel enforces these rules dynamically across all user interfaces, mobile apps, custom reports, and API web services simultaneously.
• Security applies uniformly to The Power of One: a user accessing employee compensation through a Workday report, a mobile device, a dashboard worklet, or a Workday Web Service (WWS) integration endpoint is governed by the exact same underlying security policy.
• Security is never hardcoded: screens and reports do not check procedural IF/ELSE code blocks to determine whether to display a field. Instead, the runtime engine dynamically evaluates the active user's assigned security groups against the metadata rules defined in the domain security policy, automatically security-trimming unpermitted data and actions from the user's view.

+---------------------------------------------------------------------------------------------------+
|                                 WORKDAY UNIFIED SECURITY MODEL                                    |
+---------------------------------------------------------------------------------------------------+
|                                         FUNCTIONAL AREA                                           |
|                        (e.g., Core HR, Compensation, Staffing, Benefits)                          |
|                                                |                                                  |
|                                                v                                                  |
|                                             DOMAINS                                               |
|              (Securable collections of Fields, Actions/Tasks, and Web Services)                   |
|                                                |                                                  |
|                                                v                                                  |
|                                   DOMAIN SECURITY POLICY (DSP)                                    |
|              (Rule establishing which Security Groups have View/Modify/Get/Put)                    |
|                                                |                                                  |
|                        +-----------------------+-----------------------+                          |
|                        |                                               |                          |
|                        v                                               v                          |
|                 HUMAN USERS                                    INTEGRATIONS                       |
|          - View (Read-only fields/reports)              - Get (Query data via API)                |
|          - Modify (Edit fields / launch tasks)          - Put (Create/update data via API)        |
+---------------------------------------------------------------------------------------------------+

---

Functional Areas: The Administrative Envelope

At the highest structural level, Workday organizes all system features, business logic, and security configurations into Functional Areas. A functional area represents a broad business operational discipline within the enterprise suite.

Functional Area Organization and Governance

Workday delivers more than 80 functional areas, covering every module of the Human Capital Management, Financial Management, and Student suites. Core HCM functional areas include:

• Core HR: Fundamental worker records, personal identifiers, contact information, service dates, and worker statuses.
• Staffing: Job requisitions, hiring, job changes, transfers, promotions, demotions, and terminations.
• Compensation: Base pay structures, salary plans, hourly plans, grade profiles, allowances, bonuses, and merit cycles.
• Benefits: Benefit elections, open enrollment, coverage plans, beneficiaries, dependents, and provider communications.
• Payroll: Pay groups, earnings, tax withholdings, deductions, payroll processing, and statutory remittances.
• System & Security: Security administration, tenant configuration, business process framework configuration, and audit logging.

Enabling and Disabling Functional Areas

Administrators manage functional areas using the Maintain Functional Areas task in Workday. While foundational functional areas such as Core HR, Staffing, and System & Security are permanently active and cannot be deactivated, many optional modules (e.g., Recruiting, Talent Optimization, Advanced Compensation, Project Tracking) can be enabled or disabled.

Exam Trap Alert: When a functional area is disabled in Maintain Functional Areas, every domain, task, report, business process, and web service associated with that functional area is immediately suppressed tenant-wide. Even a System Administrator cannot search for, view, or configure items belonging to a disabled functional area. If an administrator is unable to locate a delivered report or domain in the tenant, the primary diagnostic checkpoint is verifying whether the governing Functional Area is enabled.

Core Functional Areas and Representative Domains Matrix

---

Domains and Securable Items

A Domain is a Workday-delivered, securable collection of related functionality and data items that share identical or closely linked access requirements. Domains represent the atomic building blocks of data and transactional security in the tenant.

Delivered Domains vs. Custom Architecture

A foundational rule of Workday security is that customers cannot create custom domains. Workday designs, packages, and delivers all domains as part of the unified application schema. System administrators do not build domains from scratch; instead, they configure access rules by attaching permitted security groups to these delivered domains.

Anatomy of a Domain: The Three Securable Item Types

Every domain protects three distinct categories of system artifacts, collectively known as Securable Items:

1. Securable Report Fields:
   • Individual attributes stored on business objects that can be queried in custom reports, viewed on worker profiles, or surfaced in analytical dashboards.
   • Example: In the domain Worker Data: National Identifiers, the securable fields include Social Security Number, Tax ID, Passport Number, and Visa Type.
2. Securable Actions & Tasks:
   • Functional screens, menu options, and operational tasks accessible through the global search bar or the Related Actions menu ("twinkie").
   • Example: In the domain Job Profile and Job Families, securable tasks include Create Job Profile, Edit Job Profile, and View Job Family Groups.
3. Web Service Operations:
   • Programmatic Application Programming Interface (API) endpoints used by inbound and outbound integrations to exchange XML/JSON payloads with external systems.
   • Example: In the domain Worker Data: Personal Information, securable web services include Get_Workers (reading worker details) and Change_Personal_Information (updating contact information).

+---------------------------------------------------------------------------------------------------+
|                                 INSIDE A WORKDAY DOMAIN                                           |
+---------------------------------------------------------------------------------------------------+
| Domain Name: Worker Data: Personal Information                                                    |
| Functional Area: Core HR                                                                          |
+---------------------------------------------------------------------------------------------------+
|  1. SECURABLE REPORT FIELDS      2. SECURABLE ACTIONS / TASKS       3. WEB SERVICE OPERATIONS     |
|  - Legal Name                    - Change Legal Name                - Get_Workers (Personal Data) |
|  - Preferred Name                - Edit Preferred Name              - Change_Personal_Information |
|  - Home Address                  - Maintain Addresses               - Put_Worker_Contact_Details  |
|  - Personal Phone Numbers        - View Contact Information         - Get_Worker_Photos           |
|  - Date of Birth                 - Edit Emergency Contacts          - Put_Emergency_Contacts      |
+---------------------------------------------------------------------------------------------------+

---

Domain Security Policies: View/Modify vs. Get/Put

A Domain Security Policy (DSP) is the explicit administrative rule associated with a domain that dictates which security groups have permission to interact with that domain's securable items, and at what operational level.

Human Interactive Permissions: View vs. Modify

When configuring a DSP for human users accessing Workday through the user interface (web browser or mobile client), permissions are segregated into two distinct access tiers:

1. View Permission (Read-Only):
   • Authorizes assigned security groups to see securable report fields in custom reports, search results, and worker profiles.
   • Authorizes users to execute read-only inquiry tasks (e.g., View Worker History, View Compensation).
   • Critical Boundary: View permission never permits a user to update a field, launch a transactional business process, or submit an edit form.
2. Modify Permission (Read-Write / Execute):
   • Authorizes assigned security groups to edit, update, or create data associated with the domain's securable fields.
   • Authorizes users to launch state-changing tasks (e.g., Edit Personal Information, Create Position).
   • Prerequisite Rule: In Workday, granting Modify permission automatically encompasses read access; a user who can modify a field can inherently view that field.

Integration Web Service Permissions: Get vs. Put

For automated integrations and external system data exchanges running via Workday Web Services (WWS), the DSP provides separate, parallel programmatic permissions:

1. Get Operation Permission (Outbound / Read):
   • Permits an Integration System User (ISU) to execute read-only API requests to query and extract data from Workday (e.g., calling Get_Workers to extract demographic data for an external payroll vendor).
   • Corresponds conceptually to View permission in the user interface.
2. Put Operation Permission (Inbound / Write):
   • Permits an ISU to execute inbound API requests to create, update, or overwrite records in Workday (e.g., calling Put_Compensation to load annual merit increases from an external compensation modeler).
   • Corresponds conceptually to Modify permission in the user interface.

Human vs. Integration Permission Matrix

Exam Watchpoint: In domain security configuration, the UI displays two separate tables: one for Report/Task Permissions (specifying View and Modify security groups for interactive users) and another for Integration Permissions (specifying Get and Put security groups for integration accounts). A security group added only to the View column cannot extract data via SOAP API unless it is also explicitly assigned to the Get column in Integration Permissions.

---

Security Group Evaluation: Additive Union vs. Intersection

A vital concept tested on the Workday HCM certification exam is how Workday resolves access when a user belongs to multiple security groups or when multiple groups are configured on a Domain Security Policy.

Standard Additive Union (Logical OR)

By default, Workday security is additive. If multiple security groups are granted access to a domain, or if an individual worker belongs to multiple security groups, Workday calculates their effective permissions using a logical OR operation:

• If User A belongs to Security Group 1 (which has View access) and Security Group 2 (which has Modify access), User A's effective permission is Modify.
• A user does not need to satisfy every permitted group; satisfying any single permitted security group is sufficient to grant the corresponding access level.
• There is no concept of an explicit "Deny" permission in Workday that overrides an "Allow". Security is purely grant-based.

Intersection Security Groups (Logical AND)

While additive security handles the vast majority of enterprise requirements, certain high-compliance scenarios require restricting access so that a worker must meet multiple simultaneous criteria. For this purpose, Workday provides Intersection Security Groups (ISG).

+---------------------------------------------------------------------------------------------------+
|                         ADDITIVE UNION (OR) vs. INTERSECTION (AND)                                |
+---------------------------------------------------------------------------------------------------+
|  ADDITIVE EVALUATION (DEFAULT)                     INTERSECTION EVALUATION (ISG)                  |
|                                                                                                   |
|  Security Group 1: HR Partner                      Security Group 1: HR Partner                   |
|  Security Group 2: US Payroll Specialist           Security Group 2: US Payroll Specialist        |
|                                                                                                   |
|  [ Worker in EITHER Group 1 OR Group 2 ]           [ Worker MUST be in BOTH Group 1 AND Group 2 ] |
|                   |                                                     |                         |
|                   v                                                     v                         |
|            ACCESS GRANTED                                        ACCESS GRANTED                   |
+---------------------------------------------------------------------------------------------------+

• Mechanics: An Intersection Security Group requires a user to be an active member of Group A AND Group B simultaneously to receive the granted permissions.
• Business Example: An enterprise wants to ensure that only HR Partners who are also explicitly certified as US Payroll Compliance Specialists can view worker social security numbers. Granting access to HR Partner alone is too broad, and granting access to US Payroll Specialists alone includes non-HR staff. An Intersection Security Group combining HR Partner AND US Payroll Specialist solves this compliance mandate precisely.

---

Step-by-Step Configuration: Editing a Domain Security Policy

To configure access to a domain in a Workday tenant, a security administrator executes the following standardized procedure:

+---------------------------------------------------------------------------------------------------+
|                    ADMINISTRATIVE WORKFLOW: EDIT DOMAIN SECURITY POLICY                           |
+---------------------------------------------------------------------------------------------------+
| Step 1: Locate Target Domain                                                                      |
|         Task: Search for domain name or run 'View Domain Security Policy'                         |
|         Example: 'Worker Data: Personal Information'                                              |
|                                                                                                   |
| Step 2: Access Configuration Action                                                               |
|         Click Related Actions on the domain -> 'Domain Security Policy' -> 'Edit Permissions'    |
|                                                                                                   |
| Step 3: Populate Report/Task Permissions (Human UI Access)                                        |
|         - In the 'View' column, add security groups requiring read-only access                   |
|         - In the 'Modify' column, add security groups requiring write/edit access                 |
|                                                                                                   |
| Step 4: Populate Integration Permissions (API / Integration Access)                               |
|         - In the 'Get' column, add Integration System Security Groups requiring outbound read    |
|         - In the 'Put' column, add Integration System Security Groups requiring inbound write   |
|                                                                                                   |
| Step 5: Save Configuration into Staged Pending State                                               |
|         Click OK. The policy enters 'Pending Security Policy Changes' status.                    |
|         CRITICAL: Changes have ZERO operational effect until activated via policy activation!     |
+---------------------------------------------------------------------------------------------------+

---

Domain Security Auditing & Securable Item Discovery

Workday provides powerful built-in diagnostic and audit tasks that allow administrators to inspect domain configurations, trace field permissions, and verify regulatory compliance.

Key Diagnostic Tasks

1. View Security for Securable Item:
   • Accepts any securable report field, task, or web service as input (e.g., Date of Birth or Create Position).
   • Instantly displays the governing domain, the functional area, and every security group that currently holds View, Modify, Get, or Put permissions on that item.
   • Essential for answering: "Why can this user see this sensitive field on the employee profile?"
2. Domain Securable Items and Criteria:
   • Displays the exhaustive catalog of all securable report fields, operational actions, and web service operations bundled inside a specific domain.
3. Domain Security Policy Audit:
   • Generates a historical audit report detailing every modification made to a domain security policy, including the user who edited it, the previous permission configuration, the new configuration, and the activation timestamp.

---

Certification Pitfalls & Common Exam Traps

1. The "View Equals Transactional Access" Fallacy: An exam scenario states that an HR Partner has View permission on the Worker Data: Compensation domain, but complains they cannot edit an employee's hourly rate during a compensation review. The question asks what is broken. The answer: View permission strictly provides read-only visibility. To edit fields or submit transactions, the security group must be granted Modify permission on the DSP.
2. The Disabled Functional Area Trap: If an administrator searches for a delivered task (e.g., Create Applicant) and receives no results, the exam tests your knowledge that the parent Functional Area (e.g., Recruiting) is likely disabled via Maintain Functional Areas.
3. The Unactivated Policy Trap: An administrator configures a new security group on a DSP, saves the page, and logs in as a test user, but the test user still cannot see the fields. The exam tests whether you remember that security policy edits do not take effect until the Activate Pending Security Policy Changes task is executed.
4. Custom Domain Impossibility: Any question option suggesting that an administrator should "create a new custom domain" to solve an authorization requirement is always incorrect. Domains are immutable, delivered architectural structures.