Permission templates

A permission template is a named bundle of permissions you build once and apply to everybody who needs it. Building a role rather than a person is the whole idea: twenty site managers on four projects get the same access because they are on the same template, not because somebody ticked the same boxes twenty times.

Templates exist at both levels, from two different catalogues. An organisation template covers organisation-level access; a project template covers one project. See How permissions work for the model underneath.

The presets

Teralo ships templates for the roles that turn up on nearly every job, so a new organisation is usable before anybody opens the editor.

At organisation level: Organisation Admin, Office Manager, Finance / Accounts and General Staff.

At project level: Project Manager, Site Manager, Contract Administrator, Document Controller, Subcontractor, Design Consultant, Inspector / Superintendent and View Only.

The project presets are worth reading even if you intend to write your own, because they are a decent statement of what each role actually needs and they make a better starting point than an empty template.

Writing your own

Most organisations end up with a handful of their own, usually for the roles their business has that the presets do not name.

The advice that matters is to start minimal and add. It is easy to grant everything and hard to take it back once people are used to it, and an over-granted template is invisible until the day it matters. Where you are unsure, leave a permission out: somebody asking for access is a much better failure than somebody quietly having it.

Name templates for the role rather than for the access. "Subcontractor QA" tells the next person why it exists; "Extra permissions 2" does not, and somebody will have to work it out in a year.

Watch the delete permissions specifically. Nothing else implies them, which means granting them is always a deliberate act, and it should stay one.

Guests get templates too

A guest is assigned a project template exactly as your own people are, from the same catalogue.

It is worth writing templates specifically for the guest roles you deal with rather than reusing an internal one, because the shape is genuinely different: a subcontractor needs to lodge and respond across several tools, a client needs to read a lot and change nothing, and a certifier needs one tool in depth. Naming them for who they are for ("Client, read only", "Trade contractor") makes inviting somebody a decision rather than a guess. See Inviting people to a project.

Changing a template

Editing a template changes access for everybody on it, which is the point and also the risk. A permission removed disappears for twenty people at once.

Changes take effect the next time somebody opens the project. If you need to change one person rather than the role, move that person to a different template rather than editing the template around them.

Reviewing them

Two habits are worth having, and neither takes long.

Look at your templates when somebody changes role, rather than when somebody complains. Moving between templates is the correct way to change what a person can do, and it only works if the templates are still accurate.

And remove access promptly when people leave. Removing somebody from the organisation removes them from every project it hosts, which is usually what you want. See Members and user applications.

SettingsHost only

Organisation templates and project templates are edited in different places, and which you want depends on which catalogue you are working in.

Organisation, then Permissions holds the organisation templates, and it is also where the project templates your organisation uses are written. Create a template, name it, and tick the permissions it grants; permissions are grouped by the tool they belong to, and anything implied by something you have already granted appears ticked and disabled with a note saying it comes automatically.

Project, then Permissions is where a person on a project is moved from one template to another, and where a project can carry templates of its own for a role that only exists on that job.

Only somebody holding the permission to manage permissions can open either, which for most organisations means an administrator.

PermissionsHost only

Editing templates is itself a permission, and it is the one to be most careful granting, because somebody who can edit templates can grant themselves anything else.

Assigning an existing template to a person is a lower bar and sits with whoever adds people to projects, which is usually a project manager. That split is deliberate: a project manager should be able to bring somebody onto a job without being able to invent a new level of access to give them.