Agency access and strategic meetings management scope

Agencies and external stakeholders work inside your events, and strategic meetings management adds business roles with scoped visibility on top of platform access. This guide documents agency containment and audience targeting. It also documents the strategic meetings management roles, the scope model and what each role sees, and how scope and workspace membership meet. The per-role write answer those sections rely on is the role registry in The role model and role registry.

Agencies and external stakeholders

Grant an agency scoped access

Agency access follows the same role model, scoped per workspace, so an agency user sees only the events they have been added to.

1. For each event the agency runs, add the agency staff to that workspace via Settings > Team, with the role the work requires. Editor builds and runs the event. Manager also owns settings and team membership. A tailored role such as Meeting planner or Badge printing staff suits onsite suppliers. Each person receives an email invitation to the workspace.
2. If an agency planner is not yet a member of your organization, you are prompted to create the organization member during the add step. Give agency staff the Guest organization role, and grant their working role per workspace. Do not give agency staff a Member organization role. Organization members hold Editor permissions in any workspace of the organization they access. A workspace Viewer role does not restrict an organization member. A Member role would therefore defeat the per-workspace containment this section builds.

   

3. Verify the scope: the agency user's Backstage list shows only the workspaces they have been added to, and nothing else in your organization.
4. When the engagement ends, remove them from each workspace and content hub. Removal takes effect immediately, the workspace disappears from their list, and no email is sent.

Note: Where an agency also holds a strategic meetings management role, the same care applies to the scope on it. A Sourcing assignment reads more than the Sourcing module. On every event inside its scope it opens the event record read-only.

That read-only view includes the event's budget with its cost lines and their attendee attribution, the event's travel records, and the event's Transfer of value module. The Transfer of value module shows the amount allocated to each healthcare professional in the transparency categories, their attendance state, and the remainder left unattributed on the event. That last module is why the scope matters here more than anywhere else. It holds the identity, consent, and attendance states behind every allocation. An agency's Sourcing assignment is therefore scoped to the events it actually sources for, rather than to a whole market it happens to work in. The control on that is the scope you give it. Scope an agency's assignment to the geographies and business units it actually sources for, and narrow it when the engagement changes.

Target content by audience

On the audience side, visibility is managed by profile. Targeting applies across the attendee-facing surfaces: feed posts, emails, live-session polls, custom participant lists, custom session lists, app menu items, and notifications. Custom session lists include which sessions a group can see and register for. Rules are built from user profile fields (metadata) of the types boolean, choice, choice list, email, hidden, number, text, formatted date-time, and display-only.

Four kinds of conditions are available:

• a single condition.
• multiple individual conditions (match A or B).
• multiple combined conditions (match A and B).
• exclusion conditions, which hide content from a segment even when it matches the visibility rule.

To configure one:

1. Open the content you wish to target and find the targeting fields. Under This item will be visible to app user matching any of, click the settings icon. The targeting menu opens.
2. Under Add a condition to match, select the profile field to target (for example country), click Add, and enter the value to match (for example France).
3. Click OK. The rule appears on the content in Backstage, and the item is now visible only to matching users. For exclusions, apply the same steps under Invisible to everyone else.

Targeting configurations can also be imported from an Excel spreadsheet, which is practical when applying conditions across a full agenda at once. Profile fields arrive from your IdP at sign-in. Internal attendees, healthcare professionals, and agency contacts each then see the content intended for them, without manual list upkeep.

See also: How to configure targeting.

Roles for strategic meetings management

Strategic meetings management adds business roles on top of platform access, so the flow from request to reconciliation has a named owner at every step. These roles do their work in Onomi 360, the application where the meeting request portal, approvals, budget, and transfer of value live. Workspace roles keep governing event execution, as described in The role model and role registry.

Onomi 360 is reached at its own address and from the application switcher in Backstage. Its administration sits with your Backstage organization Admins, who hold the Policies area, including the Event requests configuration. Strategic meetings management roles and their scopes are granted in Onomi 360 under Users and roles. Requesters never need Backstage. Strategic meetings management roles and their scoped visibility are available since the 2025.10 release.

