People and roles

This page tells you what each person can do in Deployment Manager. It explains the roles, how a role is given, and how to get access to one installation.

What you do here

This section lists the tasks on this page.

  • Find out what your role lets you do, and what it does not.

  • As an administrator, give a person a new role on the Accounts screen.

  • Ask for access to one installation, or give that access to someone.

Two words are used a lot on this page:

  • An installation is one customer system: its servers, services and settings.

  • To deploy means to install the system on the customer’s servers.

Role and installation access: two different things

This section explains the two kinds of permission.

Deployment Manager asks two separate questions about every person:

  1. What is this person allowed to do in general? This is their role. Every person has exactly one role.

  2. Which installation may this person change? This is access to one installation.

A role is like a job title. Access is like a key to one room. A person with the role user can work on installations. But they can change only the installations they created, or the ones they were given access to.

You can ask for installation access yourself. You cannot ask for a role in the tool. An administrator gives roles.

The roles

This section describes each role: who gets it, what it can do, and what it cannot do.

There are five roles. From lowest to highest: no_access, viewer, user, support_admin, global_admin. Each role can do everything that the roles below it can do. On the Accounts screen they are shown as "No access", "Viewer", "User", "Support admin" and "Global admin".

global_admin is the top role, for the owners of the tool. It is not described on this page.

no_access

Who gets it: a person who left the company, or a person who must be locked out.

What they can do: nothing.

What they cannot do:

  • They cannot sign in. The sign-in is refused.

  • If they are already signed in, the next thing they do is refused. They see this message: "Your access to Deployment Manager has been removed. Ask an administrator to restore it."

The change works at once. The tool checks the role again on every click. So you do not have to wait until the person’s session ends.

viewer

Who gets it: every person who signs in for the first time. Anyone with a company email address can sign in without help. So the first role only lets you look.

What they can do:

  • Open the Installations tab and read every installation.

  • Open the Topologies tab and read every topology. A topology is the plan of which services run on which server.

  • Take the course on the Training tab. For a viewer, the course has three modules.

  • Read What’s new, the list of changes in the tool.

What they cannot do:

  • They cannot change anything. The installation cards show no buttons for a viewer. The list shows this note instead: "Your role does not allow changes. Ask an administrator for access to the tool."

  • They cannot create an installation or a topology.

  • They cannot open Health, Diagnostics or Test install.

  • They cannot deploy.

  • They cannot use the in-app assistant. It does not appear for a viewer.

  • They cannot ask for access to an installation. They need the role user first.

user

Who gets it: an operator who installs and repairs customer systems. An administrator gives this role on the Accounts screen.

This role can deploy to customers' production servers. That is why it is never given automatically.

What they can do on any installation:

  • Everything a viewer can do.

  • Open Health to see if the containers on each server are running.

  • Run Diagnostics. This collects a report file from every server of the installation.

  • Check the entry points, the addresses where the system answers from outside.

  • Ask the in-app assistant, and file a bug report from it.

  • See Your month, a summary of their own work.

  • Create and edit topologies.

  • Create a new installation.

  • Ask for access to an installation (see Requesting access to one installation).

What they can do only on their own installations, or ones they have access to:

  • Edit the installation and its variables.

  • Create the bundle, the files that install the system. Build an offline bundle and download it.

  • Save and remove SSH credentials. SSH is how the tool connects to a customer’s server.

  • Deploy.

  • Start, use and remove a Test install. A Test install is a practice run on throw-away servers.

  • Repair a server: restart a container, apply a preflight fix, edit the server’s .env file, roll the .env file back, or deploy one server again.

  • Mark the installation as installed.

What they cannot do:

  • They cannot change an installation that someone else created, unless they were given access. They see this message: "You do not have write access to this installation. Request access from a support admin."

  • They cannot delete an installation or a topology.

  • They cannot give access to anyone. This is true even for an installation they have access to.

  • They cannot open the Operations tab or the People tab.

  • They cannot give roles.

support_admin

Who gets it: a team lead or support engineer who looks after other operators.

What they can do:

  • Everything a user can do.

  • Change every installation without asking for access.

  • Delete an installation or a topology.

  • Open the Operations tab: the journal of everything done in the tool. See Operations journal.

  • Take the two exports of the journal: the internal one and the one for a customer.

  • Open Accounts (under the People tab). They see themselves, and everyone with a lower role. They can give a role that is lower than their own.

  • Open Access requests (under the People tab). They can Grant or Decline a request.

  • Give access to an installation, and take it back with Take back.

  • Name the owner of an installation that has no owner, with Set owner.

  • See the whole team’s progress through the training course.

  • See the practice installations of other people.

  • Share a saved draft of an installation with others.

What they cannot do:

  • They cannot change their own role.

  • They cannot change the role of another support_admin, or of a global_admin.

  • They cannot give the role support_admin or global_admin.

  • They cannot see other support_admins or global_admins on the Accounts screen.

  • They cannot open Settings, Security or the AI Assistant tab.

What each role can do

This section compares the three working roles in one table.

"Yes" means the role can do it on any installation. "Own" means only on an installation the person created, or was given access to. "No" means never. The module in brackets is the training module that unlocks the action (see Training unlocks actions).

Action viewer user support_admin

Read installations and topologies

Yes

Yes

Yes

Take the training course

Yes

Yes

Yes

Open Health, run Diagnostics, check entry points (T8, T10)

No

Yes

Yes

Ask the in-app assistant, file a bug from it

No

Yes

Yes

See Your month

No

Yes

Yes

Create or edit a topology (T4)

No

Yes

Yes

Create an installation (T5)

No

