Onomi 360 uses scoped strategic meetings management roles. Those roles decide which event requests and records a person can reach, and what they can do there.
This guide focuses on those roles. Organization, workspace, and content hub roles continue to govern the core Onomi platform and are documented separately.
Core Onomi roles
You can keep using the existing core knowledge-base articles for platform access:
- Backstage user roles
- Adding or removing workspace team members and editing their roles
- Adding or removing content hub team members and editing their roles
Those roles determine access to Backstage, workspaces, content hubs, and their execution tools. They do not replace an Onomi 360 role assignment.
A person may have both a core platform role and an Onomi 360 role because the two layers govern different surfaces.
Built-in Onomi 360 roles
The table below lists the requester and the strategic meetings management roles used across this documentation.
Each of these roles has an explicit scope you set from geography, business unit, and, if your organization uses them, therapeutic area or brand.
The table is the role set the platform ships with. A role is assigned and scoped, not authored.
You add, change, and remove assignments on the Users tab of Users and roles, and you can read the role definitions themselves on the Roles tab beside it.
During implementation, your SpotMe team reviews which of these roles your organization uses, and how their permissions map onto the way you divide approval, finance, and sourcing work.
The last column states what each assignment can change on an event inside its scope, and the sections under the table qualify that answer role by role.
If you need the full answer for one role, read its row together with its section. What neither of them names, the assignment cannot change.
Reaching a record and changing it are separate permissions. An assignment that opens an event record with no edit permission named below opens it read-only.
Not every write is typed by a person: the platform makes some itself.
When an action in one module also changes another, that write is named where the action itself is documented. Awarding a sourcing bid, for example, adds the awarded amount to the event budget.
The write is attributed to the action, not to the person who took it. It remains subject to the rules of the module it lands in.
The table names each such write beside the permission that allows the action, so a connection between modules never expands a role silently.
| Role or user type | Where it is assigned | How access is determined | What it can access | What it can change on an event in scope |
|---|---|---|---|---|
| Requester | No role assignment needed. Anyone in your organization can submit through the meeting request portal, a separate surface reached at its own address with single sign-on. | Not applicable | Their own requests, always. No role assignment is involved: an assignment is what the program-layer sections of Onomi 360 need, not the portal. A requester can always see the requests they submitted in the meeting request portal. Classification handling rules narrow the two platform access paths. They do not narrow a requester's view of their own submissions. | Their own request: its form before submission, and again after a decline until it is resubmitted, and withdrawing the request before approval completes. Nothing on the event record. |
| Approver | Onomi 360, Users and roles, with a scope | Role assigned; the approver for a given request is computed by routing | The role assignment provides the permission, and its scope bounds the queue: requests in scope, plus every request routing sends them. | Their own approval decision on the requests routed to them, with its reason and comments. The event record itself opens read-only. |
| Compliance reviewer | Onomi 360, Users and roles, with a scope | Assigned; works from a personal queue | The role assignment provides the permission, and its scope bounds the queue. The role includes no venue decision. | Their own compliance decision. The rest of the event record opens read-only. |
| Finance role | Onomi 360, Users and roles, with a scope; an owner is assigned per event for reconciliation | Assigned | Starting execution on an approved event, reconciliation, closure, and cancelling the event. | Start execution, the Start date and the End date, the event's booked venue, reconciliation, Close event, and Cancel event on the event record. Every per-event change in the Budget, the Travel, and the Transfer of value modules, and, on a record-only event, the event record's attendee list. |
| Sourcing | Onomi 360, Users and roles, with a scope | Assigned | Edit access to the Sourcing module on the events in scope: running a venue search, issuing an RFP, comparing bids, awarding, and holding the contract. That work is documented in How to source a venue from your event. The sourcing status and the awarded venue remain readable on an event record without this role. | The Sourcing module. Three of its actions each make a platform write outside it, and nothing else on the event can be changed under this role. |
| Program lead | Onomi 360, Users and roles, with a scope | Assigned | The program layer for their scope: the portfolio calendar, Contacts, the dashboards in Insights, and reports. | Nothing on an event record: an event record inside the scope opens read-only, as does the program layer. Saving, duplicating, scheduling, and deleting the reader's own custom reports there is documented in How to use Onomi 360: the portfolio calendar, engagement view, and reports. |
The approver
Only holders of the role can be named in an approval level, and someone without the role is not listed for selection.
Which approver a given request goes to is computed by the approval rules configured in Configuring approval routing, the compliance gate, and auto-approval.
An approval level that names a role places one shared approval in the personal My approvals queue of every holder with a scope that covers the request.
Any one of them may act, and the trail records who acted and when.
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.
One platform write follows the final approval. The approver does not type it.
When a request submitted through the meeting request portal reaches Approved, Onomi 360 creates the event record automatically and links it to the request.
If the request's category is mapped to Create at approval, the event workspace is created from the template that mapping names (see From approval to execution and auditing requests).
Neither write opens anything further to this assignment: the event record it creates still opens read-only, and the workspace it creates opens with no team.
The compliance reviewer
Only holders of the role can be named in the compliance gate's default reviewer list or in a gate routing entry, and someone without the role is not listed for selection.
Items in My compliance reviews come from the gate's default reviewer list and routing entries. The gate runs on the trigger conditions your organization configures (shipped default: healthcare professional or public-official attendees present).
All of it is configured in the Configuring the compliance gate section of Configuring approval routing, the compliance gate, and auto-approval.
A request routed to a reviewer, through a routing entry or the default reviewer list, is visible and workable by that reviewer whatever its scope.
The reviewer's own scope bounds every other event record and venue control they can read. A Draft request is visible only to its requester and editable by them alone, so a compliance reviewer sees it only once submitted.
If the gate's trigger conditions name the speaker-program category, the compliance approval appears in My compliance reviews like any other compliance approval.
The role includes no venue decision. A venue rule's result follows from the rules your organization configured for the market, and it is recorded on the venue entry, not decided by a reviewer.
A refused venue is refused outright (see Setting venue rules in Onomi 360). A classification handling rule never withholds a request from the reviewers the gate routed it to.
That is the same footing as the organization administrator's administrative visibility and a requester's view of their own submissions.
The finance role
Start execution on the event record moves the request to In execution.
If the request's category is mapped to Create at Start execution, it also creates the event workspace from the template that mapping names (see From approval to execution and auditing requests).
The control belongs to a holder of this role with the event in their scope.
If the category is mapped to Create at approval the workspace already exists, and the planners of that workspace (workspace Manager or Editor) have the control as well.
Together those two paths are the rule the per-event modules follow.
Whoever selects Start execution becomes the first Manager of the workspace it creates.
Becoming first Manager is what lets the rest of the team be added, since only workspace managers manage a workspace's team.
It is also the single route from a strategic meetings management scope to workspace membership, and it has two halves.
The scope opens no workspace that already exists. The action assigns the Manager role on the workspace it creates, with the workspace surfaces on that event that come with it.
If a category's workspaces have to be staffed centrally instead, map that category to Create at approval, as set out under How scope and workspace membership meet in Agency access and strategic meetings management scope.
A workspace created at approval opens with no team for the same reason in reverse, 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 opens to that workspace's planners only once planners have been added that way, and a holder of the finance role with the event in their scope is the actor until then.
Every per-event change in the Budget, the Travel, and the Transfer of value modules belongs to this assignment as well, on the two-path rule the table below sets out.
The Start date and the End date on the event record belong to it too.
The reconciliation reminder, the calendar's Planned and Completed classification, the travel step's pre-filled dates, and the retention clock all use those two dates (see From approval to execution and auditing requests).
Recording or replacing the event's booked venue is done in the event record's Venue section.
That section lists the record's venue entries with the booked one marked, and it is part of the record itself, not of the Sourcing module.
The venue is entered as free text or picked from the market's approved venue list (see Searching for venues and choosing how to book).
If the event has a workspace, this role shares the change with its planners. On a record-only event with no workspace, this role makes it alone.
A venue recorded that way is subject to the market's venue rules exactly as any venue entry is.
Reconciliation, Close event, and Cancel event are this assignment's too. Cancel event is covered by the same permission as Close event.
Cancelling an approved or in-execution event is therefore available to the event's finance owner and to the other holders of this role with the event in their scope, and to no other assignment.
The cancellation step is documented in How to set up and use meeting requests and approvals, and closure in How to use the Budget module.
On an event with no workspace, meaning a request category mapped to record-only, only this assignment can make the changes it would otherwise share with the event's workspace planners. No planner exists on such an event to make them.
Those changes are recording or replacing the venue, the Start date and the End date on the event record, and every per-event change in the three modules below.
One change belongs to record-only events alone.
On such an event this assignment adds an attendee to the event record's attendee list and sets the Show and No-show state, because there is no workspace to do that work in.
That change is not one of the shared set above. It exists on the event record only when there is no workspace.
Attendee and attendance editing on an event backed by a workspace is work in that workspace's Users module, which no strategic meetings management assignment opens. See How scope and workspace membership meet in Agency access and strategic meetings management scope.
The Sourcing role keeps its own edit access on such an event, as its row states.
A holder of the Sourcing role works the Sourcing module there, with the venue entries a shortlist and an award write on the record, and the awarded amount the award adds to the Committed column.
This assignment also opens the cost-facing reports.
Saving, duplicating, scheduling, and deleting the holder's own custom reports there, a reinvoicing summary among them, is documented in How to use Onomi 360: the portfolio calendar, engagement view, and reports.
The Sourcing role
A holder of the Sourcing role does not edit the budget by hand.
Awarding a bid adds the awarded amount to the Committed column under the category your organization's hierarchy marks with Sourcing award target, Venue for a venue award and Accommodation for a rooms-only room-block award.
That is a platform write attributed to the award (see How to use the Budget module).
A second sourcing action makes a platform write on another module in the same way.
From the awarded pricing, selecting Create room block creates the block at the bid's rates, spanning one or more hotels, in the event's Room blocks tab in Onomi 360, beside the award it came from.
That too is a platform write attributed to the award.
Adding a room block by hand, and the ongoing work of that tab, belong elsewhere: to the planners of the event's workspace and to holders of the finance role with the event in their scope (see How to manage travel and accommodation for your event).
A third seam lands on the event record itself.
Shortlisting a venue creates that venue's entry on the event record, and confirming an award records the chosen venue, the agreed rates, and the awarded costs on that entry.
Each is a platform write attributed to the shortlist or to the award (see How to source a venue from your event).
Recording or replacing a venue by hand remains with the planners of the event's workspace and holders of the finance role with the event in their scope, as the rows above state.
Those three connections are the only changes this role can make outside the Sourcing module.
They are the award writing the Committed column, Create room block writing a room block, and the shortlist and the award writing venue entries on the event record.
Nothing else on the budget, nothing else on the travel records, and nothing else on the record can be changed from it.
The per-event changes in the Budget, Travel, and Transfer of value modules
Three of those modules are read across several articles. The answer the column gives for them is stated here in one place.
It uses the wording of How to use the Budget module, How to manage travel and accommodation for your event, and How to manage transfer of value on your events.
| Module | The per-event changes | Who holds them | Who opens the module read-only | On a record-only event with no workspace |
|---|---|---|---|---|
| The Budget module | Add cost line, editing a line, Remove cost line, and Add sub category for an event-specific sub category. On the budget header: setting the Cost centre and Intercompany code fields, changing the approved band by selecting another band, and setting the Finance owner field. | Holders of the finance role with the event in their scope, and the planners of the event's workspace (workspace Manager or Editor). | An Approver, Compliance reviewer, Sourcing, or Program lead assignment with the event in its scope. | Only the finance role can make them. |
| The Travel module | Every per-event Travel module change. | The planners of the event's workspace (workspace Manager or Editor), and holders of the finance role with the event in their scope. | An Approver, Compliance reviewer, Sourcing, or Program lead assignment with the event in its scope. It opens the event's travel records read-only. | Only the finance role can make them. The working tab here is Room blocks, which shows a block created from a sourcing award on a record-only meeting. Travelers and Manifests have nothing to list, and Routing has no requests to route. The travel step and the registration journey are workspace-side (see How to manage travel and accommodation for your event). |
| The Transfer of value module | Preparing the allocation in the Transfer of value module: setting a line's Recipient, changing a line's Transfer of value category or Attribution, and Run allocation itself. | The planners of the event's workspace, and holders of the finance role with the event in their scope. | Confirm allocation, Exclude line, Reopen, and Correct allocation remain with the event's finance owner alone. Other holders read the Review and Handoff tabs with those controls disabled and the required owner named. | Only a holder of the finance role can make them. That role also includes Add attendee and the Show and No-show state there. |
Changing the approved band has one qualification.
A budget header can have no band and no budget currency: it arrives that way from your CRM, or it is created from a request with a category that omitted Budget band or left it optional and unanswered.
On such a header the first selection is offered in every currency your organization has defined, and every later change is constrained to the band set of the event's budget currency.
Working the budget during planning in How to use the Budget module sets that out.
The controls the event's finance owner holds alone
Seven controls belong to the finance owner named on the event record, not to every holder of the role with the event in its scope.
Four of them are in the Transfer of value module: Confirm allocation, Exclude line, Reopen, and Correct allocation (see How to manage transfer of value on your events).
The fifth is Route for reimbursement on a cost line marked as a reimbursement claim (see How to manage payments, honoraria, and reimbursement on your events).
The sixth is dismissing a row in the Unmatched invoices view of the event's Budget module with a reason, which keeps the row, its reason, and who dismissed it on the event record.
The seventh is recording a reason on a Meal cap exceeded flag to clear it, with the flag, the reason, and who cleared it staying on the record. The last two are documented in How to use the Budget module.
The Unmatched invoices view itself opens to both groups with the budget's per-event edit access. Those are the planners of the event's workspace and the holders of the finance role with the event in their scope, as Integration patterns: connecting Onomi to your enterprise systems states.
Only the dismissal is the finance owner's alone, and other holders read those surfaces with the controls disabled and the required owner named.
Venue entries and refused venues
Two things the rows above rely on are worth stating plainly.
The first is how venue entries appear on an event record. The record's Venue section lists one venue entry per venue that has reached the event. An entry is created at one of four points:
- when the venue is shortlisted on a sourcing request.
- when a confirmed instant booking places the venue on the record.
- when a venue is recorded directly on the record.
- when the venue captured on an approved request is copied onto it.
At most one of those entries is marked as the event's booked venue.
An entry is booked by an award, a confirmed instant booking, a venue recorded directly on the record, or the venue copied from an approved request. Until one of those happens, no entry is booked.
An event with sourcing still running therefore lists entries with none of them booked (see How to source a venue from your event). Recording or replacing the booked venue acts on the booked entry.
If a row says "the event record's venue entry" in the singular for that change, it means that entry.
The second is what a refusal leaves to do. Require listed venues refuses an off-list venue at three points:
- when the venue is shortlisted on a sourcing request.
- when an award returns to the event record.
- when a venue is recorded directly on the event record with Add venue, in a market with the toggle switched on.
Nothing releases a refused venue. Two things can follow.
One is a listed venue. The planners of the event's workspace (Manager or Editor) record it, or holders of the finance role with the event in their scope.
On a record-only event that has no workspace, the finance role records it alone. The other is an organization administrator adding the venue to the market's approved venue list.
A holder of the Sourcing role who meets any of those refusals, and who is not one of those holders, asks one of them to record the replacement. An agency of record is one example.
The third point matters most when the event never had a sourcing request. The two situations it describes differ.
Take an event approved upstream in your CRM with no sourcing request behind it.
Add venue is the only path a venue has to that record. It is therefore the only point at which the rule can refuse one.
If that event is sourced, the other two block points apply exactly as they do on any other event record (see Searching for venues and choosing how to book).
On a record-only event created from a portal request, the venue the request named is copied onto the record at approval.
The rule therefore refuses earlier, at the request's Venue field in the portal (see Configuring the request form and its categories). The earlier refusal is why the Requester row above lists nothing on the event record.
A planner is a persona, not a role: planners hold workspace roles, typically Editor or Manager, in the events they execute.
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.
Comments
0 comments
Please sign in to leave a comment.