• Requester: raises meeting and event requests through the meeting request portal, the requester-facing entry of Onomi 360. The portal is a separate surface from the program-layer sections of the application: the calendar, Contacts, the dashboards in Insights, and reports. The portal is reached at its own address by link and single sign-on, with no workspace access and no role assignment needed. Those program-layer sections need an assignment.

  Requesters follow their own requests in their request history. Each record carries two separate fields. One is the request status: Draft, Submitted, In review, Approved, Declined, In execution, Closed, Withdrawn, or Cancelled. The other is the registration status of the linked event. Where the request's category is mapped to record-only there is no registration journey. The registration status then stays empty, and the request status is the whole of what the requester follows.

• Approver: holds an assigned role with a scope. Holding the role is the permission. Only role holders can be named in an approval level. A colleague without the grant is not listed for selection when your administrators build a rule.

  Which approver a given request goes to is never picked by hand. Routing computes it from budget band, attendee type, and request category together. The request carries an escalation ladder and a visible trace of why this approver was selected. An approval level that names a role places one shared approval in the personal My approvals queue of every holder whose scope covers the request. Any one of them may act, and the trail records who acted and when.

  Reminders go to every holder with the approval still pending. Escalation after three reminder cycles moves the whole queue to the next level, or to the organization administrators where no further level exists. A delegation set by one holder passes only that holder's own items for the date range, and leaves the queue otherwise intact. Approvers act directly from the notification email, with no login required. Declines require a reason, and a resubmitted request carries the prior comments forward.

  A request approves itself under policy when its budget band qualifies against the configured threshold and its category is one your organization designated for it. The rule that fired stays visible on the record. A requester selects a band rather than an amount, so the comparison runs on the band's bounds. A band qualifies only when its To value is at or under the threshold. A band that straddles the threshold does not qualify, and the open-ended top band never qualifies.

  Where healthcare professional or public-official attendees are present, the compliance gate still applies. Such a request completes without human review only when a compliance auto-clearance rule clears the gate. The rule trace stays on the record. Routing rules, thresholds, auto-approval, and notification recipients are settings your admins tune in Onomi 360 under Policies. The setup is documented in Configuring approval routing, the compliance gate, and auto-approval and in Configuring notifications for requests and approvals.

• Compliance reviewer: holds a separate approval that fires on the trigger conditions your organization configures, with healthcare professional or public-official attendees present as the shipped default. The trigger conditions, the rules that clear a triggered request without review, and the routing are all settings. They are documented field by field in the Configuring the compliance gate section of Configuring approval routing, the compliance gate, and auto-approval, which is where this gate is configured.

  The approval is routed to a reviewer group and appears in each selected reviewer's personal queue. Any reviewer in the group can act. The compliance approval is additive: it runs independently of the budget approval and does not replace it. Here too the grant is the permission. Only role holders can be named in the default reviewer list or a gate routing entry, and a colleague without the grant is not listed for selection.

  The grant carries no venue decision. A venue rule's result follows from the rules your organization configured for the market, and is recorded on the venue entry. A refused venue is therefore refused outright, as documented in Setting venue rules in Onomi 360.

• Finance role: starts execution on an approved event, owns post-event reconciliation and closure, and cancels an approved or in-execution event. An assigned finance owner is named per event.

  Start execution moves the request to In execution. Where the request's category is mapped to Create at Start execution, it also creates the event workspace from the template that mapping names. See Configuring what approval creates in From approval to execution and auditing requests. A holder of this role whose scope covers the event holds it. Where the category is mapped to Create at approval, the workspace already exists, and the planners of that workspace (workspace Manager or Editor) hold it too.

  Whoever selects it becomes the first Manager of the workspace it creates. That first Manager is what lets the rest of the team be added, since only workspace managers manage a workspace's team. A workspace created at approval opens with no team, because nobody selected an action to become its first Manager. Its first planners are added centrally by an organization Admin, from the organization Members flow or from Manage organization > Workspaces > Add a member. Start execution reaches that workspace's planners only once planners have been added that way. Until then, a holder of the finance role whose scope covers the event is the actor.

  Cancellation is not a grant of its own. Cancel event is available to the same holders Close event is. Those are the event's finance owner and the other holders of the finance role whose scope covers the event.

  The event's named finance owner holds a further set on their own event:

  • confirming, excluding a line from, reopening, and correcting a transfer of value allocation.
  • routing a reimbursement claim.
  • dismissing a row in the Unmatched invoices view of the event's budget with a reason.
  • recording a reason on a Meal cap exceeded flag to clear it.

  Each is listed in the registry row in The role model and role registry with the article that documents it.

  Holding another strategic meetings management role over the event opens the record but not these controls. An Approver, a Compliance reviewer, a Sourcing grant holder, or a Program lead assignment covering the event does not open Cancel event. The cancellation step, its required reason, and what it does to the connected modules are documented in From approval to execution and auditing requests. The budget structures this role works against are categories, cost lifecycle, and budget policies. Those, and closing the money on a delivered or a cancelled event, are documented in How to use the Budget module.

