The role model and role registry

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

Use 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 hold both a core platform role and an Onomi 360 role because the two layers govern different surfaces.

The Onomi 360 role registry

The registry below covers the requester and the strategic meetings management roles used across this documentation. These roles carry an explicit scope built from geography, business unit, and, where your organization uses them, therapeutic area or brand.

The table is the role set the platform ships with. A role is assigned and scoped rather than authored. Your administrators work the assignments on the Users tab of Users and roles. The Roles tab beside it lists the definitions themselves. During implementation, your SpotMe team reviews which of these roles your organization uses. It also reviews how their grants map onto the way you divide approval, finance, and sourcing work.

The last column states what each assignment may write on an event inside its scope, and the sections under the table qualify that answer role by role. What neither of them names, the assignment does not write. Reaching a record and changing it are separate grants here. An assignment that opens an event record with no write named below opens it read-only.

Some writes are made by the platform rather than typed by a person. Where an action inside one module writes automatically to another, that write is named where the action itself is documented. Awarding a sourcing bid writes the awarded amount to the event budget, for example. The write is attributed to the action rather than to the person who took it. It stays subject to the rules of the module it lands in, including that module's lock policies. The registry names each such write beside the grant that triggers it, so a seam of this kind never widens a grant silently.

The approver

Only holders of the role can be named in an approval level, and someone without the grant 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 whose scope 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 rather than being typed by the approver. When a request submitted through the meeting request portal reaches Approved, Onomi 360 creates the event record automatically and links it to the request. Where 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 grant is not listed for selection. Items in My compliance reviews come from the gate's default reviewer list and routing entries. The gate fires 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 the gate routes 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 it reaches a compliance reviewer only once submitted. Where the gate's trigger conditions name the speaker-program category, the compliance approval appears in My compliance reviews like any other compliance approval.

The grant carries no venue decision of its own. A venue rule's result follows from the rules your organization configured for the market, and it is recorded on the venue entry rather than 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. 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 From approval to execution and auditing requests). The control is held by a holder of this role whose scope covers the event. Where the category is mapped to Create at approval the workspace already exists, and the planners of that workspace (workspace Manager or Editor) hold the control as well. That is the two-path rule the per-event modules follow.

Whoever selects Start execution becomes the first Manager of the workspace it creates. That 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. What the action grants is the Manager role on the workspace it creates, with the workspace surfaces on that event that come with it. Where 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 reaches that workspace's planners only once planners have been added that way, and a holder of the finance role whose scope covers the event is the actor until then.

The per-event writes of the Budget, the Travel, and the Transfer of value modules belong to this assignment as well, on the two-path rule the table below sets out. So do the Start date and the End date on the event record. The reconciliation reminder, the calendar's Planned and Completed classification, the travel step's pre-filled dates, and the retention clock all read those two dates (see From approval to execution and auditing requests).

Recording or replacing the event's booked venue sits in the event record's Venue section. That section lists the record's venue entries with the booked one marked, and it sits on the record itself rather than inside 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). The write is held alongside the planners of the event's workspace where the event has one, and alone on a record-only event that has no workspace. A venue recorded that way carries the market's venue rules exactly as any venue entry does.

Reconciliation, Close event, and Cancel event are this assignment's too. Cancel event sits on the same grant 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 whose scope covers the event, 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, this assignment holds alone the writes it would otherwise share with the event's workspace planners. No planner exists on that lane to work them. Those writes are recording or replacing the venue, the Start date and the End date on the event record, and the per-event writes of the three modules below.

That lane also carries one write of its own. On a record-only event this assignment adds an attendee to the event record's attendee list and sets the Show and No-show state, which no workspace membership exists to carry. That write is not one of the shared writes above. It exists on the event record only where 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 grant still carries its own writes on such an event, as its row states. A Sourcing grant holder works the Sourcing module there, with the venue entries a shortlist and an award write on the record, and the awarded amount the award writes into 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 grant

A Sourcing grant holder does not edit the budget by hand. Awarding a bid writes 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, and it is subject to the budget's lock policies (see How to use the Budget module).

A second sourcing action writes 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, stay elsewhere. They belong to the planners of the event's workspace and to holders of the finance role whose scope covers the event (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 writes the chosen venue, the agreed rates, and the awarded costs onto that entry. Both are platform writes attributed to the shortlist or to the award (see How to source a venue from your event). Recording or replacing a venue by hand stays with the planners of the event's workspace and holders of the finance role whose scope covers the event, as the rows above state.

Those three seams are the whole of what this grant reaches 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 is writable from it.

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.

Changing the approved band carries one qualification. A budget header can hold no band and no budget currency. It arrives that way from your CRM, or it is created from a request whose category 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 writes the event's finance owner holds alone. Seven controls belong to the finance owner named on the event record rather than to every holder of the role whose scope covers it. 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 that hold the budget's per-event writes. Those are the planners of the event's workspace and the holders of the finance role whose scope covers the event, 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.

Two things the rows above rely on are worth stating plainly.

The first is how venue entries sit 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 carries 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 carried from an approved request. Until one of those happens, no entry is booked. An event whose sourcing is still running therefore carries 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. Where a row writes "the event record's venue entry" in the singular for that write, 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 whose scope covers the event. 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 Sourcing grant holder 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 where no sourcing request was raised for the event. The two lanes it describes differ. Take an event approved upstream in your CRM for which no sourcing request has been raised. 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. Where 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 carries 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). That is why the Requester row above carries nothing on the event record.

A planner is a persona rather than a grant: 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.