9.1 Functional Areas, Domains & Business Processes

9.1 Functional Areas, Domains & Business Processes

Quick Summary: Workday configurable security has three conceptual layers. Functional Areas organize security topics. Domains control access to data, tasks, reports, and fields. Business Processes control who can initiate and complete workflow steps. Security groups receive permissions only when listed on domain or BP security policies—and those policy edits do nothing until activated.

Security is one of the highest-leverage configuration topics on Workday Pro HCM Core. HCM Fundamentals carries about 60% of the 50-question exam (80% pass, 100 minutes). Tasks T37–T43 sit under Configurable Security: differentiate functional areas, domains, and business processes; maintain groups and policies; set organization access options; and activate pending policy changes. This section builds the mental model every later security task assumes.

What "Configurable Security" Means

Configurable security means customer administrators—not only Workday—can design who sees what and who can do what in their own tenant. You create and maintain security groups, edit domain security policies, edit business process security policies, set organization access options on groups, and run Activate Pending Security Policy Changes. The design goal is least privilege with role clarity: managers see their teams, HR partners see assigned populations, integration users get Get/Put on required domains, and random employees cannot edit compensation setup.

If a question emphasizes that customers (not only Workday) author groups and policies, the concept is configurable security itself.

The Three-Layer Map

 Functional Area (e.g., Staffing)
 ├── Domains ──► Domain Security Policies (View/Modify/Get/Put)
 └── Business Processes ──► BP Security Policies (Initiate/Approve/View/Rescind…)
              ▲
              │ security groups listed as permission holders
              │
         Security Groups (user-based, role-based, Workday-Assigned, others)

Exam trap: A Functional Area is not a security group and does not by itself grant View access. Domains are not the same as business process steps. Initiate/Approve belong to BP policies; Get/Put/View/Modify on data belong to domain policies (View can also appear on BP policies for event visibility—do not confuse the two policy objects).

Functional Areas

A Functional Area is a read-only topical grouping of security domains (and related business process security) delivered by Workday. Examples you will recognize in HCM:

• Staffing
• Compensation
• Time Off
• Talent
• Benefits (when in scope)
• System / Security Administration (for setup domains)

Why functional areas exist

1. Navigation: There are hundreds of domains. Grouping by area lets you open "Staffing" and work the hire-related domains instead of hunting a flat list.
2. Governance conversations: "Who owns Compensation security?" maps to a functional area owner in many operating models.
3. Policy maintenance scope: When you maintain domain or BP security, you often start from a functional area view to find the right policy set.

What admins do not do with functional areas

• They do not invent random functional areas the way they invent custom security groups.
• They do not treat a functional area as a permission target ("give the user the Staffing functional area" is imprecise exam language).
• They do enable or work with delivered functional areas as part of tenant design, then configure policies on domains and BPs underneath.

Definition to memorize: A Functional Area groups Security Domains by topic so administrators can manage delivered security in a product-aligned way. Admins configure policies on the underlying domains and business processes, not by "permissioning the area" as a single blob without policy work.

Domains and Domain Security

A Security Domain is a Workday-defined (or customer-extended in advanced cases) bundle of related securable items—tasks, reports, data elements, and fields—governed by a single Domain Security Policy. Domains are organized into Functional Areas.

What domain security answers

Domain security answers questions such as:

• Who can View worker personal data in the UI?
• Who can Modify compensation setup objects?
• Which integration accounts can Get (read via web service) or Put (write via web service) worker data?
• Who can run a particular secured report or open a secured task?

Domain permission vocabulary (preview)

Deep policy maintenance is covered in section 9.3; the model point for T37 is: domains = data/task security, enforced by domain security policies that list security groups as permission holders.

Configuration scenario: Contoso's integration team needs an Integration System User to load worker demographic updates. The security admin does not "give them Staffing." They identify the correct domains for worker data, put the Integration System Security Group on those domains with Get/Put as required, and activate pending policy changes. Without domain policy membership, the ISU cannot load data even if someone shared a report link.

Business Processes and BP Security

A Business Process (for security purposes) is a workflow type—Hire Employee, Change Job, Terminate Employee, Request Compensation Change, and so on—whose participants and actions are controlled by a Business Process Security Policy.

What BP security answers

BP security answers questions such as:

• Who may Initiate Hire for a supervisory organization?
• Who may Approve Change Job?
• Who may View an in-flight Terminate event?
• Who may Rescind a completed staffing event when policy allows rescind?

Domain vs BP: the clean split

Exam trap: Initiate is a BP security permission. If a stem asks which permission type lets someone start Hire, do not answer View or Put. View/Modify/Get/Put describe domain (data/task) access; Initiate/Approve/Rescind describe workflow participation.

Both layers often matter together. To complete Hire end-to-end, a user typically needs:

1. BP security to initiate (and other roles need approve),
2. Domain security to view/modify the data fields and tasks used on hire steps,
3. Correct security group membership (role on org, user-based membership, or Workday-Assigned membership),
4. Organization access design for constrained roles,
5. Activation of any pending policy edits.

Missing any one layer produces the classic "I am Manager but I cannot hire" support ticket.

How Security Groups Fit the Model

A security group is a set of users (or system accounts) that share the same permission target when that group is listed on a policy. Groups come in several types (user-based, role-based, Workday-Assigned, and others such as job-based or integration system groups in broader security design). Section 9.2 details the three HCM Core differentiators. For the model:

• Membership answers who is in the bucket.
• Policies answer what the bucket can do.
• Activation answers whether the latest policy edits are live.

 Who?     → Security group membership
 What?    → Domain + BP security policies
 Where?   → Constrained role + organization access options
 Live?    → Activate Pending Security Policy Changes

High-Level Relationships (Exam Scenario Language)

Workday training often asks you to relate organizations, security, and business processes. The durable relationship for HCM Core:

• Organizations (especially Supervisory Organizations) provide the context for role assignments and constrained access to populations.
• Security groups translate roles, user lists, or Workday-maintained membership into permission holders.
• Domain policies protect the data those users touch during HCM work.
• BP policies protect the workflow steps of HCM events.
• Activation publishes policy design into runtime security.

Realistic exam scenario: "A new HR Partner role was assigned on Engineering, but the partner cannot open worker compensation fields and cannot initiate Request Compensation Change." Diagnose in layers:

1. Is the partner in a role-based security group tied to that assignable role?
2. Is that group on the domain security policies for compensation data (View/Modify)?
3. Is that group on the BP security policy for Request Compensation Change (Initiate)?
4. Are organization access options correct for constrained scope?
5. Were policy edits activated?

If membership is correct but policies were edited and never activated, runtime access still reflects the old design—an extremely common exam and production pitfall.

Common Confusions Table

Study Path for Tasks T37–T43

1. T37 (this section): Name and differentiate functional areas, domains, and business processes.
2. T39–T40: Differentiate and maintain user-based, role-based, and Workday-Assigned groups; assignable roles; constrained vs unconstrained.
3. T41: Maintain domain security policies—permissions to groups.
4. T42–T43: Maintain BP security policies and organization access rights options.
5. T38: Update a security policy and Activate Pending Security Policy Changes until live.

Memorize the three-layer map before memorizing every permission checkbox. Under exam timing (~2 minutes per item), vocabulary questions ("what is a domain?" "what does a functional area do?") are free points if the model is solid.