• Sourcing: works the Sourcing module on the events in scope: the venue search, the RFP, bid comparison, the award, and the contract. Organizations grant it to the planners who source, or to the agency of record sourcing on their behalf. The module and its flow are documented in How to source a venue from your event.
• Program lead: reads the program layer for their scope: the calendar, Contacts, the dashboards in Insights, and reports. The scope on their assignment bounds all four. The role approves nothing and executes nothing. It exists so program oversight does not require organization-wide access.

Occasional requesters do not need a license: anyone in your organization can submit a request and track its progress without holding a seat. The role set distinguishes internal and external user groups, so agency planners can hold scoped meeting-management roles the same way they hold workspace roles today. Every request, approval, decline, and status change is recorded with who acted, when, and why, and the record can be exported for audit.

Scoped visibility: what each role sees

Every strategic meetings management role assignment carries a scope, built from the organizational dimensions your program runs along, and the assignment answers two separate questions. Five surfaces answer to it: the Event requests, the portfolio calendar, Contacts, the dashboards in Insights, and reports. Which of those surfaces opens at all is decided by the assignment a person holds, and the scope on that assignment bounds what each surface it opens shows. The list below states both, role by role. Scope complements routing rather than repeating it. Who approves a request is computed from the request itself, as described above. Who sees it follows the scope.

A scope is set per assignment from these dimensions:

• Geography: the countries the assignment covers. Requests and events located in them are visible to the assignment. Geography is the scope model's name for the geography a record already carries, rather than a second value kept beside it. On a request or an event record, that geography is the Country and city field. The dimension and the field are one fact under two names.

  An assignment, or a routing entry, is scoped by selecting countries from the platform's country list. Those values are the whole of what the scope holds. Neither a market name nor a region name is itself a selectable scope value. Covering a market or a region therefore means naming the countries in it, within the 25 values per dimension one assignment holds. The assignment steps below set out that limit.

  A market is a named grouping of geographies your organization uses for policy: meal caps, venue rules, and the accommodation cap in the travel policy. A market is expressed through the geography dimension, rather than being a scope dimension of its own. The Markets list itself is maintained by your administrators in Onomi 360 > Policies > Markets. It is documented in the Maintaining the Markets list section of Setting venue rules in Onomi 360.

• Business unit: the business unit or division the assignment covers.
• Therapeutic area and Brand: optional dimensions for organizations that run their program along them. Leave them unset to scope by geography and business unit alone.

Three of those four dimensions run on lists your organization defines. Geography is the exception: its values are countries, taken from the platform's country list, so there is nothing to maintain. The Business unit, Therapeutic area, and Brand lists are maintained by your organization administrators in Onomi 360 > Policies > Dimensions. Administrators alone edit them, exactly as they alone edit every other Policies setting.

A value carries a name, an optional code for your own systems to match on, and an active or retired state. Values are added on the same tab. An administrator selects Add a value and completes those three fields. That is how each list is built in the first place, and how it grows afterwards. The same list serves every reader of the dimension. It supplies:

• the values offered in the corresponding field of the request form.
• the values your administrators pick from when they scope a role assignment, a compliance routing entry, or an auto-clearance rule.
• the groupings the calendar and the reports offer.

Renaming a value renames it everywhere it is shown, because a record and a scope hold a reference to the value rather than a copy of its name. Retiring a value works the other way round. Records that already carry it keep it, and stay readable, reportable, and in scope. The value stops being offered on new requests and in new scope selections. A division you no longer run therefore leaves its history intact, without appearing on this year's forms. A retirement is the change that calls for the review described in the Note below. A scope built on the retired value keeps working while nothing new arrives inside it.

These dimensions are not read by role assignments alone. They are the scope model your other strategic meetings management settings are built on, so one organizational shape drives all of them.

