Templates and runs

A template is the diagram. A run is one record's journey through it. Templates are built and edited; runs happen, and are read rather than edited.

The distinction matters more than it sounds, because templates exist at two levels and a run only ever belongs to one project. Getting that relationship right is the single most useful thing to understand about workflows.

Where templates live

Workflow templates are not in one central admin screen. They live in each tool's own settings, on a Workflows tab: claim workflows on the Contracts settings page, submittal workflows on the Submittals page, and so on. The reasoning is that the people who own a tool own its process.

Those pages sit under Tools, which only members of the host organisation with the right permissions can open. Guests are frequently inside workflows as approvers and act from the record and from My Items, but templates and bindings stay host side.

The organisation standard and the project copy

Open a Workflows tab on a project and you see two lists: the project's own templates, and below them a card holding your organisation's templates.

An organisation template is the shape without the people. Three-stage claim approval, a single review for small variations, a two-step submittal review. You build it once at organisation level and it says nothing about who: no names, just the structure and the rules. See Organisation level and project level for the wider pattern.

A project copy is where people are attached. Activating an organisation template on a project makes it available as a source, and taking a copy creates a real, separate template belonging to that project. That copy is where this project's project manager goes on the first decision and this project's commercial manager on the second.

Activate then copy is the only route from organisation to project. A project's binding list never offers organisation templates directly, which is deliberate: it means every running workflow belongs to the project it is running on, and nobody can change a live process on twenty jobs by editing one record.

What a copy inherits and what it does not

Editing a project copy never reaches back and changes the organisation standard. That is what makes it safe to adapt a process for an unusual job.

It also means a copy can drift, and drift is invisible until somebody goes looking. If a project starts behaving differently from its siblings, its copies are the first place to check.

A copy's structure is locked against edits that would break a run in progress. You can change who is assigned, rename blocks and adjust their settings; you cannot restructure the graph out from under records already moving through it. That is a guard rather than a limitation, and where a genuinely different shape is needed the answer is a new template rather than a rewritten one.

New projects start governed

When a project is created it inherits its host organisation's tool configuration, workflow defaults included. A new job therefore starts with a working approval process rather than an empty one, which is the main reason to set the organisation up properly before creating the first project. See The tools catalogue.

Teralo also ships sensible default workflows for every tool that has one, so an organisation that never opens the builder still has approvals that work.

One caveat worth knowing: editing a default only reaches organisations created afterwards. Templates are yours to edit, so refreshing an existing one would overwrite somebody's changes. An existing organisation adopts a changed default by editing its own template.

Keeping a standard uniform

Where governance genuinely requires that every project runs the same process, an organisation default can be locked, so projects inherit it rather than editing their own copy.

Use it where uniformity matters and leave the rest adjustable. A locked process that does not fit an unusual job gets worked around outside Teralo, which is worse than a process that could be adapted.

Runs

Once a template is bound to a tool, every new record of that type starts a run. See Binding a workflow to a tool.

A run materialises every block in the template as a step, and walks them one at a time. It shows on the record as the chip strip described in What a workflow is, and it keeps a permanent record of itself: which blocks it went through, who responded, what outcome they chose, what note they left, when.

A run cannot be edited, only acted on, which is the property that makes the trail worth anything. Changing the template a run started under does not retroactively change that run.