Assigning roles, enterprise sign-in, and provisioning

People join, move, and leave, and access has to follow. This guide documents the steps for adding and removing people at each layer, and the offboarding order that verifies a leaver's access is fully gone. It also covers enterprise single sign-on and what just-in-time provisioning does at first sign-in.

Assigning and removing roles

Add someone to an organization

1. In Backstage, go to Organizations in the main menu and select the organization. The organization page opens.
2. Click Members. The list of team members and their roles is displayed.
3. Click Add a member. In the pop-up, enter the person's full name and email address, and select their organization role. Optionally, use the role assignments section in the same pop-up to add them to specific workspaces of that organization and set their role in each.
4. Confirm. The new member receives a welcome email to access Backstage, and they appear in the members list with the role you set.

To change an organization role later, adjust the role in the dropdown beneath the member's name. To grant Developer API access, use the corresponding option on the member entry.

Analytics API access is a separate grant from Developer API access, and it is not one your administrators make themselves. The Analytics API is enabled per organization by SpotMe. Its developer role is enabled the same way. Ask your SpotMe Account Manager to enable the Analytics API for your organization. Ask them to grant the organization-scope Analytics API developer role (account_api_developer) to the users who need it. Where reporting spans several organizations in one account, ask for the customer-scope role (customer_api_developer) too. The organization ID those endpoints take as a parameter is shown in Backstage under Organization > Details.

Add someone to a workspace or content hub

1. In the workspace, go to Settings > Team (in a content hub, Settings > Team members). The current team list is displayed.
2. Click Add team member and enter the person's email address.
3. Choose the role from the dropdown: Manager, Editor, or Viewer.
4. Click Add team member. The person receives an email invitation to access the workspace (or content hub) via Backstage, and the workspace appears in their Backstage list.

Note: If the email address does not correspond to a member of your organization, you are prompted to create the organization member first. Creating one requires an Admin role in the organization.

Adding users to a workspace requires the appropriate role in both the organization and the workspace. One case cannot wait for a workspace role to exist. On a workspace whose team is still empty, the organization Admin role alone carries the first assignment. The condition on both layers applies to members adding themselves or others after that. Organization members can also be added to workspaces centrally. In the organization, open Manage organization > Workspaces, then use Add a member on the target workspace, or Join to add yourself.

Change a role

1. In Settings > Team, select the team member and click Edit.
2. Select the new role and confirm. The change takes effect immediately. The team member receives an email notifying them of the new role, with a link to the workspace in Backstage.

Remove someone

1. In Settings > Team, select the team member and click the trash can button.
2. Click Remove to confirm. The person disappears from the team list. They can no longer access the workspace via Backstage, and it no longer appears in their list of workspaces. No email is sent on removal.

Note: Removing a person's organization membership from the organization Members list ends their sign-in to Onomi 360 as well as to Backstage. Onomi 360 is reached with the same organization account. Removing the membership does not clear their strategic meetings management assignment, which stays on the Users tab of Users and roles until it is removed.

To verify an offboarding, check the layers in order, starting with the one that is easiest to miss.

• First, in Onomi 360, open Users and roles on the Users tab. Confirm the person holds no strategic meetings management role assignment. A leaver who keeps an Approver, Compliance reviewer, finance, program-lead, or Sourcing assignment keeps everything its scope shows, whatever you do at the layers below. Remove any assignment they still hold, as described under Scoped visibility: what each role sees in Agency access and strategic meetings management scope.
• Then reopen Settings > Team and confirm the person is absent from the list, repeating per workspace and content hub they were a member of.
• Next, deal with the API tokens the person created. They are a layer of their own: they sit on the person's profile rather than on a list you administer. A bearer token is created by its holder on the API tokens tab of their own profile in Backstage. It is displayed once at creation, it is long-lived, and it reaches exactly what its owner can reach. No administrator list shows another person's tokens (see Integration patterns: connecting Onomi to your enterprise systems). Have the leaver delete their tokens from that same screen before the account is disabled. Where your organization can no longer reach the account, contact your SpotMe Account Manager.
• After the tokens, check the Analytics API developer role. It is a layer of its own for the opposite reason. Both scopes, organization scope (account_api_developer) and customer scope (customer_api_developer), are enabled by SpotMe through your Account Manager rather than by your administrators. Neither scope appears on any list an administrator works: not Users and roles, not the organization Members list, and not the API tokens tab. Removing the person's organization membership does not retire either scope. The scope stays enabled until your Account Manager removes it, and so does the bearer token those endpoints authenticate with.

  Ask your SpotMe Account Manager to remove the role and to retire the token. That request mirrors the enablement request described under Add someone to an organization above. A holder of the customer-scope role reads across the organizations in your account. Check this layer for anyone who owned a reporting or BI integration.

