9.3 Domain Security Policies

9.3 Domain Security Policies

Quick Summary: Each domain is governed by a Domain Security Policy that lists which security groups may View, Modify, Get, or Put the secured items in that domain. HCM Core expects you to maintain those policies for new groups and to understand that policy changes stay pending until activation.

Task T41 is operational: take a security group (often one you just created) and give it the right domain permissions. This is how data and task access become real after membership design in section 9.2.

What a Domain Security Policy Is

A Domain Security Policy is the configuration object that states, for one domain:

• Which security groups are allowed,
• Which permissions each group has on that domain,
• Whether the policy design is enabled as intended for the tenant.

Securable items inside the domain—tasks, reports, data elements, fields—inherit protection from that policy. You do not typically secure each field with a completely separate custom model at Core level; you work at the domain (and related domain hierarchy) level Workday delivers.

Domain policy vs everything else

Domain Permission Types

Memorize the four classic domain permissions and their surfaces:

View vs Modify (UI pair)

• View without Modify = read-only UI access to the domain's items.
• Modify implies the ability to change; design still follows least privilege—grant Modify only when the role must edit.
• A compensation partner often needs View (and sometimes Modify) on worker compensation domains used in transactions, while only a smaller admin set needs Modify on compensation setup domains.

Get vs Put (integration pair)

• Get = integration read.
• Put = integration write.
• Integration System Users typically receive Get/Put on the specific domains their integration needs—not blanket Modify on every HCM domain in the UI.

Exam trap: If the stem lists Initiate among domain permissions, treat it as a distractor. Initiate is a business process permission. Domain policies grant a combination of Get, Put, View, and Modify.

Maintaining Domain Security Policies (T41)

"Maintain domain security policies to assign permissions to security groups" is a repeatable procedure:

1. Identify the domain that secures the task, report, or data the population needs (often by Functional Area → domain).
2. Open the Domain Security Policy for that domain.
3. Add the security group (user-based, role-based, Workday-Assigned, ISSG, etc.).
4. Select permissions: View and/or Modify; Get and/or Put as appropriate.
5. Remove or reduce groups that should no longer have access (least privilege).
6. Activate Pending Security Policy Changes (T38 / section 9.4) so the edit becomes live.
7. Test with a user in the group (and a user not in the group).

 Domain: Worker Data: Public
 Policy permissions (illustrative):
   • Employee as Self .......... View
   • Manager (constrained) ..... View
   • HR Partner (constrained) .. View, Modify
   • HRIS Config (user-based) .. View, Modify
   • HRIS Integration (ISSG) ... Get, Put

(Exact delivered domain names vary; the exam cares about permission semantics and procedure, not memorizing every domain label.)

Adding permissions for a new security group

When you create a new role-based or user-based group for a new operational role:

1. Create the group and membership model first.
2. Edit each required domain policy to include the new group with the minimum permissions.
3. Edit related BP policies if the role must initiate or approve (next section).
4. Activate once as a controlled change set when ready.
5. Do not assume copying a group name into one domain is enough—roles usually need a set of domains.

Configuration scenario: Contoso creates constrained role-based group "Regional HR Partner." For worker personal data domains they grant View and limited Modify. For compensation setup domains they grant nothing—only the user-based Compensation Admin group has Modify there. For staffing-related domains used during Hire, they grant View/Modify as required by the hire checklist. After policy edits, they run Activate Pending Security Policy Changes with a comment "Add Regional HR Partner domains – 2026-Q3."

Domain Hierarchies and Inheritance Awareness

Workday domains are often arranged with parent/child relationships. Child domains may inherit permissions from parents depending on how the domain structure is delivered and configured. For Core exam purposes:

• Changing a parent domain policy can broaden or reshape access more widely than expected.
• Adding a group only on a child domain may be the least-privilege approach when only that slice is needed.
• When troubleshooting "user has access they should not," inspect both the specific domain and parent policies/groups.

You do not need advanced domain architecture expertise for Core, but you must expect that domains are structured, not a random flat list of checkboxes with no relationships.

Domain Policy Changes Are Pending Until Activated

Workday holds security policy edits in a pending state until an administrator runs Activate Pending Security Policy Changes. Until activation:

• Runtime security still reflects the last activated design.
• Users will not receive newly granted domain View/Modify/Get/Put from the pending edit.
• Removing a group on a pending edit also does not remove live access until activation.

Workday logs modifications—adding/removing groups, enabling/disabling policies—and activation creates an audit-oriented record with comment context. Related actions such as viewing latest version or pending changes help admins review before go-live. If a bad activation occurs, operational recovery may involve activating a previous security timestamp (tenant procedure)—not "undo" by wishing.

Critical distinction: Adding a user to a user-based group or assigning a role that already has live policy permissions generally does not require policy activation. Activation is for policy configuration changes. Membership and role assignment use the already-live policies.

Common Domain Policy Exam Scenarios

Scenario 1 — Permission types. Question: "Which permission types are typically granted on a Domain Security Policy?" Correct cluster: Get, Put, View, Modify. Distractors: Initiate, Approve, Rescind.

Scenario 2 — View vs Modify. Question: "What is the difference between View and Modify?" View = read in UI; Modify = write/edit in UI for the domain's securable items.

Scenario 3 — Integration. Question: "Integration must load worker phones." Domain policy needs appropriate Put (and often Get) for the ISSG—not Approve on Hire BP alone.

Scenario 4 — New group no access. Group exists, role assigned, still no domain access → group missing from domain policy, wrong permissions (View only when Modify needed), or pending not activated.

Scenario 5 — Wrong layer. User can open data (domain OK) but cannot start Hire → fix BP Initiate, not another Get permission.

Domain vs BP Permissions Comparison Table

Note: View appears in both worlds with different meanings—domain View of securable data/tasks versus BP View of events. On the exam, read the stem carefully: "view the compensation grade definition" → domain; "view the in-flight Change Job event" → BP security.

Maintenance Quality Rules

1. Least privilege: Prefer View over Modify; prefer constrained role groups over unconstrained; prefer specific domains over parent-wide grants when possible.
2. Document activations: Use meaningful activation comments for audit and rollback narratives.
3. Pair with BP policies: Operational roles almost always need both domain and BP grants.
4. Test both positive and negative paths: Member can; non-member cannot.
5. Watch for inherited breadth: Parent domain changes can surprise you.

Study Link to Other Security Tasks

• T37 told you domains live under functional areas and differ from BPs.
• T39–T40 built the groups you now place on policies.
• T41 (this section) attaches domain permissions.
• T42–T43 / T38 attach BP permissions, org access options, and activation.

If you can look at any HCM "cannot see field X" ticket and immediately ask "which domain policy, which group, View or Modify, activated?" you are exam-ready for domain security policy questions.