Choose when a workflow runs

What this achieves

A binding is the rule that connects a published workflow to real requests: this kind of request, at this moment, runs this route. Until a workflow has one, it exists but nothing reaches it.

Required role: Administrator.

Before you start

The workflow needs a published version. A binding on a workflow with nothing published has nothing to run.

Steps

Go to Approvals → Workflows and open the workflow.
Open the Bindings tab.
Select New Binding.
Choose the Resource type — the kind of request this binding covers.
Choose the Trigger — the event that starts the route.
Set a Priority if more than one binding could match the same request.
Set Valid from and Valid to if the binding should only apply for a period.
Add a Condition if only some requests of this type should take this route.
Select Save.

What a binding is made of

Option	Description
Resource type	The kind of request — a leave request, a promotion request, a payroll run, and so on.
Trigger	The event that starts the route, such as when a request is created, submitted, or submitted for approval.
Priority	Which binding wins when several match the same request. Higher priority wins.
Valid from / Valid to	An optional window. Outside it, the binding does not fire.
Condition	An optional test evaluated at the moment of the trigger, so the route applies to some requests of this type and not others.

Example: HC Corp binds its promotion route to promotion requests on submission, with no condition, so every submitted promotion takes it. It binds a second, heavier route to the same request type at a higher priority with a condition on grade, so senior promotions take the longer path and everything else falls to the first binding.

Check the match before a real request does

Test Resolution previews which workflow a given request type and trigger would match, without running anything. It tells you either that a named workflow and version would run, or that nothing matched.

Use it whenever more than one binding could apply. Priority decides the winner, and this is how you confirm which one that is rather than finding out from a live request.

Manual Trigger goes further and starts a real instance against a resource you choose, taking you to the new instance. It needs an active binding to match — the dialog says so, and lists the workflow’s active bindings while you pick.

Example: Priya Raman uses Test Resolution to confirm that a promotion submission matches the senior route rather than the standard one, then uses Manual Trigger on a single real request to watch it travel before leaving the binding in place.

Turning a binding off

Deactivate stops a binding firing while leaving it on the list, and it can be reactivated from the same row at any time. Prefer it to deleting: a deactivated binding still records that this route once applied.

Deactivating does not affect requests already running. They finish on the route they started.

When nothing is bound

A request type with no workflow bound to it is not stuck. It follows the approval path built into that part of the product — a leave request routes to the manager, a payroll run needs a second administrator, a paid enrolment routes by cost.

Binding a workflow replaces that built-in path with yours. That is the point of doing it, and it is also the risk: your route now has to cover everything the built-in one did.

What happens next

The next matching request starts an instance of the published version and produces the first task in its approver’s inbox. Watch it on the instances list, and use the decisions log to confirm the route asked the people you expected.