Role-based access and visibility for internal and external stakeholders

Your event program involves many kinds of people: planners and admins on your team, field colleagues who request meetings, and agency staff who execute. Audiences only ever see the app.

Onomi separates what each of them can see and do, using layered roles, enterprise single sign-on, and audience-based visibility rules. Each person works with the access their job needs and nothing more.

Roles and access control in Onomi follow the role-based access control (RBAC) model. A person's access follows the role they hold at each layer.

Single sign-on (SSO) is behind the sign-in, so people sign in with their corporate identity.

The guides in this series document the role model and the steps for granting and removing access. They also cover enterprise sign-in with just-in-time provisioning, and how agencies and audience segments fit into the model.

Before you start

• Backstage is the planner-facing admin console of Onomi. You can manage organization, workspace, and content hub roles there. You also manage audience targeting for the app, the attendee-facing surface. See Agency access and strategic meetings management scope for that targeting. Strategic meetings management roles are assigned in Onomi 360 instead, in Users and roles, and the same guide describes them.
• Access is layered. Every Backstage user belongs to one or more organizations and has a role in each. Within an organization, the same user is added to individual workspaces (events) and content hubs, and has a separate role in each of those.
• To manage access you need the right role at the right layer. Only organization admins can add members to an organization or change organization roles. Only workspace managers can manage a workspace's team. Only content hub managers can manage a content hub's team.
• Email is the unique identifier for users across the platform.
• Enterprise single sign-on is configured together with your SpotMe Account Manager. Have your identity provider (IdP) team available for that setup.

The guides in this series

This article is the overview of the series. The three guides below contain the documentation. Read them in order for the full model, or go straight to the guide your task needs.

• Onomi 360 roles, permissions, and scope:
  • the platform role model: organization, workspace, content hub, and tailored task roles.
  • the role reference at a glance. Its last column states per role what an assignment can change on an event in its scope, including each write the platform makes on a role holder's action, such as an award writing the event budget.
• Assigning roles, enterprise sign-in, and provisioning:
  • adding people to an organization, a workspace, or a content hub, and changing and removing roles.
  • the offboarding order to verify when someone leaves, including the identity-provider layer that closes the meeting request portal for a leaver.
  • single sign-on protocols and setup, and what just-in-time provisioning does at first sign-in.
• Agency access and strategic meetings management scope:
  • granting an agency scoped access, and targeting content by audience.
  • the strategic meetings management roles, and scoped visibility with the scope dimensions.
  • how scope and workspace membership meet, with a worked example and the scope verification step at the end.

Reaching a record and changing it are separate permissions

One rule runs through the whole series: reaching a record and changing it are separate permissions.

Which surfaces open at all, and what each assignment can change once a record is open, are both role questions.

Every role and permission in this documentation is named in one place: the role reference in Onomi 360 roles, permissions, and scope.

If other documentation references a section of this article by name, that section is in the guide named above.

* Onomi 360 MeetingsEQ exclusive capabilities.