• A role assignment carries a scope, as set out here.
• Each routing entry on the compliance gate carries one, which is how a triggered request reaches the reviewers of its own geography and business unit.
• So does each compliance auto-clearance rule. The rule's Scope is built from geography, business unit, and, where your organization uses them, therapeutic area or brand. The rule clears only the requests inside its scope. A rule left unscoped applies organization-wide.

Where more than one routing entry could take the same request, one rule settles it, and the gate's own field description states that rule. Entries are evaluated in list order. The first entry whose scope matches the request is the one that receives it. A request matching no entry routes to the default compliance reviewers. Entries are reorderable, so a reviewer's personal queue membership is never ambiguous and your administrators change which entry wins by reordering them.

The ceiling on a scope belongs to the scope rather than to what reads it. The 25 values per dimension that bound a role assignment bound a routing entry and an auto-clearance rule in the same way. Where a scope has to cover more countries than that, write more than one of them. One option is a second role assignment for the same person, whose scopes the person sees the union of. The other is a second routing entry or auto-clearance rule naming the remaining countries.

Keep the entries of one review team adjacent in the list, so the first-match ordering stays readable after the split. The gate's routing entries and its auto-clearance rules are configured in the Configuring the compliance gate section of Configuring approval routing, the compliance gate, and auto-approval.

A scope matches against the dimensions the record already carries. Requests carry these dimensions from the request form: Country and city, Business unit, and, where your organization uses them, Therapeutic area and Brand. See Configuring the request form and its categories. A dimension no request carries is a dimension you cannot scope along, so keep the dimensions your program runs on required on the form.

An event that arrives already approved from your CRM carries the same dimensions a different way. It never passed through the request form. Its geography, business unit, and, where your organization uses them, therapeutic area and brand come from the inbound field mapping your CRM and event teams configure on the connector. That connector is documented in Integration patterns: connecting Onomi to your enterprise systems. Scoped visibility reads those values exactly as it reads the ones a portal request carries.

The consequence is the same on both paths. A dimension the mapping does not carry is a dimension you cannot scope along. An event that arrives without a business unit does not appear to a role scoped to one. It stays visible to organization-wide assignments and to the planners of its workspace, on the paths described under How scope and workspace membership meet below. Map every dimension your program scopes on before the first upstream event arrives. What such a record carries is documented in the Events approved upstream in your CRM section of From approval to execution and auditing requests.

Note: A change to your organizational lists reaches scopes and records in two different ways.

• A rename carries: a record and a scope follow the new name without being rewritten.
• A retirement, or a country moving from one market to another, does not rewrite what was already saved. Requests, events, and assignments keep the values they carried.

Review the Users tab of Users and roles after any change to your organizational lists. The list shows each assignment's scope beside the role, which is where a stale one shows up.

To assign a scoped role in Onomi 360:

1. Open Users and roles. The destination opens on the Users tab, which lists every person holding a strategic meetings management role in your organization, with the role and its scope beside each person. The Roles tab beside it lists the role definitions themselves, with no people in them. The definitions are read behind that tab rather than edited: a role is assigned and scoped rather than authored. The role set your organization goes live on is reviewed with your SpotMe team during implementation (see The role model and role registry).
2. Select Assign role and choose the person and the role. The picker lists your organization's existing members only. A colleague who is not one yet is added first, as described under Add someone to an organization in Assigning roles, enterprise sign-in, and provisioning. They appear here once they are a member. Requesters need none of this. Submitting and following a request in the meeting request portal needs no assignment, and no Backstage access.
3. Set the scope values: pick the Geography and the Business unit, and, where your organization uses them, the Therapeutic area or Brand. One assignment holds up to 25 values per dimension. Alternatively, select Organization-wide to give the assignment visibility across every dimension.

   

4. Select Save. The assignment appears in the list with its scope shown beside the role. To give one person more than one scope, or a spread wider than the 25 values a dimension holds on one assignment, add a further assignment. A user with several assignments sees the union of their scopes.

   

Assignments change as people move, and the same list is where you change or end one. To remove or change a scoped role:

1. On the Users tab of Users and roles, select the assignment. It opens on the person, the role, and its scope.
2. To move the assignment, select a different role or edit the scope values, then select Save. The list shows the new role and scope.
3. To end the assignment, select Remove, then confirm. The assignment disappears from the list.

A removal takes effect immediately and ends visibility of the requests and events in that scope. They leave the person's Event requests, calendar, Contacts, dashboards, and reports as soon as the change is saved. The same applies to the scope values you take away when you narrow an assignment.

