5.1 The Business Process Framework & Definitions
Key Takeaways
- Workday delivers business process types; customers create business process definitions within those types, and a type can have many definitions but only one security policy.
- A business process definition controls what needs to happen, who does it, and when, and its header shows the effective date and the groups allowed to initiate.
- Definition tabs include Business Process Steps, Notifications, Allowed Actions by Role, Allowed Services, Related Links, and Available Rules and Fields.
- Edit a definition through Related Actions > Business Process > Edit Definition, and use View Definition to see versions with different effective dates.
- The initiation date of a submitted transaction determines which version of the definition applies, so a future-dated definition change does not affect events already under way.
Types, definitions, and policies
Three objects, three different scopes - and confusing them causes most business process misconfiguration.
| Object | Who owns it | How many |
|---|---|---|
| Business process type | Workday delivers it. Hire, Change Job, Expense Report Event | Fixed - customers cannot add new types |
| Business process definition | You configure it. The actual sequence of steps | Many per type - typically one per organization or scenario |
| Business process security policy | You configure it | Exactly one per type, shared by every definition of that type |
Memorize the asymmetry. You can have several definitions of the Hire business process routing to different security groups, but they all share one Hire security policy. Any group used in any definition must appear on that single policy.
A business process controls the what, who, and when:
- What needs to happen - tasks, actions, subprocesses
- Who needs to do what - security groups
- When it happens - the order of steps and any time frame
Anatomy of a definition
The header of a business process definition displays the effective date, the security groups allowed to initiate the process, and a button to view a visual representation of the flow.
The body carries these tabs:
| Tab | Contents |
|---|---|
| Business Process Steps | The order of steps that will execute. Steps can be sequential or parallel |
| Notifications | System and custom notifications. Configurable to trigger on process status changes, or on entry to or exit from a step; can deliver by email or inside Workday |
| Allowed Actions by Role | The actions - reviews, subprocesses - allowed in this business process |
| Allowed Services | The services allowed, such as create or reset Workday accounts |
| Related Links | References to external web pages |
| Available Rules & Fields | The condition rules and fields usable in conditional rule logic on this process |
The step columns
Every business process uses the same set of configurable fields, though a field only appears if it is relevant to that process.
| Column | Meaning |
|---|---|
| Step | The task in the business process |
| Order | The execution order of the step |
| If | Conditions the event must satisfy for the step to occur |
| Type | The step type - Action, Service, To Do, and so on |
| Specify | Further definition for certain step types, e.g. Action - Propose Compensation Hire |
| Optional | If selected, the assignee may skip the step. The next step does not begin until the user completes the optional step or marks it skipped |
| Group | The security groups responsible for the step. Limited to groups on the business process security policy |
| All | If selected, all users in the security group must approve |
| Run As User | The user for a Batch or Integration step type |
| Due Date | Elapsed time from step initiation to completion. Workday does not automatically enforce due dates |
| Due Date is Based on Effective Date | Measures elapsed time from the event effective date instead |
| Complete | Identifies the completion step, making the data available to other systems such as payroll or the general ledger |
Two of these carry disproportionate exam weight. Optional does not mean skippable-by-silence - the process waits until the assignee either completes or explicitly marks the step skipped. And due dates are informational: Workday will not escalate or auto-advance a step because a due date passed.
The Group column is also the mechanical link back to security: the prompt only offers groups already on the business process security policy. If the group you want is not in the list, the fix is on the policy, not on the definition.
Editing a definition
From the definition's Related Actions, select Business Process > Edit Definition. Workday distinguishes two modes:
| Edit mode | View mode |
|---|---|
| Add, modify, or remove steps | Read the definition as of a date |
| Configure order, group, due date, required or optional | Reach each step's Related Actions to configure that step |
| Assign the completion step | Run the View Definition report |
| Maintain condition rules, step delays, advanced routing, step labels |
Note the split: you edit the definition in Edit mode, but you configure most per-step settings from a step's Related Actions while viewing the definition. Administrators hunting for "Maintain Step Conditions" inside Edit mode do not find it.
Effective dates work two different ways
This is a genuine source of exam confusion because the same phrase means two things.
On the definition. The effective date of a business process definition is the date a proposed change becomes available. A future effective date means the change does not take effect until that date. Effective dates apply to business processes, consolidated approvals, and condition rules. When you view a definition it displays as of today, and you can enter a future date to view a version not yet in effect. Use View Definition from Related Actions to see definitions of varying effective dates.
On the event. When you execute a business process, the effective date is the date the event takes effect - for a pay raise, the date the raise begins.
The rule that ties them together: the initiation date of the transaction determines which version of the business process definition is used. Change a definition today with a future effective date and events already in flight continue under the old version. This is why "I fixed the definition but the stuck event still routes to the wrong group" is expected behavior, not a bug.
Check what the type allows before you configure
Each business process type permits different configurations. The Business Process Configuration Options report is the authoritative source, and it tells you:
- Organization types for which the business process is valid
- Allowable actions and approvals
- Options on saving after an available action
- Restrictions - for example, you cannot have a Change Benefits for Life Event subprocess before the completion step
- Prerequisite actions
- Business processes that are strictly subprocesses
- Allowed subprocesses for the type
- Allowed mass actions such as rescind, correct, cancel, and approve
- Which incomplete business processes are cancelable
It also displays which step types are available for each business process type - because not every step type is available on every type.
Habit worth building: run Business Process Configuration Options before designing a definition rather than after a configuration is rejected. On the exam, it is the correct answer whenever a question asks how to determine what a business process type supports.
An organization has four separate Hire business process definitions routing to different approval groups. How many business process security policies apply?
A definition change is saved with an effective date of next month. An event initiated today is routing to the old approval group. What is the correct assessment?
Which report tells an administrator which step types, subprocesses, and mass actions a specific business process type supports?