Roles and user access
Every person who signs in to an environment has one role. The role decides what they can see and change — in the application, through the AI agent, and through the API. Roles are set per environment, so a person can be an Admin in one facility’s environment and a Viewer in another.
The roles
Section titled “The roles”| Role | Intended for | Can | Cannot |
|---|---|---|---|
| Viewer | Partners, contractors, and anyone who should only look | See every page outside the Admin panel. Use existing Live Views and embedded applications (change the time range, filter, drill down). Ask the agent questions. | Change anything. Viewers don’t see the Admin panel, the Changes page, or API keys. |
| Editor | Your own users — the default for everyone | Everything in the main navigation: modeling, publishing changes, Live Views, uploading files, and the agent’s modeling tools. Create their own API keys. | Use the Admin panel. |
| Admin | Your user managers | Everything an Editor can do, plus manage users and roles, review activity and chats, and turn AI on or off for the environment. | Use Sight Machine’s platform tools (backups, reset, gateways, model selection and similar). |
| Sight Machine | Sight Machine staff | Everything, including platform set-up and support. | — |
Viewers see a small Read-only access badge at the bottom of the left navigation. Its tooltip reads You can view everything here, but not change it. Ask an admin if you need to edit.
The agent follows the same rules
Section titled “The agent follows the same rules”The AI agent never does more than the person using it could do themselves. For a Viewer, the agent can explain, query and analyse data, but it won’t stage, publish, upload or configure anything, and it says so when asked. An Editor’s or Admin’s agent can make model changes on their behalf. There is no user management through the agent.
Applications and the API follow the same rules
Section titled “Applications and the API follow the same rules”The same role applies when someone uses an embedded application or calls the API with their credentials. An embedded application is read-only for a Viewer automatically.
How a person’s role is decided
Section titled “How a person’s role is decided”A person’s role is decided each time they use the environment, in this order:
- Sight Machine staff signing in through Sight Machine’s own sign-in always get the Sight Machine role. You can’t change it, and it means an environment always has someone who can manage users.
- An explicitly assigned role — one an Admin set in Admin › Users — comes next.
- Otherwise, Editor. Anyone else who can sign in is an Editor.
So nobody has to be set up by hand for an environment to work. Viewers and Admins are always assigned explicitly.
Because the default is Editor, someone who can sign in without being assigned a role lands as an Editor. Review Admin › Users from time to time: it lists everyone who has signed in, with their role and when they were last seen.
Who may sign in at all is separate from roles. It is controlled by the identity-provider settings agreed when the environment was deployed (see Deploying on Azure), for example a list of allowed groups or an email domain.
Managing users
Section titled “Managing users”Admins manage roles from Users in the Admin panel. Open the Admin panel from its icon at the bottom of the left navigation. Admins see these entries there:
- Users — people and their roles (below).
- Activity — the environment’s activity log.
- Chats — conversations with the agent, across all users.
- AI — one switch, AI for this environment, that turns the agent and every AI feature On or Off for everyone. Turning it off takes effect for everyone within about 30 seconds and is recorded in the activity log; data, models and dashboards keep working.
The Users list
Section titled “The Users list”The list shows Name, Email, Role, Source, Last seen and Staged changes for everyone who has signed in, plus people with a pre-assigned role who haven’t signed in yet (Not signed in yet).
Source says where the role comes from:
| Source | Meaning |
|---|---|
| Sight Machine sign-in | Sight Machine staff. The role can’t be changed here. |
| Assigned | An Admin set this role. |
| Default | Nobody assigned a role, so the person is an Editor. |
| Pre-assigned | A role was set by email for someone who hasn’t signed in yet. |
Staged changes counts changes the person has staged in the shared draft that are not published yet.
Where local accounts are set up for the environment, a Sign-in column shows how each person signs in:
| Sign-in | Meaning |
|---|---|
| SSO | Signs in through your identity provider (single sign-on). |
| Local · enabled | A local account that can sign in. |
| Local · disabled | A local account whose sign-in an Admin has turned off. |
| Local · password change pending | A local account that hasn’t yet replaced its temporary password. |
| Local | A local account set up by Sight Machine rather than on this page. |
| Unavailable | The sign-in information couldn’t be loaded right now. |
The column is blank for someone with a pre-assigned role who hasn’t signed in yet.
Change someone’s role
Section titled “Change someone’s role”Use Change role on the person’s row and pick Viewer, Editor or Admin. You can grant any role up to your own: an Admin can make someone a Viewer, Editor or Admin, and can demote another Admin. If the picker is disabled, hover over it to see why — for example Sight Machine staff roles come from how they sign in and can’t be changed here. or This person’s role is above yours.
If you lower the role of someone who has unpublished staged changes, you are warned. Their changes stay in the shared draft under their name; nothing is discarded.
To undo an assignment, use Remove role. The person goes back to the default role (Editor).
Every role change is recorded: who changed it, for whom, the old and new role, and when.
Set a role before someone signs in
Section titled “Set a role before someone signs in”Click Pre-assign role, enter the person’s Email, choose a Role, and click Pre-assign. The role applies the first time the person signs in; if they already have, it applies now. No email is sent, and this doesn’t create a sign-in for them — they still need to be able to sign in through your identity provider. To withdraw a pre-assignment before they sign in, use Cancel pre-assignment.
This is the way to bring in a Viewer: pre-assign the Viewer role before they first sign in, so they never land as an Editor.
Local accounts
Section titled “Local accounts”For environments that don’t sign in through a corporate identity provider, Admins can create accounts that sign in with an email and password. Click Create local account, fill in Email, Full name and Role, and click Create account. A Temporary Password is shown once: give it to the person yourself, by a separate channel. They must change it at first sign-in. You can also require an authenticator app at first sign-in.
From a local account’s row you can Reset password, Disable sign-in or Enable sign-in, and Delete account. Deleting a local account can’t be undone; the person’s role and history stay.
If the environment signs in through your identity provider, Create local account is unavailable, with the explanation This environment signs in through its identity provider; local accounts are off. Sight Machine can change the realm mode.
When someone is refused
Section titled “When someone is refused”If a person tries something their role doesn’t allow, the application tells them Your access doesn’t include this. An admin can change your role. rather than reporting a failure. To give them more access, change their role in Admin › Users.