What is already recorded stays recorded. Approvals the person granted remain in the audit trail with their name, the date, and their comments, because the trail records what happened rather than who holds a role today. Approvals still pending with them do not vanish either. An organization administrator reassigns each one to another holder of the same role, or lets the escalation ladder carry it to the next level. Both routes are described in the Delegation, reassignment, and escalation section of Approving requests and working your review queue. Every assignment, change of scope, and removal is itself recorded with who made it and when.

Note: Removing a scoped role does not remove the person's workspace roles, and removing someone from a workspace does not remove their scoped roles. An offboarding covers both layers, in the order set out in Assigning roles, enterprise sign-in, and provisioning.

Which surfaces an assignment opens, and what each of them shows under its scope, is as follows:

• Requester: their own requests, always, with or without any scope. Submitting and tracking a request in the portal needs no scope and no role assignment at all. The surfaces are the meeting request portal and their own requests, and nothing else: no assignment is involved, so no program-layer section opens.
• Approver: the requests inside their scope, plus every request routing sends them. A request routed to an approver is visible to that approver whatever its scope. Those requests are read in Event requests, which is the surface this assignment opens. The assignment also opens the event records inside the scope and their per-event modules, which open read-only on the terms the role registry states. Those modules are the Budget module and its cost lines, the event's travel records, and the event's Transfer of value module with the per-healthcare-professional allocations, attendance states, and unattributed remainder the Sourcing bullet below enumerates.

  The assignment opens no calendar, no Contacts, no dashboards, and no reports. A classification handling rule never withholds a request from an approver it has been routed to. That is the same footing as the organization administrator's administrative visibility and a requester's view of their own submissions.

• Compliance reviewer and finance role: the requests and events inside the full scope on their assignment. That means its geography, its business unit, and, where your organization uses them, its therapeutic area or brand. A reviewer covering one market sees that market's work in their personal queue, rather than the organization's full list. A reviewer aligned to a therapeutic area sees that therapeutic area's work. Compliance gate routing entries are scoped on the same dimensions, so a reviewer also sees every approval routed to them.

  A request the compliance gate routes to a reviewer appears in that reviewer's personal queue, and is workable by them whatever its scope. The gate routes it through a routing entry or the default reviewer list. The reviewer's own scope bounds every other event record and venue control they can read.

  The two assignments open different surfaces. A compliance reviewer's assignment opens My compliance reviews in Event requests, the event records in scope, and the venue controls on them. It opens no calendar, no Contacts, and no dashboards. Where the gate's trigger conditions name the speaker-program category, the compliance approval it produces appears in that personal queue like any other compliance approval the gate produces. A classification handling rule never withholds a request from the compliance reviewers the gate has routed it to. That is the same footing as the organization administrator's administrative visibility and a requester's view of their own submissions.

  A finance-role assignment opens the Event requests, the event records in scope, and the cost-facing reports bounded by that scope. Those reports are the Costs report, the costs entity of the report builder, and the reinvoicing summaries. The assignment opens no Contacts. Where AI assistance is enabled for your organization, the natural-language question panel rides the reporting surfaces rather than being a surface of its own. This assignment therefore reaches the panel on the cost-facing reports it opens, with the answers bounded by the same scope (see How to use AI assistance in Onomi 360).

  On the events its scope covers, the reviewer's assignment reads the venue rules and their results. It decides none of them. A venue a rule refuses is refused outright, as documented in Setting venue rules in Onomi 360. A Draft request is visible only to its requester, so a Draft request reaches a reviewer only once it is submitted. On the events in scope that have no workspace, the finance role's assignment also opens the event record's attendee list for editing. See How scope and workspace membership meet below.

• Sourcing: the events inside the scope on their assignment. The assignment opens those event records and their per-event modules on the terms the role registry states. The Sourcing module is writable under the grant, and the rest of the record opens read-only. That read-only part includes the Budget module and its cost lines, the event's travel records, and the event's Transfer of value module. The Transfer of value module shows the amount allocated to each healthcare professional in the transparency categories, their attendance state, and the remainder left unattributed on the event.

  It opens no program-layer section, so it adds no program-layer visibility of its own. A Sourcing assignment opens the event records inside its scope, and no list of its own. The events to source are reached two ways. One is a direct link to the event record, sent by the event's finance owner or by the planner handing sourcing over. The other is the event's workspace, where the holder is a member of one.