• Then, in the organization Members list, remove their organization membership. That ends their access to Backstage and to Onomi 360 alike. Onomi 360 is reached with the same organization account, at its own address and from the Backstage application switcher. Removing the membership does not clear a strategic meetings management assignment. That assignment stays on the Users tab of Users and roles until it is removed. It takes effect again if the person is ever re-added or their identity re-enabled. That is why the order above starts there.
• Last comes the layer that sits outside Onomi: your identity provider. Disabling a leaver's identity there ends the federated sign-in path, so that person cannot reach Onomi while the identity is disabled. The provider side of that is documented in Integration patterns: connecting Onomi to your enterprise systems. This layer closes the meeting request portal. The portal is a separate surface reached at its own address with single sign-on rather than through an organization account.

  A requester may hold no organization membership and no strategic meetings management assignment. The five layers above then have nothing to remove, so a run against those five alone returns nothing to do while that person's portal access continues. Disabling the identity at the provider is what closes that access. Treat the disable as part of the same check rather than as something that has already happened.

See also: How to add, edit, or remove team members in an organization, How to add/remove team members in a workspace and edit roles, and How to add/remove team members in a content hub and edit roles.

Enterprise sign-in and provisioning

Onomi supports single sign-on (SSO) over SAML 2.0, OAuth 2.0, and OpenID Connect. It works with corporate identity providers such as Microsoft Entra ID, Okta, and Google, plus any provider that speaks these protocols. People log in with their corporate identity and reach their workspaces in one step. Email is the unique identifier for users.

Choose a protocol and prepare the configuration

SSO is set up together with your SpotMe Account Manager, who provides the configuration for your identity provider based on the protocol you use. What your IdP team prepares depends on the protocol:

• SAML 2.0: your IdP's federated XML metadata file, plus test credentials. If the metadata file is not available, provide the IdP sign-on URL and the IdP's public PEM-encoded X.509 certificate. The connection is SP-initiated, authentication requests are signed, encryption is supported, and the default NameId format is the email address. Logout is not supported.
• OpenID Connect: the discovery URL, the client ID, the client secret, and test credentials. If the discovery URL is not available, provide the issuer URL and the authorization, token, user info, JWKS, and revocation endpoints. Both the code flow (recommended) and the implicit flow are supported. Logout is not supported.
• OAuth 2.0: the client ID, the client secret, and test credentials.

Note: The setup references your app's branding identifier, the same ID used in your app install link. Your Account Manager or SpotMe support can confirm it. The capabilities above cover nominal cases. If your needs require a different configuration, contact SpotMe support.

What just-in-time provisioning does at first sign-in

Users are generally expected to already be present in the workspaces they can attend. Just-in-time provisioning is available, and it is configured per SSO connection. Where it is enabled, the user profile is created and updated at first authentication. The profile is built from the user information contained in the SAML assertions received from your identity provider. Those workspaces then need no pre-loaded user list.

What it creates by default is a workspace user record, the app-side profile the workspace's Users module holds. That record carries the imported profile fields for in-app display, targeting, and personalization. It creates no organization membership in Backstage, adds nobody to a workspace team, and sets no organization role or workspace role. During implementation, an identity provider (IdP) group can be mapped to a predefined Onomi 360 role assignment. Eligible users then receive that role automatically at sign-in.

Two workspace matching modes decide where each user lands:

• EID mode: if your IdP can store additional metadata per profile, it holds a list of event identifiers (EIDs) the user has access to. The EIDs are retrieved during authentication, and the user is automatically added to those workspaces.
• Profile field mode: the user is routed based on profile fields held in your IdP, for example a country or department field. The user record is created in the matching workspace.

During authentication, any profile field can be imported and made available in the workspace. The field can appear on the user's in-app profile, or your admins can use it in targeting and personalization. Profile photos cannot be imported.

One consequence belongs with the rest of your access model, because this is a route into a workspace that no administrator works. The placement is driven by an attribute your identity provider holds, rather than by an administrator adding the person to the workspace. That attribute set is an access control over which events' audiences a person reaches. Review it alongside the assignments in Users and roles and the organization Members list. Treat a change to it as a change to who reaches which events.

What a placed account may do beyond that follows three grants your administrators make: the organization role, the workspace role, and the strategic meetings management assignment. Any predefined Onomi 360 role assignment mapped from an IdP group counts among the third. The containment control over those assignments is set out in Agency access and strategic meetings management scope, under Agencies and external stakeholders and How scope and workspace membership meet.

Verify the setup

Sign in once with the test credentials your IdP team provided. The user record appears in the workspace user list with the imported profile fields populated. That confirms the protocol configuration, the matching mode, and the field import in one pass.

See also: Single sign-on (SSO) and SSO JIT provisioning.

For what this module does and where its boundaries are, see Role-based access and visibility for internal and external stakeholders.

* Onomi 360 MeetingsEQ exclusive capabilities.