Workday Security Groups: Designing Role-Based Access

Good Workday security design starts from jobs people actually do, not from the list of security groups. Map each HR, payroll and manager responsibility to the smallest set of domains and business process permissions it needs, choose role-based, constrained groups wherever access should follow the organization, and activate and test every policy change before it reaches production.

Key takeaways

• Workday controls access through security groups assigned to domain security policies and business process security policies, so design both layers together.
• Prefer role-based, constrained groups for HR partners and managers; reserve user-based, unconstrained groups for a short list of administrators.
• Policy edits stay pending until someone runs Activate Pending Security Policy Changes, which gives you a natural review gate.
• Test access with real personas in a sandbox and keep a rollback plan using a previous security timestamp.

How does Workday security actually work?

Workday's configurable security framework has three moving parts. Security groups hold people (or integration systems). Domains bundle related tasks, delivered reports, report data sources and web service operations that share the same security, and a domain security policy says which groups can view or modify those items. Business process security policies say which groups can initiate, approve, cancel, rescind or otherwise act on each step of a process such as Hire or Change Job.

Two details trip up new admins. First, Workday decides which items live in a domain, and you cannot move them, so you secure the domain, not the individual report. Second, according to Workday's own course material, business process permissions do not inherit: each subprocess has to be configured on its own. A role that can approve a hire may still be unable to complete the onboarding subprocess unless you grant it explicitly.

Group membership also comes in three flavors: Workday-assigned (for example self-service groups), manually assigned (user-based and integration system groups) and derived (role-based, job-based and location membership groups). Derived groups are the backbone of a maintainable design, because access changes automatically when a worker moves jobs or roles.

Which security group types should you use for each audience?

Constrained groups limit access to a subset of target instances, usually by organization. Unconstrained groups see every instance. The table shows a pattern many HRIS teams start with; adjust it to your organization model and confirm the group types available in your tenant.

Audience	Suggested group type	Context	Why
Employees	Workday-assigned self-service	Own data only	Delivered and low maintenance
Managers	Role-based	Constrained to supervisory organization	Access follows the manager role assignment
HR business partners	Role-based	Constrained to assigned organizations	Reassigning the role moves access with it
Payroll specialists	Role-based or job-based	Constrained to pay group or company	Keeps payroll access tied to the population they process
HRIS and security admins	User-based	Unconstrained	Small, named list that is reviewed often
Integrations	Integration system group	Usually unconstrained	Grant only the Get and Put operations each integration needs

The common mistake is solving every access request with a new user-based group. User-based groups are unconstrained and stay with the person until someone removes them, which is how a former payroll analyst who moved to finance keeps seeing salary data a year later.

How do you apply least privilege without breaking HR operations?

NIST defines least privilege as limiting users to the access that is minimally necessary to accomplish assigned tasks. In Workday terms, that means granting View instead of View and Modify where people only report on data, and constraining groups instead of granting tenant-wide access. A practical sequence:

1. Inventory responsibilities. List what each role must do: hire, change compensation, run payroll audits, approve time. Interview the people doing the work, not just their managers.
2. Map responsibilities to domains and processes. For each responsibility, identify the domains and business process steps involved. Use your tenant's security reports to see which policies currently include each group.
3. Separate duties that should not combine. NIST's separation of duty principle applies directly: the person who enters a compensation change should not be the only approver, and whoever maintains bank account data should not also release payments.
4. Decide the constraint. Supervisory organization, company, location or pay group. Pick the one that matches how the work is divided.
5. Document exceptions. Every unconstrained grant gets an owner, a reason and a review date.

Field and domain sensitivity is not uniform. Compensation, government IDs, bank details, medical and leave data deserve tighter policies than job titles. If you also build custom reports on these domains, align your security model with your Workday reporting governance strategy so report sharing does not quietly undo your restrictions.

How should you test and activate security changes?

Workday saves security policy edits as pending. They take effect only when someone runs the Activate Pending Security Policy Changes task, and each activation creates a timestamped security evaluation moment. If a change causes problems, the Activate Previous Security Timestamp task can revert policies to an earlier state. Changes to security group membership and definitions, however, take effect immediately, so treat those with the same care.

A testing routine that catches most errors

• Build the change in a sandbox first and record the pending changes before activating.
• Test with personas: an employee, a manager two levels up, an HR partner for one region, a payroll specialist and an integration account.
• For each persona, check three things: can they do the job, can they see data outside their scope, and can they act on business process steps they should not.
• Include a comment on every activation that references the ticket number, so the audit trail tells a story.
• Repeat the critical persona tests after each Workday feature release, since new items can appear in domains you already secure.

Condition rules and step conditions in business processes interact with security. A step routed to a group that lacks permission will stall. Our guide to configuring condition rules in Workday covers the routing side.

What should a quarterly Workday access review include?

Access drifts. People change roles, contractors stay past their end date and emergency grants become permanent. A quarterly review keeps the model honest.

Check	What to look for	Owner
User-based group members	Anyone who no longer needs admin access	HRIS lead
Unconstrained grants on sensitive domains	Compensation, banking, personal data access beyond need	Security admin with HR and payroll leaders
Integration system users	Unused integrations and broad Put permissions	Integration owner
Terminated or transferred workers	Lingering manual group memberships	HRIS analyst
Recent activations	Changes without a ticket or approval	Internal audit or controls team

Security is part of a broader risk program. For the human side of that partnership, see how HR and risk management work together on cybersecurity.

Frequently Asked Questions

What is the difference between constrained and unconstrained security groups in Workday?

A constrained group limits members to a subset of target instances, usually the workers in organizations they are assigned to. An unconstrained group grants access to every instance in the tenant. Managers and HR partners normally belong in constrained, role-based groups, while unconstrained access should be limited to a small number of administrators and integrations with a documented business reason and a regular review.

Do Workday security changes take effect immediately?

Policy changes do not. Edits to domain and business process security policies stay pending until the Activate Pending Security Policy Changes task runs. Changes to security groups themselves, such as adding a member or changing a group definition, take effect immediately. Plan reviews around that difference, and always add a descriptive comment when activating so later audits can trace why the change happened.

Can I roll back a bad Workday security change?

Yes, for policy changes. Each activation creates a timestamp, and Workday provides an Activate Previous Security Timestamp task that reverts policies to an earlier point. It does not undo group membership changes, which take effect immediately. Confirm the exact behavior in your tenant and your Workday Community documentation before you rely on it in an incident runbook.

How often should we review Workday security access?

Many HRIS teams review privileged and user-based group membership quarterly, and the full role model at least once a year or after a reorganization. Also re-test critical personas after each feature release. If your organization is subject to financial controls audits, your auditors may set the review frequency, so align your calendar with their requirements.

Next steps for your Workday security model

Start with an export of every security group and its members, then flag user-based and unconstrained groups on sensitive domains. Pick one high-risk area, such as compensation or bank account data, and redesign it with role-based constrained groups in a sandbox. Write a persona test script, activate with a ticket reference, and schedule your first quarterly review. For more admin guides, browse our Workday guides hub.

Last reviewed: October 2026.

Sources

• Configurable Security Framework, Workday Education
• Least Privilege (Glossary), NIST Computer Security Resource Center
• Separation of Duty (Glossary), NIST Computer Security Resource Center