3.1 Components of the Configurable Security Framework

The framework in one paragraph

Workday provides a security framework that lets you configure what users can view and what actions they can take. The system is organized into functional areas. Functional areas are divided into domains and business process types. All three are Workday-owned and delivered - customers cannot add, remove, or rearrange them. What customers configure is user access, by creating and configuring users and security groups, and attaching those groups to security policies.

The four components

1. Functional areas

The top-level grouping - Staffing, Benefits, Core Compensation, Financial Accounting, Procurement, and so on. Each contains domains and business process types.

2. Domains

A domain is a collection of items that share the same security: tasks, delivered reports, report data sources, report fields, and web service operations. Workday determines which items sit in each domain, and a given item may be in more than one domain. You cannot change the delivered items in a domain.

Domain security policies control access to tasks, reports, data, and web services. The permissions define who can run a report, view the data in a report, or complete a task.

3. Business process types

Business process types represent events or transactions - Hire, Change Job, Expense Report Event. Workday determines the available types. You configure the business process definition steps, such as approvals and actions, and which security group each step routes to.

Business process security policies allow you to determine who can participate in a business process workflow. The permissions define who can initiate, approve, cancel, and rescind business process events.

4. Security groups

A security group grants Workday access to a collection of system users. Users become members in one of three ways:

How the pieces connect

              FUNCTIONAL AREA  (Workday-delivered)
                       │
        ┌──────────────┴──────────────┐
        ▼                             ▼
    DOMAIN                    BUSINESS PROCESS TYPE
        │                             │
        ▼                             ▼
 Domain Security Policy      BP Security Policy
        │                             │
        └────────► SECURITY GROUP ◄───┘
                        │
                     USERS

Add a security group to a domain security policy to grant access to the secured items in that domain. Add a security group to a business process security policy to grant the ability to participate in that type of business process.

What can and cannot be configured

Custom domains: Workday provides 200 custom domains in the System functional area, which let you configure security permissions for custom items such as custom dashboards and custom objects. This is the escape hatch when you need to secure something you built.

The five steps for configuring access

Workday's own courseware states the process as five steps, and this ordering is examinable:

1. Identify users
2. Create security groups
3. Edit security policies
4. Activate Pending Security Policy Changes
5. Test changes

Step 4 is where administrators lose time

When you change a security policy, the change is saved but pending until you run the Activate Pending Security Policy Changes task. Until then, nothing has changed for any user.

The exception worth memorizing: if you add a user to a security group that already has the security policy permissions, you do not need to activate changes. Membership changes take effect immediately; policy changes need activation.

That single distinction resolves a large family of exam scenarios. "I added Maria to the HR Partner group and she still cannot see the task" is a policy problem or a role-assignment problem, not an activation problem. "I added the HR Partner group to a domain and nobody can see the task" is an activation problem.

Enabling domains and new business process types

Deployments and releases both leave you with security that is delivered but not switched on.

A suspended domain. If a domain security policy shows the status "Suspended - Policy not enabled," enable it before you can grant access to the items it controls. From the domain security policy's Related Actions, select Domain Security Policy > Enable, confirm, and select OK. Then edit the permissions to grant View or View/Modify to the appropriate security groups - and activate.

Workday notes that it rarely delivers new domains already enabled or with security groups in place: Workday supplies the framework and the customer decides if, when, and how to take it up. When Workday does pre-enable a domain, it specifies whether you must set up permissions.

New business process types. When a release delivers a new business process type, you may need to create the business process security policy and set up its permissions, and you will likely need to create the default definition as well.

Cross-application consequences

All Workday applications in a tenant use the same security configuration, so a security change made for one application may affect others. Workday's illustration: remove the Report Writer security group from the Custom Report Creation domain security policy and its members can no longer create custom reports at all, regardless of functional area.

This is why step 5 - test changes - is not optional politeness. After activating, verify in a nonproduction tenant using proxy, and check more than the one scenario that prompted the change.