Own a process from request to outcome¶
A process owner maintains the relationship between the business purpose, the people allowed to decide, the information needed and the outcome the organization expects. A published workflow supports that process; it does not remove the need for accountable ownership.
Use this guide for planning and oversight. The workflow authoring, request execution and approval guides provide the intended task instructions.
Draft and availability: Those instructions follow inspected final-screen designs, with current implementation differences retained. This guide does not establish connected workflow delivery, live recovery or a completed process-owner walkthrough.
Define what completion means¶
Begin with the initiating need, required information, eligible participants, decision rules and intended outcome. Identify what happens after approval and which area owns that next step.
| Object or stage | Meaning to keep clear |
|---|---|
| Reusable definition | The process configuration used to start work |
| Submitted request | One recorded instance with its own reference, answers and history |
| Assigned task | A specific unit of responsibility within the process |
| Approval | A decision under the relevant mode, voters and required count |
| Correction | A supported return to the original requester for permitted changes |
| Handoff | Prepared information sent toward another business area, with separate delivery and outcome evidence |
Read request and task meanings before defining a success measure. Finishing one person's task is not always the same as finishing the request. A receiving project, record or other process retains its own lifecycle.
Specify what rejection, return for correction, cancellation and completion mean in the chosen process. Do not assume that those actions erase history or have the same effect.
Maintain the people and authority behind the route¶
Keep relevant People and organization information, membership and access and approval authority aligned with the intended responsibilities.
Approval bodies distinguish members, voters, quorum, chairpersons, direct signers and delegates. A sufficient voter count does not prove that the request has received its required decisions. Signing authority does not place a signature on a document.
Check effective dates and supported authority conditions. A saved future membership is not evidence that every dependent process will wake up automatically at that time. When pending work matters, verify the current task and authority state through the documented process.
A business role alone cannot bypass product permissions, source access or the work's current state.
Review configuration changes against existing work¶
A new definition or template version does not establish that an existing request has switched routes. The template lifecycle explanation describes retained versions and answer rules.
Timing also has a saved context. Existing tasks can retain their original policy targets and working calendar after an SLA policy is edited. Later tasks can receive a different snapshot. Deactivating a policy does not erase earlier timings or cancel the tasks that already use them.
Before a change, identify whether it affects new work, currently pending work, future assignments or only the display. Tell the affected people what must be checked afterwards. Do not promise a universal migration of existing work.
Handle an authority change without losing the original request¶
The background authority-refresh process can revisit pending approvals after a qualifying change. It can replace open tasks and retain earlier resolved decisions.
When a reviewer sees an unexpected cancelled task:
- Identify the original request and current approval.
- Review the current actionable tasks and retained decisions.
- Establish whether a qualifying authority change produced replacement routing.
- Involve the governance or process owner if the workflow is suspended or the required authority is unresolved.
- Follow the documented recovery path for that specific condition.
These are investigation activities using the canonical guides, not a new intervention screen. Do not create a replacement request simply because an old task is no longer actionable.
A saved body change does not prove that its notification reached Workflow. A future-dated change does not by itself prove a scheduled refresh. Verify the current result.
Preserve the meaning of time¶
Response and completion deadlines answer different questions. Working days, hours, breaks, holidays and the headquarters timezone can affect their calculation. The timing guide explains those dependencies.
Replacement tasks can inherit existing obligations. Supported authority suspension can pause timing, but recovery does not universally reset every due date or move an already-reached deadline forward.
For delayed work, establish the current task, its saved due and pause information, the reason for delay and the actual remaining decision. Do not infer a new deadline solely from the time a replacement task appeared.
An escalation may arrange an alert or reassignment according to its rule. Evidence that an alert was prepared or delivered is separate from completion of the business work.
Check documents and receiving work separately¶
A file operation and its business use have different outcomes. Document sessions explain uploading, viewing and preparing signatures. Records explains registration, filing and lifecycle. Preparing a signed file does not alone establish that the source business document was updated.
For a workflow handoff, verify both the source request's state and the receiving area's acknowledgement or result. Shared work between organizations additionally follows its exchange rules.
Define the evidence required for the outcome you are claiming. A sent message, a recorded request and a completed receiving action are not interchangeable.
Investigate an exception with the right owner¶
| Observation | What to establish | Responsible owner to involve |
|---|---|---|
| A person cannot see or decide the work | Current identity, membership, product permission and assignment | Organization administrator and process owner |
| Approval cannot continue | Specific approval, decision mode, eligible authority and recorded reason | Governance and process owners |
| Work appears overdue | Saved timing, calendar, pause facts and current actionable task | Process owner |
| Submission or a decision timed out | Whether the original action saved or progressed | Authorized support with the business owner |
| A handoff has no confirmed outcome | Source state, receiving acknowledgement and actual downstream result | Both process owners |
| A view or notification disagrees with the work | Observation time and the source business state | Support and the relevant feature owner |
Retain the workspace, request, task or approval reference, attempted action, approximate time and visible reason. Explain the business impact without distributing protected documents or credentials unnecessarily.
Activity history can supply recorded context within its scope. An empty history or a healthy service observation is not complete proof of what happened.
Keep the process understandable¶
Review the process after material behavior, responsibility or configuration changes. Update the team's instructions and expectations with the actual effect on new and existing work.
Use the adoption guide to record scope, ownership, evidence and unresolved constraints. Source behavior, intended screens, deployment and reader comprehension each need their own verification. A process diagram or completed configuration form cannot substitute for all four.