4.1 Domain Security Policies & Permissions

What a domain security policy does

Each domain has its own domain security policy, and that policy controls a user's access to the securable items in the domain. You grant access by adding a security group to the policy with the appropriate permission.

Domains secure all delivered items - data sources, report fields, delivered reports, tasks, and web service operations. To access an item, a user must belong to a security group that has access to the domain securing that item. Workday determines the contents of a domain; you cannot change them.

Workday's illustration: the Worker Data: Active Employees domain contains three securable items - the Active Employees report, the Employee Talent Analysis report, and the All Active Employees data source. The HR Partner security group is on that policy, so Logan McNeil (an HR Partner) can run both reports and build reports on that data source.

Items are secured individually, and sometimes twice

This table from Workday's reporting courseware is worth internalizing, because it shows that the thing being secured is often much smaller than the report a user is trying to run.

Running one custom report can therefore depend on several domains at once - the domain securing the data source, plus a domain for each report field used, including fields used only in a filter. This is the single most productive fact for troubleshooting reporting access, and it is developed further in section 8.4.

Remember too that a given item may be in more than one domain. Access through any one of them is sufficient, which is why removing a group from one policy sometimes changes nothing.

The permission model

Domain security policies express permissions in two registers.

• View grants read access to the secured items - running a report, seeing a field's data.
• Modify grants the ability to change data through the tasks the domain secures. Modify implies the ability to view what you are changing.
• Get is the integration-side read permission, used by web service operations retrieving data.
• Put is the integration-side write permission, used by web service operations creating or updating data.

Why this matters for integrations: an Integration System Security Group needs Get and Put on the relevant domains, not View and Modify. Granting a user-facing permission set to an ISSG is a classic misconfiguration that produces a working login and a failing integration.

Editing a domain security policy

1. Find the domain. Search for it directly, or use the Functional Areas report or Maintain Functional Areas task to locate the domain within its functional area.
2. From the domain security policy's Related Actions, select Domain Security Policy > Edit Permissions.
3. Add or remove security groups in the View and Modify (or Get and Put) columns.
4. Save. The change is now pending, not live.
5. Run Activate Pending Security Policy Changes.
6. Test.

The activation step reviews every pending change in the tenant, not only yours. Read the list before confirming - in a shared tenant you may be activating a colleague's half-finished work alongside your own.

Enabling a suspended domain

During a deployment, or when Workday delivers a new domain, you may find a policy with the status "Suspended - Policy not enabled." Until it is enabled you cannot grant access to the items it controls.

1. From the domain security policy's Related Actions, select Domain Security Policy > Enable.
2. Confirm the change and select OK.
3. Edit the permissions to grant View or View/Modify to the appropriate security groups.
4. Run Activate Pending Security Policy Changes.

Enabling a domain is itself a security change and requires activation. Administrators regularly enable a domain, add groups, and stop - then wonder why nothing happened.

Finding out which policy controls an item

Three reports answer the question "why can this person not do this?"

The standard workflow is to run the first against the item the user cannot reach, run the third against the user, and compare the two lists. If they do not overlap, you have found the gap. Section 4.3 develops this into a full troubleshooting method.

Design habits that keep policies maintainable

• Grant to groups, never to individuals. Domain security policies accept security groups only, which is a feature - it forces you to name the responsibility rather than the person.
• Prefer the narrowest permission that works. View before Modify; Get before Put.
• Check the cross-application impact before removing a group. Because all applications share one security configuration, a removal you scope mentally to one functional area applies everywhere.
• Use custom domains for custom items. Workday delivers 200 custom domains in the System functional area precisely so custom dashboards and custom objects do not have to be crammed into a delivered domain.
• Activate deliberately. Batch related edits, then activate once, then test - rather than activating after each small change.