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.

Those sections rely on the role reference in Onomi 360 roles, permissions, and scope, which states what each role can change.

Agencies and external stakeholders

Give 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 assign their working role per workspace. Do not give agency staff a Member organization role. Organization members have 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: If an agency also has a strategic meetings management role, the same care applies to the scope on it. A Sourcing assignment sees 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 contains the identity, consent, and attendance states behind every allocation.

An agency's Sourcing assignment is therefore scoped to the events it actually sources for, not 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.

You can use four kinds of conditions:

• 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.

You can also import targeting configurations 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 roles are assigned in Onomi 360 under Users and roles. Their permissions and per-event controls are defined in Onomi 360 roles, permissions, and scope.

This guide focuses on how those roles interact with organizational scope, workspace membership, agencies, and audience targeting. Keep these distinctions in mind:

• A requester needs no role assignment and sees their own requests in the meeting request portal.
• Approver and Compliance reviewer assignments open their respective review queues.
• The finance role owns execution, reconciliation, and closure for events in scope.
• The Sourcing role works the sourcing module for events in scope.
• A Program lead reads the portfolio calendar, Contacts, dashboards, and reports in scope.

Workspace roles continue to govern event execution. A strategic meetings management assignment does not open an existing workspace.

Scoped visibility: what each role sees

Every strategic meetings management role assignment has 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.

The assignment a person holds decides which of those surfaces opens at all. The scope on that assignment bounds what each open surface shows.

The list below states both, role by role. Scope complements routing. It does not repeat it.

Who approves a request is computed from the request itself, as described above. Who sees it follows the scope.

Define the scope dimensions

You set a scope per assignment from these dimensions:

• Geography: the countries in the assignment's scope. Requests and events located in them are visible to the assignment. Geography is the scope model's name for the geography a record already has. No second value is 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.

  You scope an assignment, or a routing entry, by selecting countries from the platform's country list. Those values are the whole of the scope.

  Neither a market name nor a region name is itself a selectable scope value.

  You therefore cover a market or a region by naming the countries in it, within the limit of 25 values per dimension on one assignment.

  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. It is not a scope dimension of its own.

  You maintain the Markets list itself 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 in the assignment's scope.
• Therapeutic area and Brand: optional dimensions for organizations that run their program along them. You can leave them unset to scope by geography and business unit alone.

Maintain dimension values

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.

You maintain the Business unit, Therapeutic area, and Brand lists in Onomi 360 > Policies > Dimensions.

Administrators alone edit them, exactly as they alone edit every other Policies setting.

A value has a name, an optional code for your own systems to match on, and an active or retired state.

You add values on the same tab: select Add a value and complete 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 you pick from when you 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 keep a reference to the value. Neither keeps a copy of its name.

Retiring a value works the other way round. Records that already have it keep it, and remain 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.

Use dimensions in routing and inbound records

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

If 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 with a scope that matches the request is the one that receives it.

A request matching no entry goes to the default compliance reviewers.

Entries are reorderable, so a reviewer's personal queue membership is never ambiguous, and you can change which entry wins by reordering them.

The limit belongs to the scope, not to what uses it: the 25 values per dimension that bound a role assignment bound a routing entry and an auto-clearance rule in the same way.

If a scope has to cover more countries than that, you need more than one of them.

One option is a second role assignment for the same person, who then sees the union of their scopes.

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 remains 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 has.

Requests bring these dimensions from the request form: Country and city, Business unit, and, if your organization uses them, Therapeutic area and Brand.

See Configuring the request form and its categories.

A dimension no request supplies 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 gets the same dimensions a different way. It never passed through the request form.

Its geography, business unit, and, if 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 Connecting CRM, HCP identity, and consent.

Scoped visibility uses those values exactly as it uses the ones a portal request supplies.

The consequence is the same on both paths. A dimension the mapping does not supply 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 remains 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 includes 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 affects scopes and records in two different ways.

• A rename shows everywhere: 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 their saved values.

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, so a stale one shows up there.

Assign and maintain a scoped role

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. You can read the definitions behind that tab, not edit them: a role is assigned and scoped, not authored. The role set your organization goes live on is reviewed with your SpotMe team during implementation (see Onomi 360 roles, permissions, and scope).
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, if your organization uses them, the Therapeutic area or Brand. You can set up to 25 values per dimension on one assignment. 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 one assignment takes per dimension, add a further assignment. A user with several assignments sees the union of their scopes.

   

Assignments change as people move, and you can change or end one in the same list. 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 remains recorded. Approvals the person granted remain in the audit trail with their name, the date, and their comments, because the trail records what happened, not 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 move it to the next level.

Both paths 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 checks both layers, in the order set out in Assigning roles, enterprise sign-in, and provisioning.

Compare the role surfaces

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 reference 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, if your organization uses them, its therapeutic area or brand. A reviewer with one market in scope sees that market's work in their personal queue, not 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 sends to a reviewer appears in that reviewer's personal queue, and is workable by them whatever its scope.

  The gate sends 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.

  If 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.

  If AI assistance is enabled for your organization, the natural-language question panel rides the reporting surfaces. It is not a surface of its own.

  This assignment therefore has 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 in its scope, the reviewer's assignment shows 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 reviewer sees it 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 reference states. The Sourcing module can be edited under the role, 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, if the holder is a member of one.