• Program lead: the geography, business unit, and, where used, therapeutic area or brand on their assignment. The assignment opens the calendar, Contacts, the dashboards in Insights, and reports across the scope on the assignment. It also opens the event records inside that scope and their per-event modules read-only. Where AI assistance is enabled for your organization, the natural-language question panel rides the calendar and reports rather than being a surface of its own. This assignment therefore opens the panel there, with the answers bounded by the same scope (see How to use AI assistance in Onomi 360).

An organization-wide assignment widens the scope rather than the surface set: it sees everything its role opens, across the organization, rather than everything in the application. Two consequences follow. A holder of the finance role and an Approver do not open Contacts, which is a Program lead surface. A Program lead reads the calendar, Contacts, the dashboards in Insights, and reports without opening an approval, a compliance decision, or a module write.

Agency and external seats are bounded by their scope. An agency planner holding a strategic meetings management role sees the requests and events of the scope on their assignment, and nothing wider. Where an agency of record runs your sourcing, this is the grant it holds: the Sourcing role with the scope you set. Alongside it sit the Guest organization role and the per-workspace containment described in Agencies and external stakeholders above. Their access is therefore bounded twice, once by scope and once by workspace membership.

How scope and workspace membership meet

Three clauses govern, one per surface.

The program-layer views in Onomi 360 follow strategic meetings management scope: the Event requests, the portfolio calendar, Contacts, the dashboards in Insights, and reports. Which of those surfaces opens at all is decided by the assignment a person holds, and the scope on that assignment bounds what each surface it opens shows. The per-role list is in Scoped visibility: what each role sees above.

The workspace surfaces follow workspace membership. Who can open, edit, or view an event's workspace in Backstage follows the workspace roles documented in The role model and role registry. A scope opens no workspace that already exists.

One route does lead from a scope to workspace membership, and it is an action rather than an access rule. On an event whose request category is mapped to Create at Start execution, selecting Start execution creates that event's workspace. Whoever selects it becomes the first Manager of the workspace that action creates.

A holder of the finance role whose scope covers the event holds that action. A strategic meetings management scope with no workspace membership is therefore enough to become the Manager of the workspace this action creates. That Manager role carries the workspace surfaces on that event, including the attendee identity resolution, consent records, and attendance state the Users module governs. The control on that is the Event creation mapping, stated with the rest of the containment guidance below.

The per-event strategic meetings management modules that sit on an event record in Onomi 360 (Request, Budget, Sourcing, Travel, and Transfer of value) open on two paths.

• They open to users whose strategic meetings management role scope covers that event. What each of those roles may write once the record is open is stated per role in the last column of the role registry in The role model and role registry.
• They also open to the planners of that event's workspace. A workspace Manager or Editor role opens that event's execution-adjacent modules, and nothing program-wide.

The invariant holds across both paths: neither widens the program-layer views, which stay bounded by strategic meetings management scope.

A planner of the event's workspace reaches that event's record and its per-event modules even where their strategic meetings management scope does not cover it. They open it from the event's workspace or from a direct link. The program-layer lists, search results, and reports stay bounded by scope, so a record outside a user's scope does not appear in them.

A classification handling rule narrows both paths and widens neither. Where the rules on a record's classification level withhold it from a user, that record does not open. That holds whether they reached it through their strategic meetings management scope or as a planner of the event's workspace. No handling rule opens a record to someone neither path admits.

A record reached by a direct link, from Event requests, or from the calendar does not open. The message names the rule rather than the reader's scope: "You cannot open this record. A classification handling rule on its level withholds it from you. Ask your organization Admin to check the View rule for that level.", so a reader whose scope already covers the event is not sent to ask for a scope they already hold.

The two paths differ in what they let a person change. The strategic meetings management scope path is read-and-configure inside Onomi 360. It opens the event's per-event modules, their settings, and their records at the level the registry's write column states for the role held. It never opens workspace-side attendee editing.

Changing an attendee's identity resolution, their consent record, or their attendance state is work on the user list of the event workspace's Users module in Backstage. That work needs planner membership of that workspace. A person whose access comes from a strategic meetings management role alone reads those states in Onomi 360, and asks a planner to change one. The guides that depend on those states say so at the step where they matter: How to manage transfer of value on your events and How to manage payments, honoraria, and reimbursement on your events.

