Stages
What is a Stage?
A Stage is the fundamental building block of a Process Orchestrator process. In Business Orchestration terminology, a stage corresponds to an Activity or Task - a discrete unit of work within the process that must be completed before moving forward.
Each stage represents a distinct phase in the business process where specific objectives are accomplished. Stages are not just placeholders - they are rich containers that encapsulate everything needed to complete a particular piece of work.
| Stage Element | Purpose | Example |
|---|---|---|
| Work to be performed | The core activity or set of activities | Review submitted documents for completeness |
| Data requirements | Information needed to complete the stage | Customer ID, income verification, credit report |
| Validation rules | Conditions that must be met to proceed | All required fields populated, documents attached |
| Assignments | Who is responsible for completing the work | Credit Analyst team, specific manager, or system |
| Automation triggers | Logic executed on entering or exiting | Send notification, update record, calculate score |
Stage Assignments
Stages in Process Orchestrator are generic containers - they don't have predefined types like "manual task" or "automated task." Instead, the Assignment configuration determines who is responsible for completing the work within that stage.
This flexible, assignment-driven approach provides powerful versatility: the same stage structure can behave as a manual task, a team queue, or a fully automated step simply by changing its assignment configuration.
The engine supports exactly four assignment strategies:
| Assignment | Business Orchestration Equivalent | Multi-Task | Description | Best For |
|---|---|---|---|---|
| User | User Task | No | A specific, named user is assigned a single task for the stage | Tasks requiring specific expertise or accountability |
| Team | User Task (with lane/pool) | No | A single task is assigned to a team; any qualified team member can claim and complete it | Workload balancing, availability-based assignment |
| Team Members | Parallel User Tasks | Yes | Every member of the team receives their own individual task | Consensus gathering, parallel reviews, multi-party sign-off |
| Custom | Flow-driven assignment | Configurable | The assignees (and whether one or many tasks are created) are resolved dynamically by a Logic Flow at runtime | Cross-functional collaboration, rule-based routing, hybrid work |
User Assignment is appropriate when a specific individual must handle the work. This might be because they have unique expertise, they have an existing relationship with the customer, or accountability requires a named individual. It always produces a single task.
Team Assignment is ideal when any qualified person can do the work and you want to balance workload across a group. A single task is assigned to the team, and the first available team member claims it.
Team Members Assignment creates parallel work when you need input from multiple people. Each member of the team receives their own task to complete, so the stage's completion criteria is evaluated across all of them.
Custom Assignment provides maximum flexibility: a Logic Flow decides who should receive tasks. A custom strategy can be single-task or multi-task depending on how the flow is configured.
Process Orchestrator does not have a separate "System" / service-task assignment strategy. Every assignment strategy above creates one or more activity (task) records. Fully automated, no-human behavior is modeled by running Logic Flows in a stage's On Entering / On Exiting automation - the stage still owns a lightweight task but the real work is performed by the flow.
Traditional Process Orchestrator tools force you to choose a task type upfront, locking in behavior. Process Orchestrator's assignment-based approach means you can:
- Prototype quickly: Start with a User stage, shift to a Team or Custom strategy later
- Adapt to change: Shift from individual to team assignment without redesigning
- Mix modes: Combine human tasks with On Entering / On Exiting Logic Flows for automation
Stage Configuration
Stages offer rich configuration options that control behavior, automation, assignments, and flow.
General Settings
The General tab defines the fundamental properties of a stage:
| Setting | Description | Purpose |
|---|---|---|
| Stage Name | The display name of the stage | Identifies the stage in the designer and at runtime |
| Stage Owner | The user or role responsible for the stage | Defines accountability and escalation target |
| Due Date | The expected completion timeframe | Enables SLA tracking and deadline enforcement |
| Terminating Stage | Whether this stage ends the process | Marks the stage as a process endpoint |
Stage Owner vs. Task Assignee
The Stage Owner is the person or role accountable for the stage's completion. This is distinct from the task assignee - the owner has oversight responsibility even if the work is performed by others.
- Stage Owner: Accountable for completion, receives escalations, has oversight visibility
- Task Assignee: Performs the work, receives task notifications, completes the task
Due Date Configuration
Due dates can be configured as:
| Due Date Type | Description | Example |
|---|---|---|
| Fixed Duration | A set time period from stage entry | 3 business days after entering the stage |
| Calculated Date | A date derived from record data | Based on the "Requested Completion Date" field |
| Dynamic Expression | A formula-based calculation | Priority = High → 1 day; Priority = Normal → 5 days |
Terminating Stage
A Terminating Stage marks the end of a process instance. When an instance reaches a terminating stage, the process is considered complete.
On Entering
The On Entering configuration defines automation that executes when a stage is reached - before any task assignment is created.
Purposes:
- 📧 Send notifications alerting stakeholders that the stage has been reached
- 📝 Update data records with status changes or timestamps
- 🔗 Trigger integrations with external systems via Service Connections
- 🚀 Launch sub-processes that run in parallel
- ✅ Validate prerequisites before work begins
| Option | Description | Use Case |
|---|---|---|
| Logic Flows | Logic Composer Flows to execute | Send email, update record, call external API |
| Sub-Processes | Other business processes to launch | Initiate parallel approval, start compliance check |
| Execution Order | Sequence of multiple automations | Ensure notification sends after record update |
| Error Handling | Behavior if automation fails | Retry, skip, or halt the process |
Example On Entering Configuration:
Stage: Document Review
On Entering:
1. [Logic Flow] UpdateApplicationStatus
- Sets Application.Status = "Under Review"
- Sets Application.ReviewStartDate = Now()
2. [Logic Flow] SendReviewNotification
- Sends email to applicant
- Uses Localized Resource for multi-language support
3. [Logic Flow] CreateAuditEntry
- Logs "Review Started" to audit table
Assignment
The Assignment configuration defines what work needs to be done, who does it, and what constitutes completion.
Activity Entity
The Activity Entity specifies which Dataverse activity type is used to represent the work item:
| Activity Entity | Use Case | Example |
|---|---|---|
| Task | General work items, to-dos | "Review application documents" |
| Phone Call | Stages requiring customer contact | "Call applicant to verify information" |
| Appointment | Scheduled meetings or sessions | "Conduct in-person interview" |
| Communication-based stages | "Send follow-up request" | |
| Custom Activity | Organization-specific activity types | "Site Inspection", "Compliance Review" |
By leveraging Dataverse activity entities, Process Orchestrator integrates seamlessly with the platform:
- Timelines: Activities appear on related record timelines
- Queues: Team assignments route to Dynamics queues
- Dashboards: Work items visible in standard activity views
- Mobile: Accessible via Dataverse mobile apps
Task Definition
| Element | Description |
|---|---|
| Task Name | Clear description of the work (e.g., "Review Application Documents") |
| Instructions | Detailed guidance for the assignee |
| Required Fields | Data that must be completed before the task can be finished |
| Attached Forms | UI forms presented to the assignee |
Completion Criteria
Completion criteria define when a task is considered done:
| Criteria Type | Description | Example |
|---|---|---|
| All Complete | Every assigned task must be finished | All 3 executives must approve |
| Any Complete | Stage progresses when first task completes | First available agent handles request |
| Percentage | A threshold of tasks must complete | 2 out of 3 approvers (66%) |
| Custom Rule | Logic-based completion determination | Senior approver OR two junior approvers |
On Exiting
The On Exiting configuration defines automation that executes when a stage completes - after all assignment criteria are met but before transitioning to the next stage.
Purposes:
- 📧 Send completion notifications
- 📝 Update records with outcomes, timestamps, or calculated values
- 📊 Log metrics and audit information
- 🚀 Trigger follow-up processes
- 🔗 Synchronize with external systems via Service Connections
Example On Exiting Configuration:
Stage: Manager Approval
On Exiting:
1. [Logic Flow] RecordApprovalDecision
- Sets Application.ApprovalStatus = Task.Outcome
- Sets Application.ApprovedBy = Task.CompletedBy
- Sets Application.ApprovalDate = Now()
2. [Logic Flow] NotifyApplicant
- Sends approval/rejection email based on outcome