Workflow definition and publication¶
A workflow definition describes how work moves from its starting point to completion: the steps, who receives them, the decisions that move work forward, and any handoff after the work finishes. Operations teams maintain definitions so that repeated work follows an agreed process. A definition is the reusable route; an individual request or project approval follows that route when it runs.
Availability: The backend implements definition browsing, draft creation and replacement, simulation and publication. The frontend is still in progress and the inspected screens use sample data. The task guide follows the intended final design and explains current limitations. Connected use in your environment has not been verified. This documentation is a review draft.
Who uses it¶
| Reader | What they need to understand |
|---|---|
| Employees and external participants | Your request or assigned task can follow a definition, but participation does not give you permission to change that definition. Use the request or work area for individual work. |
| Managers and process owners | Agree the purpose, accountable team, approval responsibilities, exceptions and completion point before asking an author to publish. Review the saved route rather than relying on its name. |
| Executives | Publication makes a particular version available for compatible workflow use. It is not proof that a process is effective, everyone has been trained, or a downstream service has received work. |
| Tenant administrators and authorized authors | Maintain draft details, steps, rules and handoff settings, resolve validation issues, and verify the saved publication result. Viewing definitions and managing them are separate permissions. |
| Support and platform staff | Distinguish an unavailable screen, insufficient access, an invalid draft and an uncertain save. A platform support role alone does not establish authority to publish a tenant's process. |
Engineering, design and operations readers can use the private integration reference in GitHub. It records exact contracts, source evidence and open implementation work.
Choose the workflow family¶
| Family | Purpose and important rules |
|---|---|
| Case management | Formal case review. The definition uses the case-management category and needs a review or approval scenario. Starting real work requires a case-aware source. |
| Project workflow | Governance of project initiation, changes, milestones, deliverables, closure or cancellation. It needs the project-management category and an approval or decision step. It is not a replacement for every project-planning activity. |
| File movement | Document preparation, routing and filing completion. The route must include document or form work; the retired project-file model is not a current filing workflow. |
| SOP workflow | A general standard operating procedure. The author still needs a valid route, appropriate assignments and a way to finish. |
The current starter catalog contains Case Triage Review, Project Milestone Sign-off, Records Filing Route and SOP Basic Review. A starter supplies an initial structure for review. It does not prove that your organization's people, approval bodies, timing policies or downstream systems are ready.
What a definition contains¶
Details and ownership. A name and stable code identify the definition. Its family and category describe the kind of work. Optional owner-team, owner-role and organogram choices provide the maintenance and organizational context. An owner field is descriptive responsibility, not a grant of permission.
Steps. Each step has an order and type, with options for its role in the process. Some steps need assignment, approval, documents or form completion. A route can also carry time targets, parallel-work settings, linked workflows and limits on which fields reviewers or requesters can change. Only use combinations supported by the current service and validated for the draft.
Route rules. Transitions connect steps. Assignment rules describe where work should go; approval rules describe how decisions are gathered. These concepts are distinct: sending work to a queue does not itself define how many approvals are required, and a parallel-work threshold is not automatically a count of human reviewers.
Handoff. A definition may describe which information is sent to a supported downstream destination after workflow completion. Saving that configuration does not execute the handoff or prove delivery. The design's older “After submission” example does not match the implemented completion trigger and is being corrected.
Draft, simulation and publication¶
- Create a draft from a starter or from scratch. New standalone definitions begin at version 1.
- Save the complete draft structure. Every structural update advances its draft revision and clears the previous simulation result.
- Run simulation and resolve reported issues. The check examines route structure and supported organizational routing. It does not run a real business request or exhaustively prove every possible form value and operational outcome.
- Publish when the draft is ready. Publication reruns the server checks, records the publisher and publication time, and makes the version read-only.
A version number identifies a saved version in a definition family. A draft revision identifies edits within a draft; these numbers are not interchangeable. A successful simulation belongs to the revision it checked. If someone changes the draft afterwards, check the new revision again.
Published definitions cannot be edited through draft replacement. Although the backend has a next-version operation used by request-template authoring, the inspected standalone definition interface does not expose a general “create next version” action. Do not create a duplicate code to work around that limitation. Deprecation and archive labels appear in the design library, but no standalone retire, archive or delete action is established by the inspected definition endpoints.
Governance and rollout decisions¶
Before publishing, agree the intended users, who owns each step, how rejected or returned work is handled, what completion means, and whether linked organizational data and destinations are ready. Have an authorized reviewer compare the saved definition with a realistic example. Keep rollout and training decisions separate from the technical publication action.
The publication contract supports optional effective dates, but the inspected screens do not establish a complete scheduling journey. Do not assume that a displayed date automatically schedules deployment, migrates running work or changes every consumer's version selection. The lifecycle and selection behavior of each consuming feature requires its own verification.
No feature-specific price or savings figure is established here. Workspace access, subscription entitlements and separately governed capabilities still apply where relevant. Do not infer a commercial entitlement from the presence of a starter or a preview screen.
Continue¶
Use Create, maintain and publish a workflow definition for the intended steps and recovery guidance. Review roles and permissions, people and organizational structure, or leave approval guidance when those dependencies are part of the process.
Before adopting a published route, read how requests move through their route. It explains the runtime limits that a saved definition or structural simulation does not establish.