Binding a workflow to a tool

Binding is the link between a record type and the template that governs it. It is the step people forget, and the reason is that everything up to it feels like the work: you can build the best claim approval in the world and nothing changes until a contract is told to use it.

If somebody asks why a record did not go for review, its binding is the fastest place to look.

Where each tool binds

The pattern is the same everywhere and the location differs, because it follows how each tool is organised.

Per contract. A contract's progress claim workflow is bound in that contract's own Settings, which means two contracts on the same project can genuinely run different processes. That is the point rather than an accident: a major subcontract and a minor supply agreement should not need the same three-stage approval.

Per type. Where a tool has record types (incidents, observations, submittals, method statements), the binding sits on the type. A near miss and a lost-time injury are different types and can take different routes.

Per tool. The rest bind once on the tool's own settings page, through a card holding the default template and, at project level, an option to inherit the organisation's default.

All of these sit under Tools at organisation or project level, which is host territory. See Templates and runs.

Inheriting or pinning

At project level, a binding can follow the organisation default or point at a project copy.

Leave it on the organisation default and it follows the standard, including when the standard changes. This is right for a process that should be uniform.

Point it at a project copy and it stops following. This is right for a job that genuinely needs something different.

Both are legitimate. What causes trouble is not knowing which one a project is on, so it is worth looking at the binding rather than assuming, particularly on a project somebody else set up.

Where uniformity matters enough, an organisation default can be locked so projects inherit rather than editing. See Templates and runs.

Auto-approve, never nothing

A binding is required. Creating or submitting a record whose type has no bound template fails with an error rather than going through unapproved.

So where a record type genuinely needs no review, the answer is an auto-approve template: a trigger straight to an End block that approves. It sounds like ceremony and it is not. It means every record has a recorded path rather than a silent gap, and, more usefully, it means a mis-scoped or missing binding fails loudly at the moment somebody tries to use it, instead of quietly approving everything for six months before anybody notices.

Teralo ships auto-approve variants for the tools that commonly want them, so this is usually a choice from a list rather than something to build.

Getting an organisation template onto a project

Two steps, and they have to happen in that order.

Activate the organisation template on the project, from the card listing your organisation's templates on the tool's Workflows tab. Activation makes it available as a source; it does not make it run.

Copy it, which creates a project template you can attach this project's approvers to. Then bind that copy.

A project's binding list only ever offers project templates, which is what makes activate-then-copy the only route. That is deliberate: it means every running workflow belongs to the project it runs on, and nobody changes a live process on twenty jobs by editing one record.

You can open an organisation template read-only from that card without activating it, which is the right way to check what a standard actually does before adopting it.

Checking a binding is working

Create a test record and look at the chip strip on it. If the strip is there, the binding is live and you are looking at the template you bound. If the record was created and approved with no strip at all, something bound an auto-approve template.

Changing a binding affects new records. Records already running continue under the template they started on, which is the same rule that stops a template edit rewriting history. See What a workflow is.