9.4 BP Security Policies, Org Access & Activation

9.4 BP Security Policies, Org Access & Activation

Quick Summary: Business Process Security Policies decide who may Initiate, Approve, View, Rescind, and otherwise act on HCM workflows. Organization access options on security groups decide which orgs constrained members can reach. After you update domain or BP policies, you must run Activate Pending Security Policy Changes—until then, pending edits have no effect.

Tasks T38, T42, and T43 turn security design into live behavior. Domain permissions (section 9.3) answer data/task access; this section answers workflow participation, population scope options, and the activation gate that every implementer must remember under exam pressure.

Business Process Security Policies (T42)

A Business Process Security Policy is maintained per business process type (for example Hire Employee, Change Job, Terminate Employee, Request Compensation Change). It lists which security groups may perform which workflow actions.

Core BP permission concepts

Exact action lists vary by process, but Core exam language repeatedly hits Initiate, Approve, View, and Rescind as the mental model for BP security.

Maintaining BP security policies

Parallel to domain maintenance:

1. Open the Business Process Security Policy for the process type.
2. Add the security group that should participate.
3. Grant the correct actions—e.g., Managers Initiate and Approve Hire; HR Partners Initiate, Approve, View, maybe Rescind per design.
4. Remove groups that should no longer act.
5. Activate pending policy changes.
6. Test initiation and approval with real role holders.

 Hire Employee — BP Security Policy (illustrative)
   Initiate:  Manager (constrained), HR Partner (constrained)
   Approve:   Manager (constrained), HR Partner (constrained)
   View:      HR Partner (constrained), HRIS Config (user-based)
   Rescind:   HR Partner (constrained), HRIS Config (user-based)

Configuration scenario: Store managers must start Hire for their store teams but must not rescind completed hires. HR Partners at region level may initiate, approve, view, and rescind. The admin places constrained Manager groups on Initiate/Approve only, and constrained Regional HR Partner groups on Initiate/Approve/View/Rescind, then activates.

BP security vs domain security during a real event

Completing Hire successfully usually requires both:

Exam trap: "Which permission lets a user start Hire?" → Initiate on the BP security policy, not Put, not Functional Area, not "View domain only."

How BPs interact with configurable security (preview of later BP track)

Business Process definitions (steps, approvals, routing) decide what the workflow looks like. BP security policies decide which groups are allowed to perform those step types. A perfectly designed approval chain still fails if the approver's group is not allowed to Approve. Conversely, granting Approve without routing the step to that role still produces empty inboxes. Security and BP configuration are partners—later chapters (BP Fundamentals track, ~20% of the exam) deepen routing; Core security tasks still require the policy side.

Security Group Access Rights to Organization Options (T43)

For constrained role-based (and related) designs, membership alone is not the full population story. Organization access options—often described as security group access rights relative to organizations—control which organizations' people and data the group can reach.

Why org access options exist

Consider HR Partner assigned on Operations supervisory org:

• Should they see only workers in Operations itself?
• Or Operations plus all subordinate supervisory orgs?
• Should access apply only along the supervisory hierarchy, or also consider other org types depending on configuration?

Access rights to organization options answer those design questions. They are a major reason constrained security is powerful: the same "HR Partner" role group can be safe when org options limit scope, or overly broad if options include more of the tree than intended.

Practical implications

Configuration scenario: Global Retail assigns HR Partner on "West Region Leadership." Organization access options are set so the partner includes subordinate store teams under West Region. Without subordinate inclusion, the partner would only see the leadership node and fail to support store workers—even though BP Initiate and domain View were configured correctly.

Exam framing: When a stem mentions security group access rights to organization options, think population scope for constrained access, not domain Get/Put checkboxes and not activation comments.

Constrained + org options + policies = complete design

 Role assignment on org
        +
 Constrained role-based security group
        +
 Organization access options (which orgs/subordinates)
        +
 Domain policies (View/Modify/Get/Put)
        +
 BP policies (Initiate/Approve/View/Rescind)
        +
 Activate Pending Security Policy Changes
        =
 Live, least-privilege HCM access

