10.3 Definition, Type, Event & Step
Key Takeaways
- A business process type is the delivered kind of process (Hire Employee, Change Job, Terminate)—the catalog entry security policies and definitions hang from.
- A business process definition is the configured ordered set of steps for a type; customers maintain default, org-specific, and rule-based definitions under the type.
- A business process event is a single runtime instance of a selected definition for a specific subject and effective context (for example, one worker's Hire).
- A step is an individual unit of work inside a definition/event—actions, approvals, To Dos, notifications, subprocesses, and related step types.
- Relationship chain: Type → Definition (selected) → Event (instance) → Steps (work units); Hire and Change Job scenarios use the same chain with different types.
10.3 Definition, Type, Event & Step
Quick Summary: Type = what kind of process. Definition = configured step list for that type. Event = one live run for a real subject. Step = one unit of work inside that run. Hire and Change Job share this vocabulary; only the type (and its definitions) change.
Task T46 is vocabulary with operational consequences. If you confuse definition with event, you will misread every management, routing, and security question that follows. This section locks the four terms and walks Hire and Change Job end-to-end.
The Four Terms at a Glance
| Term | What it is | Config-time or run-time? | Example |
|---|---|---|---|
| Business Process Type | Kind/category of process delivered in the product | Catalog / setup anchor | Hire Employee; Change Job |
| Business Process Definition | Configured ordered steps for a type (default, org-specific, or rule-based) | Configuration | Default Hire definition with steps A–G |
| Business Process Event | One instance of a selected definition for a specific subject | Runtime | Hire of Jordan Lee effective 2026-09-01 |
| Step | Single unit of work in a definition and its event | Both (defined in definition; executed on event) | Manager Approval step on that Hire |
TYPE (Hire Employee)
└── DEFINITION (Default Hire — steps configured here)
└── EVENT (Hire: Jordan Lee → Platform Team)
├── Step: Initiate / Propose
├── Step: HR Partner Review
├── Step: Manager Approval
└── Step: …
One-sentence chain: You configure definitions under a type; when a user initiates, Workday creates an event that executes the steps from the selected definition.
Business Process Type
A business process type is the delivered process kind—the named workflow category such as:
- Hire Employee
- Change Job
- Terminate Employee
- Request Compensation Change
- Create Position
- Contract Contingent Worker
- End Contingent Worker Contract
What types are for
| Concern | How type is used |
|---|---|
| Security | Business Process Security Policies are maintained per type (who may Initiate/Approve/View/Rescind Hire vs Change Job) |
| Configuration | Definitions are created under a type |
| Analytics / inbox | Events are classified by type for reporting and work queues |
| Product behavior | Types carry delivered business meaning (staffing vs compensation vs absence) |
What a type is not
- Not a single running hire of one person (that is an event)
- Not the list of approval steps (that is a definition's steps)
- Not a security group
- Not a Supervisory Organization
Exam trap: "Hire Employee" as a type is shared by the whole tenant. Ten different workers hired this week create ten events, still one type, possibly sharing one definition (or selecting different definitions per section 10.2).
Business Process Definition
A business process definition is the configured blueprint of steps for a type. When you "edit the Hire process," you are almost always editing a definition: adding an approval, reordering steps with letters, attaching condition rules to steps, setting advanced routing, help text, notifications, and so on (later chapters).
Definition facts for T46
- Multiple definitions can exist per type (default, org-specific, rule-based).
- Exactly one definition is selected per initiation (section 10.2).
- Definitions are configuration objects; they do not themselves "complete" until someone runs an event.
- Changing a definition affects future events that select that definition; in-flight events already follow the definition version/context they started with (operational awareness for go-lives).
| Definition question | Good answer |
|---|---|
| Where do I add a second approval for executives? | On the appropriate definition (often rule-based) under the type |
| Where do I set who may Initiate? | On the BP security policy for the type, not "inside the definition" as a substitute for security |
| What selects among definitions? | Rules, org context, then default |
Configuration scenario: Contoso's HCM analyst opens the Hire Employee type, edits the default definition to insert a background-check To Do before Manager Approval, and tests by initiating a new Hire event. The type did not change names; the definition's step list changed; each test creates a new event.
Business Process Event
A business process event is a runtime instance—one concrete execution of a selected definition for a specific business subject and context.
Event characteristics
| Characteristic | Detail |
|---|---|
| Subject | The worker, position, or other object the process is about |
| Status | In progress, completed, canceled, rescinded (as applicable) |
| Participants | Who initiated; who has open steps; who already acted |
| Effective context | Effective dates and org/job context captured for the transaction |
| Audit | History of step completions, comments, and approvals |
Event vs definition (highest-frequency confusion)
| If you mean… | Use the word… |
|---|---|
| The configured step design for Hire | Definition |
| Jordan Lee's hire going through approvals this week | Event |
| All hires as a process category | Type |
| The Manager Approval waiting in inbox | Step (on an event) |
Exam trap: "How many events occur when five employees are hired?" → Five events (same type, same or different definitions selected per case). Not "one event with five workers" unless the product task truly is a mass process with its own design—standard Hire teaching examples are one worker per hire event.
Configuration scenario: HR Partner initiates Hire for Jordan Lee into Platform Team. Workday selects the default Hire definition, creates Hire event E-10492, and generates open steps for the initiator and later approvers. Separately, another partner initiates Hire for Sam Okonkwo—the type is still Hire Employee, but the event is different.
Step
A step is an individual unit of work defined on a definition and executed on an event. Training and the exam refer to several step categories (deep coverage in the next chapter), including conceptually:
| Step category (conceptual) | Role in the process |
|---|---|
| Action | Perform a transaction action / data entry style work in the flow |
| Approval | Approve or send back; may use approval chains |
| To Do | Manual checklist item completed outside automated action |
| Notification | Inform parties without requiring approval |
| Subprocess | Launch another related process as part of the parent |
| Integration / Service (where used) | System-automated work |
Step facts for terminology
- Steps are ordered on the definition (ordering letters and insertion are definition-level configuration later).
- On an event, steps become inbox work (or automated completion) for the resolved participants.
- Routing decides who gets a step; BP security decides whether that who is allowed to perform the action.
- Condition rules on steps can include/exclude a step for a given event without choosing a whole different definition.
Definition (design): Step A → Step B → Step C
Event (runtime): A completed → B waiting on Manager → C not started
Hire Employee: Terminology Walkthrough
Use this story to cement all four terms.
- Type: Hire Employee — the process kind; BP security policy for Hire controls Initiate/Approve/etc.
- Definitions under Hire:
- Default Hire definition (standard path)
- Rule-based Executive Hire definition
- Org-specific Germany Hire definition
- Initiation: Manager of Platform Team starts Hire for an open position. Security: Manager group has Initiate on Hire; constrained scope includes Platform Team.
- Definition selection: Candidate is non-executive, US → no rule match, no Germany org-specific → default definition selected.
- Event created: Hire event for the new worker/position context with effective hire date.
- Steps execute: e.g., complete hire data (action) → HR Partner review → Manager Approval → complete.
- Outcome: Event completes; worker is hired; definition remains for the next initiate.
| Term | In this story |
|---|---|
| Type | Hire Employee |
| Definition | Default Hire definition |
| Event | This specific hire transaction |
| Steps | Data entry, HR review, Manager Approval, … |
Change Job: Terminology Walkthrough
- Type: Change Job — separate type from Hire; separate BP security policy; separate definitions.
- Definition: Rule-based definition matches because Management Level becomes Executive; executive Change Job definition selected instead of default.
- Event: Change Job event for worker Alex Rivera transferring to VP role effective 1 October.
- Steps: Include extra Compensation Committee approval that exists only on the executive definition—not on default Change Job.
Side-by-side Hire vs Change Job
| Concept | Hire example | Change Job example |
|---|---|---|
| Type | Hire Employee | Change Job |
| Typical subject | Candidate / new employee into a position | Existing worker changing job/position attributes |
| Definition | Default vs rule/org Hire defs | Default vs rule/org Change Job defs |
| Event | One hire transaction | One job-change transaction |
| Illustrative steps | Propose hire, approvals, onboarding To Dos | Propose change, comp review, manager/HR approvals |
| Security policy | Hire BP security policy | Change Job BP security policy |
Exam trap: Completing Hire security does not automatically grant Change Job Initiate. Policies are per type. Shared security groups may be listed on both policies, but the type-level policy entries are distinct.
How the Terms Relate to Orgs and Security (Tie-Back to T44)
| Term | Org relationship | Security relationship |
|---|---|---|
| Type | Many types use Supervisory Org context for staffing | BP security policy is per type |
| Definition | Org-specific definitions key off org context; rules may read org attributes | Definition does not replace Initiate/Approve grants |
| Event | Captures the org/job context of that transaction | Only authorized users create/act on events |
| Step | Routing often resolves Manager/HR Partner roles on orgs | Performer must be allowed to Approve/complete per BP policy + domains |
Terminology Confusions Table
| Mix-up | Correct |
|---|---|
| Calling a running hire a "definition" | It is an event |
| Calling Hire Employee a "step" | It is a type |
| Thinking one type allows only one definition | Multiple definitions per type |
| Thinking five hires are one event | Five events |
| Thinking step order lives on the security policy | Order lives on the definition |
| Thinking Initiate is configured as a step type name only | Initiate is a BP security permission for the type |
Quick Memory Hooks
- Type = what kind? (Hire vs Change Job)
- Definition = which blueprint? (default / org / rule)
- Event = which occurrence? (Jordan's hire)
- Step = which task in the occurrence? (Manager Approval)
Or: Type shelves the binder; definition is the checklist template in the binder; event is today's filled checklist for one person; step is one checkbox line.
Practice Mapping Drill
Read each phrase and name the term:
| Phrase | Term |
|---|---|
| "Terminate Employee" as a process category | Type |
| "We added a Works Council To Do to Germany's hire path" | Definition (org-specific) |
| "Open process for Maria's transfer still waiting on Compensation" | Event (with open step) |
| "Manager Approval" | Step |
| "Who can Initiate Change Job?" | Security on the type (not a definition name) |
| "First matching condition picked the executive path" | Definition selection among definitions of a type |
Bridge to the Rest of BP Fundamentals
| Later topic | Terminology it assumes |
|---|---|
| Actions & subprocesses | Step types inside a definition / event |
| Approvals & chains | Approval steps and participants |
| Condition rules | Rules on steps or for rule-based definitions |
| Advanced routing / labels / help | Attributes of steps on a definition |
| Notifications | Often steps or related BP triggers |
| Ordering letters / validation | Definition-level structure |
| Mass/individual BP management | Acting on events and maintenance of processes |
| BP security interaction | Policies on types vs design of definitions |
If T46 vocabulary is shaky, every later BP item costs extra time. If it is automatic, definition selection (T45) and org/security relationships (T44) snap into a single story: types are secured and defined; definitions are chosen; events run steps for real workers in real org context under real security constraints.
That story is the entire Business Process Framework chapter—and the foundation for the remaining ~10 BP Fundamentals questions on Workday Pro HCM Core.
What is a business process type in Workday?
What is the difference between a business process definition and a business process event?
In a Hire Employee example, what is Manager Approval?
Five workers are hired this week using the same default Hire definition. How should you describe that in BP terminology?