Skip to main content

Assignments & Routing

Every step in a workflow needs to know who is responsible for it and where the flow goes next. You set both of these inside the Workflow Designer, in the Add / Edit Step dialog. This page explains how assignment and routing work.

Step dialog with role and routing fields

How to open these settings​

Assignments and routing aren't a separate screen — they live in the step dialog of the visual designer:

  1. Open a workflow from Workflow Definitions (route /configuration/workflow-designer/<id>).
  2. Click + Add Step, or the pencil on an existing step, to open the dialog.
  • Access required: the Manage Workflows permission (CONFIGURATION.WORKFLOWS).

Assigning a step to a role​

Each step has an Assigned Role dropdown that names who is responsible for completing it. The available roles are:

RoleTypically used for
IT AdminTechnical setup and administration tasks.
Service Desk AgentFirst-line logging, triage, and ticket handling.
ManagerLine-manager approvals and sign-offs.
Channel ManagerChannel/partner-related approvals.
Sales RepresentativeSales-related tasks.
Finance TeamBudget checks and finance approvals.
RPA BotAutomated (robotic) steps with no human action.
SystemSteps the platform performs automatically, such as emails and notifications.

Pick the role from the dropdown and Save. On the canvas, the role appears on the step's meta line next to a person icon (for example, Service Desk Agent).

Roles describe responsibility within the process. They tell everyone reading the workflow who owns each step; assign RPA Bot or System for fully automated steps.

Setting how long a step should take (SLA)​

Next to the role, each step has an SLA Duration and a Unit (hours or days). This is the target time for completing the step and is shown on the canvas next to a clock icon (for example, 4 hours or 2 days). Automated steps are often set to a short SLA, while reviews and approvals may take days.

Routing: how the flow moves between steps​

For most step types, routing is simply top to bottom — when a step finishes, the flow continues to the next step below it, and eventually reaches the End cap. You control this order by arranging steps in the designer (drag, or the up/down chevrons).

The one step type that changes the path is the Decision step.

Branching with a Decision step​

A Decision step asks a single yes/no question and sends the flow down one of two branches. When you choose Decision as the step type, extra fields appear:

  1. Condition (required) — the yes/no question to evaluate, e.g. "Was the incident resolved at L1?".
  2. If Yes, go to — the step the flow jumps to when the answer is Yes.
  3. If No, go to — the step the flow jumps to when the answer is No.

Each branch dropdown lets you choose:

  • Next step — continue to the step immediately below (the default).
  • A specific step in the workflow (listed as Step N: Title).
  • End workflow — finish the process on that branch.

Decision node showing Yes and No branches

On the canvas, a Decision node shows its question and both routes — a green Yes → line and a red No → line — each pointing at the step (or End) you selected.

Important — binary branches only: a Decision step has exactly two outcomes (Yes and No). DocLock does not support parallel branches, split approvals, or more than two outcomes from a single step. To model more complex logic, chain several Decision steps one after another.

A worked example​

The built-in Incident Resolution workflow shows routing in action:

  1. Log & Categorise Incident (Task → Service Desk Agent)
  2. L1 Initial Assessment (Approval → Service Desk Agent)
  3. Resolved at L1? (Decision) — Yes → Notify User of Resolution; No → L2 Technical Resolution
  4. L2 Technical Resolution (Task → IT Admin)
  5. Notify User of Resolution (Email → System)
  6. Close & Document (Task → Service Desk Agent)

The Decision step routes simple incidents straight to the notification, while unresolved ones are sent to the L2 team first.

Tips​

  • Give Decision questions a clear yes/no phrasing so the two branches are unambiguous.
  • Use End workflow on a branch when that path is a valid finishing point (e.g. a rejection).
  • Need a loop (e.g. "send back for revision")? Point a branch back at an earlier step — the Contract Lifecycle sample does this to return to negotiation.

Troubleshooting​

ProblemLikely cause and fix
No routing fields on a stepOnly Decision steps branch. Other steps always flow to the next step below.
A branch shows "Unknown"The step it pointed to was deleted. Re-open the Decision step and pick a valid destination.
I need three outcomes from one stepNot supported — branches are binary. Add a second Decision step after the first to split further.
The wrong person is shown for a stepOpen the step with the pencil and change the Assigned Role.
A branch loops foreverCheck that at least one path eventually reaches End workflow; avoid branches that always return to an earlier step.