Miss any layer and the symptom appears as "security is broken" even when only one layer is wrong.

Updating a Security Policy (T38)

"Update a security policy" means editing either:

• a Domain Security Policy, or
• a Business Process Security Policy,

…to add/remove groups or change allowed permissions/actions. Workday records the modification (who/when, add/remove groups, enable/disable patterns) and holds the result as pending relative to the last activated baseline.

Safe update workflow

1. Document intent: Which role needs what access, and why.
2. Identify policies: Domains and BPs in the Functional Area(s) involved.
3. Edit policies: Add groups/permissions; remove excess.
4. Review pending changes before activation (view pending / latest version patterns).
5. Activate Pending Security Policy Changes with a clear comment.
6. Test positive and negative access.
7. If activation was wrong, follow tenant recovery procedures (for example activating a previous security timestamp)—not a casual silent undo.

Activate Pending Security Policy Changes (exam-critical)

Activate Pending Security Policy Changes is the task that publishes pending domain and BP security policy edits into runtime security.

Facts to memorize

This is one of the highest-value exam sentences in the chapter: Security policy changes do not take effect until you activate pending security policy changes.

What activation is not

• Not the same as Assign Roles
• Not the same as creating a security group
• Not required for every HR transaction
• Not a report-only "preview forever" step—you must complete activation for go-live of policy edits
• Not BP definition reordering (letters/steps)—that is BP configuration, though BP security policy still needs activation when edited

Activation scenario bank

Scenario A: Admin adds Manager group to Hire Initiate. Managers still cannot start Hire. Cause: pending not activated (or wrong group/constraint).

Scenario B: Admin activates successfully; one manager still fails. Cause: role not assigned on that manager's Sup Org, org access options wrong, or domain Modify missing for hire fields—not "activation broken."

Scenario C: Admin removes a group's Modify on a domain, forgets activation; users still modify. Cause: old policy still live until activation.

Scenario D: "Do user-based membership adds require activation?" Generally no for membership against already-activated policies. Yes if you also edited the policies that grant that group access and those edits are still pending.

Domain Policy vs BP Policy vs Activation — Master Table

End-to-End Exam Case Study

Business need: Compensation Partners for EMEA must propose compensation on Change Job for EMEA orgs, view worker compensation data, and approve compensation-related steps, but must not modify global compensation grade setup and must not access Americas populations.

Design walkthrough:

1. Group type: Constrained role-based security group for assignable role Compensation Partner.
2. Role assignment: Assign Compensation Partner on EMEA supervisory (or designated) orgs.
3. Org access options: Include subordinate EMEA orgs as required; do not use unconstrained enterprise access.
4. Domain policies: View/Modify on worker compensation domains used in transactions; no Modify on compensation grade setup domains (or View-only if inquiry needed).
5. BP policies: Initiate/Approve/View as required on Change Job / compensation request processes.
6. Activate Pending Security Policy Changes with comment "EMEA Compensation Partner security – go-live."
7. Test: EMEA partner succeeds; Americas partner/role holder does not see EMEA; setup admins still control grades.

If any exam stem stops at step 6 omitted, the correct answer is almost always that pending policy changes must be activated or that access remains unchanged until activation.

Common Confusions Table

Final Security Checklist for HCM Core

1. Differentiate Functional Area / Domain / Business Process (T37).
2. Choose user-based vs role-based vs Workday-Assigned (T39).
3. Maintain groups and assignable roles; decide constrained vs unconstrained (T40).
4. Maintain domain policies View/Modify/Get/Put (T41).
5. Maintain BP policies Initiate/Approve/View/Rescind (T42).
6. Set organization access options for group scope (T43).
7. Update policies carefully and Activate Pending Security Policy Changes (T38).

Internalize that checklist and you can answer nearly every Configurable Security item on the 50-question, 100-minute, 80% Workday Pro HCM Core exam without guessing between similar-sounding permissions.