Users & Access
Users & Access is where an Administrator manages who can sign in to the dashboard and what they can do. It has two tabs: Users and roles and Single sign-on.
Users and roles
Invite, import, enable, and remove dashboard users for the tenant, and change their roles. Users belong to one Company and cannot see the data of another tenant.
Each user is assigned a role that gates their access across the back office and settings:
| Role | Scope |
|---|---|
| Operator | Day-to-day case work — review queue, Accept/Reject, resolve duplicates. |
| Supervisor | Operator capabilities plus data edits, state resets, blocklisting, anonymization, and selected settings. |
| Administrator | Full configuration and user management. |
Full detail is in Roles & Permissions. Role changes are audited.
Single sign-on
Single sign-on (SSO) lets dashboard users sign in with the corporate credentials of the Company, so the account lifecycle and the access policy stay with the identity provider (IdP) of the Company: a user who leaves the Company loses dashboard access when their corporate account is disabled.
Supported identity providers
| Provider type | What you enter |
|---|---|
| Google Workspace | Client ID and client secret of an OAuth client. |
| Microsoft Entra ID | Client ID, client secret and the Directory (tenant) ID of the app registration. |
| OpenID Connect (Okta, Auth0, Keycloak, …) | Client ID, client secret and the issuer / discovery URL. |
| SAML 2.0 (Okta, ADFS, …) | The IdP metadata URL or XML and its signing certificate; no client secret. |
Setting it up
- Open Users & Access → Single sign-on and choose the provider type. The page shows the redirect URI the platform uses for this organization (for SAML: the Reply / ACS URL and the service-provider entity ID).
- In your identity provider, create an OAuth client or app registration (or a SAML application) and paste that redirect URI into it.
- Copy the credentials back into the dashboard and Enable. The client secret is write-only: it is stored, never shown again, and a new one has to be entered to change it.
- Choose the default role that a user gets on their first SSO sign-in (Operator is the safe choice; raise individual users afterwards under Users and roles).
- Test with a colleague: they enter their email address on the sign-in page and are taken to your provider.
Disable removes the provider link; users then sign in with their dashboard password again.
How sign-in works
- The sign-in page is email-first: the user types their email address, the platform looks up the organization by the email domain and forwards them to that organization's provider.
- Every organization also has its own sign-in page at
/login/<organization>, which starts SSO immediately and offers a password fallback for the first Administrator and for accounts without SSO. - A user who signs in through SSO for the first time is created automatically with the default role. Membership is derived from the verified email domain of the organization, not from anything in the URL.
The email domain(s) of the organization are registered and verified by Innovatrics when the tenant is created; contact your representative to add a domain.
Security notes
- Credentials of the Company are never seen by the platform: authentication happens at the identity provider.
- The client secret and SAML certificate are stored encrypted and are not returned by any API or screen.
- All SSO configuration changes are written to the audit log.