Share with your organisation

Every template is either private to its creator or shared with the organisation.

New templates start private — one pushed from a configuration repository is the exception, below. Sharing is a deliberate act: Share with the organisation on the template’s page under Templates, and Make private to take it back. Either asks first.

What each means

	Who can see it	Who can change it
Private	Its creator only	Its creator (a builder or above), and administrators
Organisation	Everybody in the organisation	Every builder, and administrators

Sharing hands a template to the organisation. From then on it is the organisation’s, not its creator’s: any builder can update, rename, re-share or delete it, whoever made it, and an operator can use it but never change it. Making it private again hands it back to the person who made it, not to whoever pressed the button. Keep a template private while it should stay yours.

A template you cannot see answers “not found”

Not “forbidden”. That is deliberate: whether a colleague has a private template called Q4 migration attempt 3 is not something the API should let you probe for.

Which plans allow it

Sharing is a plan feature. On a plan without it, templates stay private and an attempt to share is refused with FEATURE_SHARED_TEMPLATES.

The check is on the server, not only in the app. That matters because the same templates are reached by the SDK and by an agent over MCP — a gate the app honours and the API does not would not be a gate at all.

See Plans and limits.

When to share

Share the ones that encode a decision the organisation has made:

• The monthly file from Finance, with its match rule.
• The vocabulary of a recurring import — which columns mean which fields.
• Anything you would otherwise explain to a colleague over their shoulder.

Keep private the experiments, the one-offs, and anything half-built. A shared template is implicitly a recommendation.

Templates from a configuration repository

A template pushed from a config bundle belongs to the whole organisation by design — that is what pushing it means.

Because pushing them is sharing, a plan without shared templates refuses a bundle that carries any, rather than quietly importing them as somebody’s private ones. The error names the feature and suggests removing templates/ from the bundle or upgrading.

Pushed templates carry where they came from, so re-pushing updates the same template rather than accumulating copies, and they never collide with a hand-made template that happens to share a name.

A pushed template belongs to its repository. A change to its recipe, name or description made anywhere else — the Templates API, an agent over MCP, an import — is refused with TEMPLATE_MANAGED, naming the file, because the next push would overwrite it without a word. Who can see it is still the organisation’s to decide, and it can be used, copied and deleted like any other — though a deleted one is made again by the next push that carries its file. A push that changes a template’s recipe records its next version; one that sends it unchanged records nothing.

See Configuration as code.

Deleting

A private template is deleted by its creator (a builder or above) or an administrator, and a shared one by any builder. Its versions and its schedules go with it. Run history is kept — it records what happened, not what the template says now, and deleting the recipe should not erase the evidence of what it did. Every import that used the template keeps its own copy of the recipe.

A template cannot be deleted while an import that uses it is running: the delete is refused with IMPORT_RUNNING, naming the import, and nothing changes. Delete it once the run ends.