6.3 Using Reports to Troubleshoot Business Processes
Key Takeaways
- The process history of an event shows every step, its status, its assignee, and whether it was skipped, and is the first place to look when an event is stuck.
- Business Process Configuration Options confirms what a business process type permits, ruling out configuration that was never possible.
- Business Process Security Policies for Functional Area lists a type's description together with all of its processes and subprocesses.
- View Definition shows the version of a definition in effect on a given date, which matters because the initiation date determines which version an event follows.
- Process Monitor shows the status of scheduled and background processes, and the To Dos report shows which business processes use which To Do steps.
Diagnose in this order
Business process problems reduce to a small number of causes, and there is an efficient order for eliminating them.
1. Look at the EVENT → process history: which step, what status, who is assigned
2. Look at the DEFINITION → View Definition as of the event's initiation date
3. Look at the SECURITY → BP security policy (participation) + role assignment (assignee)
4. Look at the TYPE → Business Process Configuration Options: was this ever allowed?
Most administrators invert this and start by editing the definition, which is why they change a definition that the stuck event is not even using.
Step 1 - read the process history
Every business process event carries a process history showing each step, its status, its assignee, and the date and time each transition occurred. Reach it from the event's Related Actions or from the event record itself.
What the history tells you:
| What you see | What it means |
|---|---|
| Step Awaiting Action with an assignee | Routing worked. The person has not acted. Chase the person |
| Step Awaiting Action with no assignee | The role is unassigned on the relevant organization - a role assignment problem |
| Step not present at all | An entry condition evaluated false and the step was skipped |
| Step present and skipped | Marked skipped by an assignee on an optional step |
| Process Successfully Completed but downstream data missing | The completion step is placed after the step you are waiting on |
| Step In Progress on a Service or Integration step | The separate processing thread has not returned - check the integration event, not the business process |
The two most confusable outcomes. A step that never appears in the history was skipped by a condition. A step that appears with no assignee has a security or role assignment cause. These need completely different fixes, and the history is what distinguishes them.
Step 2 - confirm which definition version applied
Because the initiation date of a transaction determines which version of the definition is used, the definition you are reading now may not be the one the stuck event is following.
From the definition's Related Actions, run the View Definition report and enter the event's initiation date. That shows the version actually in effect. Effective dates apply to business processes, consolidated approvals, and condition rules, so a rule may also have changed since the event began.
Step 3 - check security and role assignment
Two separate checks, for two separate symptoms.
No assignee on a step. Roles are assigned on organizations and cascade down hierarchies. Verify the role is assigned on the relevant organization or a superior. Use View Security Groups for User on the person who should be assigned to confirm they are actually in the group.
User cannot act at all - the task is missing. That is the business process security policy. Confirm the group is on the policy with the needed permission, and that the policy change was activated. Recall that the definition's Group prompt only offers groups already on the policy.
User can act but the form is blank or partial. That is a domain security policy, not a business process one. Use the method in section 4.3: View Security for Securable Item on the field or task, then View Security Groups for User.
Step 4 - confirm the type allows it
The Business Process Configuration Options report tells you what the business process type supports: valid organization types, allowable actions and approvals, restrictions, prerequisite actions, which processes are strictly subprocesses, allowed subprocesses, allowed mass actions such as rescind, correct, cancel and approve, and which incomplete processes are cancelable.
When a configuration simply will not save, or a mass action is unavailable, this report tells you whether the capability exists at all - which is faster than assuming a defect.
The reports worth knowing by name
| Report | Answers |
|---|---|
| Business Process Configuration Options | What does this business process type support? |
| Business Process Security Policies for Functional Area | Description of each type, with all processes and subprocesses in the functional area |
| View Definition | What did the definition look like on a given date? |
| To Dos | Which business processes use which To Do steps? |
| Process Monitor | What is the status of scheduled and background processes, including alerts? |
| View Security Groups for User | Which security groups does this user belong to? |
| View Security for Securable Item | Which domains secure this item, and which groups are permitted? |
Process Monitor is easy to overlook because it is usually taught alongside alerts. It monitors background and scheduled processing, which makes it the right place to look when a Service, Integration, Batch/Job, or scheduled report step has not produced its result.
Building a custom report to find stuck events
For recurring monitoring rather than one-off diagnosis, build a custom report on business process data. A practical pattern:
- Create a custom report on a business process or event data source.
- Add columns for the process type, the current step, the assignee, the status, and the initiation date.
- Filter to events in progress beyond a threshold - for example, initiated more than five business days ago and not completed.
- Configure an alert on it so the queue is pushed to the right group rather than pulled. Alerts are covered in section 8.2, and they are the standard mechanism for turning a diagnostic report into ongoing monitoring.
This is exactly the pattern the exam has in mind when it asks how to proactively identify stalled business processes: a custom report supplies the criteria, and an alert delivers the results.
Symptom-to-cause quick reference
| Symptom | Most likely cause | Check |
|---|---|---|
| Event stuck, no assignee | Role unassigned on the organization | Assign Roles on the organization and its superiors |
| Event stuck, assignee present | Human delay | Notify; consider a step delay or an alert |
| Step never ran | Entry condition false, possibly a delivered one | Process history; Maintain Step Conditions |
| Step ran that should not have | Condition created but never applied to the step | Maintain Step Conditions |
| Change to definition had no effect on an in-flight event | Version by initiation date | View Definition as of the initiation date |
| User cannot start the event | BP security policy | Policy permissions; activation |
| User can act but sees no data | Domain security policy | View Security for Securable Item |
| Completed, but payroll or GL has nothing | Completion step placed too late | Definition step order |
A business process event is stuck. The process history shows the current step is Awaiting Action but no assignee is listed. What is the most likely cause?
An administrator corrects a business process definition, but an event initiated last week continues to follow the old routing. Which report confirms which version of the definition that event is using?
A team wants ongoing notification whenever a Change Job event has been in progress for more than five business days. What is the standard Workday approach?