10.1 Organizations, Security & BP Relationships

10.1 Organizations, Security & BP Relationships

Quick Summary: Workday business processes do not run in isolation. Organizations supply the context (especially Supervisory Orgs for HCM staffing). Security decides who may Initiate, Approve, View, and Rescind. Business process definitions decide which steps run. All three must align or the process will not start—or will start for the wrong people.

Business Process Fundamentals contributes 10 of 50 questions (20%) on the Workday Pro HCM Core exam (80% pass, 100 minutes). Tasks T44–T46 establish the framework vocabulary and relationships before later chapters dig into steps, approvals, condition rules, and BP management. This section is the relationship map: how organizations, security, and business processes fit together at a high level.

Why the Triangle Matters

Every successful HCM workflow answers three questions at once:

1. What workflow runs? → Business process type and the definition selected for this initiation (default, org-specific, or rule-based—section 10.2).
2. In what organizational context? → Typically a Supervisory Organization (and related org assignments on the position) that supplies manager chains, role holders, and constrained security scope.
3. Who is allowed to participate? → Business Process Security Policies and Domain Security Policies listing security groups whose membership comes from roles on orgs, user lists, or Workday-Assigned criteria.

                 Organizations
              (context & role holders)
                      │
         ┌────────────┼────────────┐
         ▼            │            ▼
   Security groups    │     Population scope
   (who is in bucket) │     (org access options)
         │            │            │
         └──────► BP + Domain policies ◄──┘
                      │
                      ▼
              Business Process
         (type → definition → event → steps)

If you only configure definitions and ignore security, nobody can initiate. If you only grant Initiate and ignore org context, constrained partners may open the wrong population—or no population. If you only assign roles and never attach groups to policies (or never activate policy edits), membership is ornamental.

Exam framing for T44: Stems that say "high-level relationships between organizations, security, and business processes" want this triangle—not a deep dive into approval-chain step types (later) and not a pure domain View/Modify definition question (Chapter 9).

Organizations: Context for Process and People

Supervisory Organizations as the HCM backbone

For most staffing business processes—Hire, Change Job, Terminate, Create Position, and related movements—the Supervisory Organization is the primary organizational context:

• The position or job being staffed sits in a Supervisory Org.
• The Manager role on that org is the default people leader for approvals and team visibility.
• HR Partner, Compensation Partner, and other supporting roles are often assigned on supervisory nodes to cover a population.
• Constrained role-based security groups resolve membership and scope from those role assignments and organization access options.

Non-supervisory orgs (Company, Cost Center, Region, Location, Custom) still matter for data defaults, eligibility, financial attribution, and some routing rules, but the exam's relationship story for "who acts on staffing events" almost always starts with the supervisory tree.

What "org context" means at initiation

When a user starts Hire for a position in Engineering → Platform Team:

Configuration scenario: Contoso's Store Managers hold the Manager role on each Store Team supervisory org. They can initiate Hire only for their store because: (1) BP security grants Manager groups Initiate on Hire, (2) the groups are constrained, (3) organization access options limit them to their assigned org (and subordinates if designed), and (4) they only hold Manager on their store. Corporate HR Partners assigned on Region Leadership orgs cover many stores without being unconstrained enterprise-wide.

Security: Who Can Initiate and Act

Security is not a single switch. For business processes, separate what BP security does from what domain security does—Chapter 9 material that BP Fundamentals reuses constantly.

Business Process Security Policies

A Business Process Security Policy is maintained per business process type. It lists which security groups may perform workflow actions such as:

Who can initiate is therefore:

1. A person in a security group that is granted Initiate on that BP type's security policy, and
2. That membership is meaningful in the organization context (for constrained role-based designs: role assigned on the right org + org access options), and
3. Any pending policy edits were activated if the policy was recently changed, and
4. Domain security allows them to open the tasks and fields the initiation requires.

Exam trap: "Who can initiate" is not answered by "whoever is listed as a step in the definition." Definitions describe steps; security policies authorize participation. A definition may include Manager Approval, but if the Manager group lacks Approve on the BP policy, the step cannot be completed correctly.

Domain security still participates

Even with perfect Initiate rights, a user who cannot View/Modify required worker, job, or compensation domains will stall mid-process. Integrations need Get/Put. The relationship model is:

Business Processes: What Runs

A business process in framework language is the combination of:

• a type (Hire Employee, Change Job, …),
• one or more definitions (the configured step lists),
• runtime events (instances), and
• steps inside each running event.

Those terms are defined in full in section 10.3. For relationships, remember only this: definitions shape the path; they do not replace security or invent org membership.

 Type: Hire Employee
   └── Definition selected (default / org-specific / rule-based)
         └── Event: Hire of Alex Rivera into Platform Team
               └── Steps: Propose Hire → HR Review → Manager Approve → …

Organization context influences which definition may be selected (org-specific and rule-based designs) and which people security resolves as participants. Security influences whether those people may perform the step actions the definition expects.

High-Level Relationship Statements (Memorize These)

Use these as quotable exam answers:

1. Organizations provide context for staffing processes and for role-based security membership and population scope.
2. Security policies grant permissions to security groups; groups do not grant access by themselves.
3. BP security controls workflow participation (Initiate, Approve, View, Rescind); domain security controls data/task access.
4. BP definitions control which steps run and in what order; they assume security and org design will supply real participants.
5. Initiation requires BP Initiate permission in the correct org context—not merely knowing the Hire task name.

Relationship Table for Exam Scenarios

Worked Scenario Bank (T44 Style)

Scenario A — Triangle success

Northwind assigns Manager on Assembly Line 1, uses a constrained Manager security group on Hire Initiate and Approve, activates policies, and uses the default Hire definition with a Manager Approval step. Result: the Assembly Line 1 manager can initiate and approve Hire for that org's positions. All three layers cooperate.

Scenario B — Security missing

Same org design, perfect Hire definition, but Manager group was never added to Hire Initiate. Result: managers cannot start Hire. Definition and org are fine; BP security is not.

Scenario C — Org context missing

HR Partner group has Initiate on Hire and is constrained, but nobody assigned HR Partner on the new "Cloud Services" supervisory org after a reorg. Result: partners who should cover Cloud Services cannot act for that population. Policy exists; org role assignment does not.

Scenario D — Domain gap

User can initiate Change Job (BP Initiate OK) but cannot open compensation fields on a step. Result: domain security (or related field security) is incomplete. BP relationship includes domains, not only BP policies.

Scenario E — Activation gap

Admin adds HR Partner to Hire Initiate today and forgets Activate Pending Security Policy Changes. Result: runtime still follows the last activated policy—partners still blocked. Pending policy edits are not live.

Who Can Initiate: Decision Checklist

When an exam item asks who can initiate a business process based on security and org context, walk this checklist:

1. Identify the business process type (Hire, Change Job, Terminate, …).
2. Confirm a definition will be selected (default at minimum—details in 10.2).
3. Identify which security groups have Initiate on that type's BP security policy.
4. Determine how membership works for those groups (role-based constrained, unconstrained, user-based, Workday-Assigned).
5. For constrained role-based groups, verify role assignment on the relevant organization and organization access options.
6. Confirm domain access needed to complete initiation screens.
7. Confirm activation if policies were recently edited.

The person who "should" initiate from a process-design perspective is not always the person who can initiate. Design intent lives in definitions and operating procedures; can is a security + org fact.

Common Confusions Table

How This Section Connects Forward

Master the triangle before memorizing step letters. Under ~2 minutes per question, T44 items reward instant separation of context (org), permission (security), and workflow design (BP).