That rule describes an event that has a workspace. An event in a request category your organization mapped to record-only has none, and it reads differently. The attendee, the attendance state, and the consent reference sit on the event record in Onomi 360. There is no workspace planner membership for anyone to hold. The grant that opens them is a holder of the finance role whose scope covers the event.

That is the role the registry in The role model and role registry carries the write on. On an event with no workspace, a finance-role assignment whose scope covers the event carries the write on the event record's attendee list. That write is adding an attendee and setting the Show and No-show state. No other strategic meetings management role opens that write.

The self-service small-meeting categories are record-only by default, so this is the lane most of your meetings run in. Grant the finance role a scope that covers those events, rather than leaving the record without a named owner. What the lane records, and where its consent value comes from, is documented in Meetings with no workspace, in Running and correcting an allocation.

The workspace path has a consequence inside your own organization as well. Because a planner of an event's workspace holds that event's per-event writes, who holds the Member organization role is itself a segregation-of-duties control. Organization members work with Editor permissions in the workspaces they access. Membership of an event's workspace can be arranged centrally as well as from the workspace itself. In Manage organization > Workspaces, a member is added to a workspace with Add a member, or joins it with Join. Each of those requires the appropriate role in both the organization and the workspace.

The central path is what staffs a workspace created at approval. A workspace created that way is created from the workspace template the mapping names, and starts with no team. Nobody selected an action to become its first Manager, and only a workspace Manager manages a workspace's team. Its first planners are added centrally by an organization Admin, either from the organization Members flow, using the role assignments section of Add a member, or from Manage organization > Workspaces > Add a member.

On a workspace whose team is still empty, the organization Admin role alone carries that first assignment. The condition on both layers applies to members adding themselves or others after that. Where the category is mapped to Create at Start execution instead, the person who selects Start execution becomes the workspace's first Manager, and the team is built from there.

A member who joins or is added that way is a planner of that event. The workspace-role row of the registry in The role model and role registry therefore governs them on that path. That holds whatever scope their own strategic meetings management role assignment carries, and whether or not they hold one at all. The per-event Budget writes, the per-event Travel writes, and the transfer of value preparation that row names are open to them on that event.

Where the per-event write boundary has to hold for internal colleagues as well as for external ones, set it at the organization layer rather than expecting the modules to hold it. Give internal staff who should not write on event money a Guest organization role and their working role per workspace, exactly as Agencies and external stakeholders above prescribes for agency staff. Keep the Member role for the people whose job is executing events. Review the organization Members list alongside Users and roles when you review access, because the organization role is what decides whether a workspace can be reached at all.

One route into a workspace is not closed by that control, and it takes a setting rather than a role. On a request category mapped to Create at Start execution, whoever selects Start execution becomes the first Manager of the workspace that action creates. A holder of the finance role whose scope covers the event holds that action. A strategic meetings management scope alone can therefore produce workspace membership on those events.

Where the workspaces of a category have to be staffed centrally, map that category to Create at approval on the Event creation tab. Its workspaces are then created with no team. Their first planners are added by an organization Admin on the central path described above. See Configuring what approval creates in From approval to execution and auditing requests. Which categories carry which mapping is therefore an access decision as much as an execution one, so review it with the rest of your access model.

One further route is not an administrator action either, and it takes an identity-provider attribute rather than a setting of yours. Where just-in-time provisioning is enabled on your single sign-on connection, first sign-in places the account in the workspaces the matching mode selects from the assertion. The attribute set your identity team maintains therefore decides that placement.

What that placement creates is a workspace user record, the app-side profile the workspace's Users module holds. It is not membership of the workspace team. It sets no organization role, no workspace role, and no strategic meetings management assignment, so it carries none of the per-event writes this section governs. The Guest organization role that contains the agency and external-stakeholder route is not the control that closes this route.

The attribute set is still an access control over which events' audiences a person reaches, so review it alongside Users and roles and the organization Members list. What that placement carries, and what it leaves with your administrators, is set out under What just-in-time provisioning does at first sign-in in Assigning roles, enterprise sign-in, and provisioning.

One of those modules carries a further condition. Acting in the Sourcing module needs the Sourcing grant on top of either path. Acting means running a venue search, issuing an RFP, comparing bids, awarding, and holding the contract. Without the grant, the sourcing status and the awarded venue stay readable on the event record to everyone who reaches it on either path. How the module itself works is documented in How to source a venue from your event.