Yes

Yes

Ask for access to an installation

No

Yes

Not needed

Edit an installation and its variables, start a Test install (T5)

No

Own

Yes

Create the bundle (T6)

No

Own

Yes

Build the offline bundle (T7)

No

Own

Yes

Save or remove SSH credentials (T8)

No

Own

Yes

Deploy (T9)

No

Own

Yes

Repair a server: restart a container, preflight fix, edit or roll back .env, deploy one server again (T10)

No

Own

Yes

Mark as installed (T11)

No

Own

Yes

Set the owner of an installation with no owner (T11)

No

No

Yes

Grant, decline or take back installation access (T12)

No

No

Yes

Open the Operations tab and take its exports

No

No

Yes

Delete an installation or a topology (T14)

No

No

Yes

Open Accounts and Access requests, give lower roles

No

No

Yes

Nobody can change the shared demo installation, whatever their role. See Training unlocks actions.

Training unlocks actions

This section explains how the training course limits what you can do.

Your role says what you may do. But some actions stay muted until you finish the training module that teaches them. This is true for viewer, user and support_admin. Only global_admin does not have to take the course.

  • A viewer’s course has three modules: T1 to T3.

  • A user’s course has eleven modules: T1 to T11.

  • A support_admin’s course has all fourteen modules: T1 to T14.

When an action is muted, the tool tells you which module unlocks it. The message looks like this: "Finish training module T9 — Deploy — to use this."

Good to know:

  • Reading is never limited.

  • The module you are working on does not mute the button it teaches. So you can always press it during the lesson.

  • The shared demo installation cannot be changed by anyone. If you try, you see this message: "This is the training installation everybody learns on, so it cannot be changed. Build one of your own to practise on."

  • An administrator can let a person skip a module. The tool records this.

For the full course, see Training.

The role ladder

This section explains how roles are ordered and which role a new person gets.

The five roles form a ladder: no_access, viewer, user, support_admin, global_admin. Each role includes everything the roles below it can do.

A first sign-in gets viewer, on purpose. Anyone inside the company’s own email domain can sign in without help. But the working role (user and above) can deploy to every customer’s production servers. So the tool never gives the working role automatically. A person gives it later, on the Accounts screen (under the People tab).

no_access is how you remove an account that has left or must be locked out. It is a role, not a separate switch. So it works at once. The tool reads the role again on every request. A signed-in session otherwise stays valid for days, and it cannot be taken back.

A viewer can still read every installation. So changing someone to viewer does not lock them out. Use no_access for that.

Granting a role

This section explains how to change a person’s role, and the rules for it.

To change a role:

  1. Open the People tab.

  2. Open Accounts.

  3. Find the person in the list.

  4. Press Change role.

  5. Choose the new role and confirm.

To learn what each role means, press What the roles mean on the same screen.

The rules for a support_admin:

  • You must be higher than the person’s current role. The same role is not enough.

  • You must also be higher than the role you give.

  • A support_admin may not change their own role.

  • A support_admin may not change the role of an equal, or of someone higher. This rule keeps the ladder safe. Without it, one administrator could use a colleague of the same role to promote a third person to the top role. They could also quietly demote the person who checks their work.

  • Only a global_admin may give global_admin. A support_admin is not higher than global_admin, so a support_admin can never give it.

  • A global_admin has no limits on anyone, on purpose. So there is always someone who can fix a mistake in roles. This leaves one gap: the last global_admin can lower their own role. This risk is accepted. It is rare. You can fix it the same way the very first administrator was created. See bootstrapping the admin list.

When the tool refuses a change, it always says why. It never only hides the button. These are the messages:

  • "Only an administrator can assign roles."

  • "You cannot change your own role — ask another administrator."

  • "A support_admin cannot change the role of a support_admin."

  • "A support_admin cannot grant the role global_admin."

Requesting access to one installation

This section explains how to ask for access to one installation, and how an administrator answers.

Every signed-in user and above can read any installation. To change an installation that you did not create, you need access to that one installation. Change means: edit it and its variables, create its bundle, deploy it, run a Test install on it, or repair one of its servers.

You do not need access to ask for access. That is the purpose of the request.

Who may change an installation:

  • the person who created it,

  • a person who was given access to it,

  • every support_admin and global_admin.

Nobody else can change it. Being the last person who edited it is not enough.

Ask for access

  1. Open the Installations tab.

  2. Find the installation. Its card says Read-only.

  3. Press Request access.

  4. If you want, write a short reason. Then send the request.

You can have one open request per installation at a time. If you send another one, the tool shows the one that is already waiting. When an administrator answers, you get an email.

Answer a request (support_admin and above)

  1. Open the People tab.

  2. Open Access requests. It lists every request that is still waiting, oldest first.

  3. Press Grant or Decline.

You can also give access without a request. Open the installation’s Access panel. Type the person’s email in Give write access to, and confirm.

Good to know:

  • A grant records who gave it and when. The tool sends an email to the person who asked.

  • You can take access back at any time with Take back. The record is not deleted. It is marked as taken back. So you can still see who removed the access, and when.

  • Access cannot be passed on. A person with access to one installation cannot give it to anyone else. Only an administrator gives access.

  • Every installation has an owner: the person who saved it first. You must be signed in to save, so the tool always knows who that is. An installation has no owner only when it got into the database some other way, not through the tool. You cannot make such an installation from the screens. If you meet one, it shows this message: "This installation has no owner on record, so no one can change it until a support admin grants access." A support_admin names its owner with Set owner. Set owner works only on an installation with no owner. It does not move an installation from one person to another.

See also Requesting access to an installation.