How permissions work

You do not get a job title in Teralo, you get a permission template: a named bundle of permissions assigned to you when you are added. The template decides which tools appear in your sidebar and what you can do inside them. Everybody has one, and nobody is on a project without one.

This article is the model behind that. If you are here because something is missing from your screen, the last section is the short answer.

Two levels, two catalogues

Permissions exist separately at organisation level and at project level, and they are different catalogues rather than the same list applied twice. There are 26 organisation permissions and 113 project ones, which is a fair measure of where the work happens.

So you carry an organisation template and a template on each project, and they do not imply each other. A colleague can be an organisation administrator and be on one of your projects as View Only, or be an ordinary member of the organisation and run a project. See Organisation level and project level.

Your project template can also differ between projects, which is worth remembering before concluding that a tool is broken: check you are on the project you think you are.

Permissions are grouped by tool and stack in a family

Permissions are named for what they let you do and grouped by the tool they belong to. Within a tool they come in a family, and holding a higher one implies the lower ones in the same family.

View is the floor. Any permission to act on something implies being able to see it, so a template granting create without view is not a thing you can accidentally produce. Create, edit, approve, review, execute and resolve all imply view. Manage implies create, and through it view.

Delete is always its own permission, and it is deliberately not implied by anything else, including manage. That means "a manager who cannot permanently delete" is expressible on every tool, which is the point: deleting a record removes evidence, and nobody should acquire that by being given a broad role.

The template editor shows this: a permission implied by another one appears ticked and disabled, with a note saying it is granted automatically.

Templates rather than tick boxes

Access is granted by assigning a template rather than by ticking permissions per person. That is not just convenience. A named template is a statement about a role, so it can be reviewed, reused and reasoned about, and twenty people on the same role genuinely have the same access rather than nearly the same.

Teralo ships presets for the common roles and you can write your own. See Permission templates.

Administrators

An organisation administrator bypasses permission checks for their own organisation, and for the projects their organisation hosts. That is the one place access does not come from a template.

It stops at the organisation boundary. On a project hosted by somebody else, an organisation administrator of your company is an ordinary guest on an ordinary template, with exactly the access that template grants.

What permissions do not do

Two limits are worth being precise about, because people expect permissions to cover them and they do not.

Permissions do not decide what a guest organisation can see. A guest sees its own organisation's rows. Another subcontractor's submittals are not hidden behind a permission that could be granted; they are not in the data the page loads at all. Widening a template will never reveal them. See Hosts and guests.

Permissions are not the whole answer to who can approve. Being assigned to a workflow step and holding the right permission are two separate requirements, and on a few tools being assigned is deliberately not enough on its own. See Assigning approvers.

There is also a boundary above templates: an enterprise agreement can reduce which tools an organisation has at all, and a tool withheld that way is not something a template can grant back. See Plans and entitlements.

Work through it in this order, because each step is cheaper than the one after.

Are you on the right project? Templates differ between projects and this is the most common answer.

Is it a guest or host thing? Some areas belong to the organisation running the project: its settings and tools, report authoring, procurement, the Payments tab inside a contract. No permission produces those for a guest.

Is it in your template? If it is genuinely something you should have, ask the host to adjust the template you are on, or to move you to a different one. The change takes effect the next time you open the project.

Has your organisation got the tool? A tool the organisation has not turned on does not appear for anybody. See The tools catalogue.