Your organization administrators reach one thing beyond both paths, and only for administration. Organization administrators hold organization-wide visibility of requests in Event requests for administration only. That means opening an escalated or stalled request, reassigning a pending approval to another holder of the required role, and re-routing a request that could not be routed. Administrator access carries no approval right and no module write of its own.

On the request records themselves, those three actions are the whole of it. The visibility exists so that a request never comes to rest where nobody can reach it, whatever scope the administrator's own role assignments carry. An administrator therefore does not approve, decline, clear a compliance gate, or write to an event's Budget, Sourcing, Travel, or Transfer of value module by virtue of being an administrator.

Administrator access is separate from scoped role visibility, and does not widen the program-layer views. The calendar, Contacts, the dashboards in Insights, and reports show an administrator the scope on their own role assignment and nothing more. That bound holds on Reports as it does everywhere else, because an administrator has no configuration right there that widens what they read.

Handling rules narrow the two paths that reach a record: strategic meetings management scope, and workspace membership. They do not remove the administrative visibility of requests in Event requests that organization administrators hold. That visibility exists so a request never comes to rest where nobody can reach it. It stays bounded to the three administrative actions, with no module write and no approval right. The reassignment, escalation, and re-routing steps are documented in the Delegation, reassignment, and escalation section of Approving requests and working your review queue.

Two further administrative jobs are worked from Event requests, and neither is an action on a request.

• The Request form tab of Event requests is where the portal address is read, and where the request categories and their fields are configured. The controls there are Add a field, Remove, Add category, Retire, Available in the portal on each category, and renaming a category. All of it is documented in Configuring the request form and its categories.
• Held arrivals is where an event record your CRM sent that could not be created is read. The row shows the value that failed to resolve and the field it arrived in, the reference of the source CRM record, and the arrival timestamp. A row clears when the corrected record is sent again. A row that will not be recovered is dismissed there with a recorded reason, which is a write on a record that is not a request. That view is documented in Events approved upstream in your CRM, in the same article.

Editing the organization-level settings behind those modules is separate from both paths and narrower than either. The Policies area of Onomi 360 is edited by organization administrators alone.

It holds the settings every event runs on, and each is documented where its module is:

Everyone who reaches a module through scope or through workspace membership works within those settings and sees them read-only. One administrator-only setting sits outside Policies: the request form and its categories, configured on the Request form tab of Event requests as described above. Organization administrators alone edit it, exactly as they alone edit the settings in Policies. On Reports there is no such setting, so every assignment that opens a report reads it under its own scope, and a Program lead reads the numbers with nothing to redefine.

One setting shown in Policies is not edited there by anyone. The AI model configuration means the provider and models your organization's AI assistance runs on. It is agreed with your SpotMe team and shown in Policies, so your administrators can see what is in force. It is not an administrator-editable setting, and it is documented in How to use AI assistance in Onomi 360.

Worked example: a planner holds the Approver role scoped to Germany and the oncology business unit, and is on the team of one German workshop's workspace as an Editor. The Event requests is the program-layer surface her Approver assignment opens. There she sees the requests for Germany and oncology, plus any request routing sends her, and nothing else. The event records inside that scope and their per-event modules open to her read-only.

In the workshop's workspace she works with her Editor rights, governed by workspace membership alone. Her Approver assignment opens no workspace that already exists, and carries no Start execution. To build a second event she must be added to its team. When she is added to a French event's workspace to help execute it, she can build that event in Backstage. She can also work that event's own record and its per-event modules in Onomi 360, because she is a planner of its workspace. She opens it from the workspace or from a direct link, since the French event does not appear in her program-layer lists or search results.

What her Approver assignment opens does not move. The Event requests still shows the requests for Germany and oncology, plus every request routing sends her. The event records inside that scope and their per-event modules still open read-only. That assignment opens no calendar, no Contacts, no dashboards, and no reports, so reading the program layer would need a Program lead assignment of its own. Sourcing that French venue is a further step: it needs the Sourcing grant, and her Approver assignment does not carry it.

To verify a scope, assign one and have the user open All requests in Event requests in Onomi 360. The view contains only requests inside the scope, while an organization-wide colleague sees the full list.

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.