← All guides

Tenants, people and roles

Tenants

Each customer is an isolated tenant — devices, views, credentials, jobs and audit are all scoped to one and never bleed across. SentinelOps is multi-tenant by design so an MSP can manage many customers from one console while keeping each one’s data walled off; MSP-level roles can see across tenants and every cross-tenant read is logged. For the customer it is the guarantee that their estate and secrets are theirs alone. Reached from the Dashboard → Tenants tab (global/MSP operators).

Tenant list

One row per visible tenant with its id and creation time. Each offers Manage (opens the tenant’s organization profile and Microsoft 365 view), View machines (jumps to Devices filtered to that tenant), Rename, and — for non-default tenants — Delete. Clicking the row itself opens Manage.

Add a tenant

Add tenant creates a new isolated organization from a name — from that point its devices, jobs, credentials and audit are kept separate from every other tenant.

Migrate resources

The Migrate resources action (top right) moves resources between tenants in a controlled way — used when reorganising customers or correcting where something was enrolled.

Removing a tenant

The red Delete removes a tenant (needs operator.manage). Deletion does NOT cascade and is refused while the tenant still owns any device, job, credential or audit record, or has an active legal hold — so first move or remove those (decommission then Remove its devices, disconnect its cloud connectors, clear its credentials). When the server refuses it returns the exact dependency breakdown so you can clear the blockers. The default tenant cannot be deleted.

Users

Every person with access to this organization — operators, engineers, administrators and customer-portal accounts — in one table scoped to the tenant selected in the top bar. SentinelOps keeps it here so access is granted, scoped and revoked from a single place rather than spread across the systems people use. For the tenant it is the definitive record of who can sign in, what they may do, which devices are theirs, and whether they are protected by a second factor. Creating a user issues a temporary password they must change at first sign-in, and every action is audited against this tenant.

The table, column by column

Each row shows Name/email, Username, Role (with account type), Status, Mobile account + Platform, 2FA (the registered methods, or "none"), SSO (linked or local), Devices assigned, Last login and Last seen. "Pending" status means the account has not yet signed in and changed its temporary password. Click a row, or Manage, to open the account.

Create a user — field by field

Create user opens a form: Full name, Username (required), Email, Phone and Role (only roles within your own authority are listed). "Add from a directory…" fills Name/username/email from an existing Microsoft 365 user instead of retyping. For a staff role a Mobile access section appears — tick it to create a mobile operator account, pick a device platform, and (with mobile.operator_tokens.create) generate the operator token + enrollment QR now, setting its valid-for hours and device limit. A temporary password is issued and shown once; the token and QR are shown once too. The mobile app is for staff, so the section is withdrawn entirely for a customer-portal role.

Manage an account

The detail panel shows role, status, 2FA, SSO, device count and last login, plus the assigned Devices (assign or unassign). Two-factor requirement can be set per account to follow the organization policy, be required, or be exempt — enrolment itself is always done by the person. Edit permissions pins permissions on the account (only permissions you hold yourself are offered, the same ceiling the server enforces). Tenant access (for a non-portal account) ticks additional tenants an engineer may work in.

Account actions

From the detail panel: Reset password (issues a one-time temporary password and signs them out), Unlock (clears a lockout after too many failed sign-ins), Reset 2FA (removes their second factors so they can sign in with a password until they re-enrol), Sign out everywhere (kills every session), Enable/Disable account, and Delete user (removes the account, deletes its mobile account, revokes its tokens and unassigns its devices — the audit trail is kept). Each is permission-gated and confirmed.

Roles

What each kind of account may do, expressed as a named set of permissions. Built-in roles are fixed and ship with the platform; you can also define custom roles for this organization. SentinelOps centralises this so access is granted by job function rather than by hand-picking permissions per person, and so a tenant can never create a role more powerful than the person who created it. For the tenant it is how "help desk" or "read-only auditor" becomes a reusable, least-privilege building block they assign to users and groups.

Built-in roles

Shown with their exact permission set: Engineer is the top operating role; Administrator runs tenants and fleets; Auditor is read-only. Each is tagged platform or tenant-scoped. These cannot be edited or deleted — they are the fixed baseline every custom role is measured against.

Create a custom role — field by field

Create role opens a form: Name, Description, and a checklist of Permissions. Only the permissions you hold yourself are listed, because the server caps a new role at the creator’s own authority on save. You must tick at least one permission. The role then applies to this organization and can be assigned to users directly or through a user group.

Delete a role

Delete removes a custom role, but the server refuses while any account still uses it — move those accounts to another role first. Built-in roles have no delete.

Two-Factor

Second-factor coverage across this organization and, specifically, the accounts still without one. It is a focused slice of the Authentication policy: a worklist rather than a settings page. SentinelOps surfaces it because an account with only a password is the weakest link, and the fastest way to close the gap is a list of exactly who to chase. For the tenant it turns "are we all on 2FA?" into a short, actionable roster.

Coverage

A one-line count of how many accounts out of the total have a second factor registered. When everyone is covered the view says so plainly instead of showing an empty table.

Accounts without 2FA

A table of the accounts still missing a second factor — name, role and last login — each with a Manage button that opens the account. Enrolment is always done by the person themselves (an administrator cannot scan a code into someone else’s authenticator), so from the account you set whether 2FA is required and they complete it at next sign-in.

Setting the requirement

Whether 2FA is required for everyone is set under Authentication → Require two-factor; per-account exceptions are set on the user. This view is the coverage report that tells you where to apply those settings.

Next: Use the API →