Skip to main content

Admin

The Admin section (visible only to admins) covers member management, tag definitions, and the audit log.

Members

Invite new members by email; they’ll receive an invite with a code to set their own password. If Navigator can’t send invite emails in your environment, you’ll get a shareable invite link instead. A pending invite can be revoked any time before it’s accepted.

From the Members list, admins can change any member’s role, disable/re-enable their access, or hide a former member from the default list (their access is unaffected; hiding only removes them from view, and a “Show hidden” toggle brings them back).

Roles

RoleCan do
AdminEverything, including managing members, connector credentials, and tag definitions
Credential ManagerAdd/edit connector credentials, without full admin access
ContributorApply tags to assets, run configuration audits (once that feature is live)
ViewerRead-only access to every page

Navigator always keeps at least one admin on your tenant. You can’t demote or disable the last remaining admin.

Tags

Tag definitions (rename, delete) are managed here. See Tags for the full picture of tagging, including how tags get applied to assets from the list pages.

Audit Log

A record of configuration/admin actions: member role changes, invites, connector credential additions/edits, tag and category changes. This is intentionally separate from Telemetry, which tracks changes to your asset data rather than account/configuration actions.

Single Sign-On

Connect an identity provider (Microsoft Entra ID, Okta, Google Workspace, or any SAML 2.0-compliant IdP) so your team can sign in with their existing company credentials instead of a Navigator password.

  1. From Admin → Single Sign-On, add a connection: a display name, the email domain(s) it applies to, and your IdP’s metadata, either a metadata URL or pasted metadata XML.
  2. Once added, a connection starts as Optional: members on its domains can choose SSO or a password at login.
  3. Test the connection. Before it can be switched to Required, Navigator needs to confirm you own the domain(s) it applies to; contact support to complete that verification.
  4. Once verified, switch the connection to Required to disable password login for those domains entirely.

Add at least one bypass account before requiring SSO. A bypass account can always sign in with a password, even on a domain where SSO is required, so you’re never locked out if your IdP connection ever breaks. Manage bypass accounts from the same Single Sign-On page.

Creating a password-based account on a Required domain

Once a domain is set to Required, Navigator refuses any password path for it — not just login, but also invite acceptance for a new account on that domain. This is intentional: it’s the same rule closing off the very thing SSO enforcement exists to prevent, applied consistently rather than only at the login form.

If you genuinely need a password-based account on a Required domain anyway (testing, a service account, or a colleague who needs a second, separate Navigator account under the same email domain), there are two supported paths:

  • One-off: switch the connection back to Optional, complete the invite, then switch it back to Required. Anyone already signed in via SSO is unaffected — this only changes whether a new password-based account is accepted while the window is open.
  • Ongoing: add that specific account to the bypass list instead (see above). It keeps password access permanently, without loosening enforcement for the rest of the domain.

When SSO is available, users see a Sign in with SSO option on the login page; entering a work email routes them to the correct identity provider based on its domain, with no separate URL or bookmark to remember.