• Program lead: the geography, business unit, and, if 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. If AI assistance is enabled for your organization, the natural-language question panel rides the calendar and reports. It is not 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, not the surface set. Its holder sees everything the role opens, across the whole organization.

The assignment still does not open 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 sees the calendar, Contacts, the dashboards in Insights, and reports without opening an approval, a compliance decision, or edit access in a module.

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.

If an agency of record runs your sourcing, this is its role assignment: the Sourcing role with the scope you set.

Beside it are 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.

The assignment a person holds decides which of those surfaces opens at all. The scope on that assignment bounds what each open surface shows.

The per-role list is in Scoped visibility: what each role sees above.

Workspace membership and per-event modules

The workspace surfaces follow workspace membership. Who can open, edit, or view an event's workspace in Backstage follows the workspace roles documented in Onomi 360 roles, permissions, and scope.

A scope opens no workspace that already exists.

One route does lead from a scope to workspace membership, and it is an action. No access rule opens that route.

On an event with a request category 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 with the event in their scope can select 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 comes with the workspace surfaces on that event, including attendee identity resolution, captured consent responses, synchronized consent information, and the attendance state governed by the Users module.

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 on an event record in Onomi 360 (Request, Budget, Sourcing, Travel, and Transfer of value) open on two paths.

• They open to users with that event inside their strategic meetings management role scope. What each of those roles can change once the record is open is stated per role in the last column of the role reference in Onomi 360 roles, permissions, and scope.
• 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 is the same on both paths: neither widens the program-layer views, which remain bounded by strategic meetings management scope.

A planner of the event's workspace can open that event's record and its per-event modules even if 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. If the rules on a record's classification level withhold it from a user, that record does not open.

Whether they reached it through their strategic meetings management scope or as a planner of the event's workspace makes no difference.

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, not 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." A reader with a scope that already covers the event is therefore not sent to ask for a scope they already hold.

The two paths differ in what they let a person change.

Editing attendee and consent information

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 role reference's last column states for that role. It never opens workspace-side attendee editing.

Changing an attendee's identity resolution, their captured consent response, 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. The customer's connected consent-management platform, master data management system, or CRM remains the consent master.

A person with access from a strategic meetings management role alone sees 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 works differently.

The attendee, the attendance state, and the consent reference are on the event record in Onomi 360.

No workspace exists, so no planner membership does either. They open to a holder of the finance role with the event in their scope.

The table in Onomi 360 roles, permissions, and scope lists the change under that role.

On an event with no workspace, a finance-role assignment with the event in its scope has the edit on the event record's attendee list. That edit is adding an attendee and setting the Show and No-show state.

No other strategic meetings management role can make that edit.

The self-service small-meeting categories are record-only by default, so this is the lane most of your meetings run in.

Assign the finance role with a scope that includes those events, so the record is not left 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.

Control internal and external workspace access

Because a planner of an event's workspace has that event's per-event edit access, 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 with no team yet, the organization Admin role alone is enough for that first assignment.

The condition on both layers applies to members adding themselves or others after that.

If 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 role reference in Onomi 360 roles, permissions, and scope therefore governs them on that path, whatever scope their own strategic meetings management role assignment has, and whether or not they hold one at all.

Every per-event Budget change, every per-event Travel change, and the transfer of value preparation that row names are open to them on that event.

If the per-event edit boundary must apply to internal colleagues as well as external ones, set it at the organization layer.

Do not expect the modules to enforce it.

Give internal staff who should not edit 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 who execute 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. What closes it is a setting.

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 with the event in their scope can select that action.

A strategic meetings management scope alone can therefore produce workspace membership on those events.

If 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 have which mapping is therefore an access decision as much as an execution one, so review it with the rest of your access model.

Account for JIT workspace placement

One further route is not an administrator action either. It is driven by an identity-provider attribute, and no setting of yours controls it.

If 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 in the workspace's Users module. It is not membership of the workspace team.

It sets no organization role, no workspace role, and no strategic meetings management assignment, so it brings none of the per-event edit access 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 can reach, so review it alongside Users and roles and the organization Members list.

What that placement includes, 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.

Apply the additional sourcing condition

One of those modules has a further condition. Acting in the Sourcing module needs the Sourcing role on top of either path.

Acting means running a venue search, issuing an RFP, comparing bids, awarding, and holding the contract.

Without the role, the sourcing status and the awarded venue remain 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.

Use administrator access for recovery

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 on its own gives no approval right and no edit access in any module.

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 have.

An administrator therefore does not approve, decline, clear a compliance gate, or edit 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.

The same bound applies on Reports as 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 edit access in any module 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 shows the portal address, and the request categories and their fields are configured there. 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 lists the event records your CRM sent that could not be created. 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 leaves the list when the corrected record is sent again. A row that will not be recovered is dismissed there with a recorded reason, which is a change 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 contains the settings every event runs on, and each is documented with its module:

Everyone who reaches a module through scope or through workspace membership works within those settings and sees them read-only.

One administrator-only setting is 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 opens a report under its own scope, and a Program lead sees 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 you 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 it does not include 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 role, and her Approver assignment does not include 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.