How to plan your Onomi 360 implementation

Most of Onomi 360 is configuration your administrators own: thresholds, categories, policies, and lists that are edits, never development requests. A smaller set of steps comes first. Those are capabilities enabled for your organization, connections built to your enterprise systems, and the foundation lists and settings the later steps read. This article lists the steps in dependency order. It says what kind of step each one is, tells you what to prepare, and gives the pace each step usually sets. Your rollout plan then starts from the real sequence rather than discovering it. For what each capability does, see its own article, linked per step.

How to read the checklist

Every step is one of three kinds:

• Organization enablement: a setting activated for your organization by your SpotMe Account Manager. No project; once enabled, the configuration is yours.
• Implementation project: a connection or configuration built together with our implementation team, typically because it touches one of your enterprise systems.
• Customer-side setup: work your own team does in your systems or in Onomi 360, with documentation rather than a project.

Steps depend on earlier steps, and the order below is the dependency order. Eleven of those dependencies are structural, and a plan that reorders them stalls:

• Your organization's region is decided before your organization is created, so it sits ahead of the numbered steps rather than inside them. It cannot be changed afterwards.
• Sign-in comes before every other numbered step, because it is how requesters reach the meeting request portal.
• Onomi 360 and the request suite come before every other Onomi 360 step, because the request is what the budget, the sourcing, the travel needs, and the allocation all hang on.
• The dimension lists come before four things: the request form's field values, the scopes on role assignments, the compliance gate's routing entries and auto-clearance rules, and the report groupings. Each of those names a value from a list rather than holding one of its own. Geography is the exception, being countries from the platform's own list.
• The Markets list comes before the venue rules and meal caps, before the travel policy, and before the market-to-team mapping, because those read it. Each market names the team that books for it, so the mapping is built from the markets defined here (step 11). The compliance gate's routing entries do not read it: they are scoped on the geography values a request carries and are configured at step 2.
• Each market's currency is decided when the market is built. The field's documented default is your organization's reporting currency. That currency is configured with the budget suite in phase 2, and does not exist yet at phase 1.
• Roles and their scopes come before the approval rules and the compliance gate, because only a role holder can be named in a rule.
• The per-currency budget band sets come before three things: the request form's Budget band field, any approval rule carrying a band condition, and auto-approval. Each of those reads a band set, and the auto-approval comparison runs on a band's To value. The rest of the budget suite follows the request form and the approval rules. The band sets are configured in the budget suite at step 7, so they are entered before step 2's field set and rules are finished.
• The budget suite comes before transfer of value, because allocation reads reconciled budget actuals.
• The budget suite also comes before any event can be closed. The closure that brings an event to Closed is recorded with Close event on the budget header, so that status is reachable only where the budget suite is enabled for your organization. The Finance owner field the Reconciliation reminder addresses sits on the same header. Every retention period computed from the recorded closure has nothing to start from without it. The suite is therefore a prerequisite for ending the lifecycle rather than an optional later phase.
• The transfer of value setup comes before the disclosure handoff, which consumes confirmed allocations, and before a speaker roster, which resolves to the same HCP identities.

The capabilities behind these steps arrived at different times, so release order is not implementation order. An organization adopting them configures the lifecycle foundation first, then adds the capabilities needed for its operating model.

Each step below notes the pace it usually sets. Those durations assume the decisions listed under Prepare are made before the configuration session. That is where rollout calendars slip in practice. The settings themselves are quick. Agreeing thresholds, categories, and cap amounts across compliance, finance, and the affected countries is not.

You do not have to adopt everything. The lifecycle suite is designed for phased rollout by country, division, or request category. Every step past the foundations is optional, with one exception: the budget suite at step 7. An organization that stops at phase 1 can request, approve, and execute. It cannot close, because the closure that brings an event to Closed is recorded with Close event on the budget header. To plan a rollout for your organization, please contact your SpotMe Account Manager.

Before phase 1: your organization's region

Your organization's data region. Agreed with your SpotMe team before your organization is created. That is why it comes before the numbered steps rather than sitting inside them. The region is chosen from the four residency locations, and, like a workspace's region, it cannot be changed afterwards.

It fixes where the Onomi 360 records for every event in your program reside, whatever region each event's own workspace runs in. Those records are every record class your retention rules are configured on. The classes are requests, approvals and their traces, budgets, and confirmed allocations. They also include transfer-of-value handoffs, consent capture records, event records with their attendee lists, and the audit records that evidence all of them. Contacts, the consolidated HCP engagement view built from them, resides there too.

Prepare: the residency position your legal and data protection teams hold, and the regions your event workspaces will run in. Where those differ from your organization's region, prepare confirmation that the transfer mechanism in your data processing agreement covers the records that reach it.

Check it after creation in Onomi 360 under Policies, beside the organization details. See Data residency.

One foundation needs no step in this checklist, because it is already in place. The registration journeys, identity resolution, consent capture, and attendance states your events run on are the event platform's registration foundation. They predate the strategic meetings management modules this checklist sequences, so they are configured per event on its workspace rather than enabled here (see HCP registration and validation on your events).

Phase 1: foundations

1. Single sign-on and provisioning. Configured with your SpotMe Account Manager and your identity provider (IdP) team. The Onomi side is one working session. Allow a week or more for your IdP change window, which is what usually sets the date. Prepare: the protocol (SAML 2.0, OpenID Connect, or OAuth 2.0), your IdP metadata or client credentials, test credentials, and the workspace matching mode. See Assigning roles, enterprise sign-in, and provisioning.
2. Onomi 360 and the request and approval suite. Organization enablement. Depends on SSO, which is how requesters reach the meeting request portal. Enablement itself is a setting. The configuration takes about one working session per family of request categories. The policy decisions behind it take longer.

   Prepare:

   • your request categories and their field choices;
   • what approval creates per category. That means which categories create an event workspace at approval, which create one when Start execution is selected on the event record, and which are record-only. It also means the workspace template each creating category starts from;
   • the region those workspace templates create in. Settle it with your SpotMe team before you map a category to automatic creation. A workspace's region is fixed when the workspace is created and cannot be changed afterwards. Neither creating path puts a person in the loop to choose it (see Data residency);
   • approval rules with named approvers per level;
   • the compliance gate's trigger conditions, default compliance reviewers, and routing entries by geography, business unit, and, where you use them, therapeutic area or brand;
   • auto-approval and auto-clearance policy decisions made with your compliance organization;
   • notification template recipients;
   • and, for each category you map to record-only, who names the finance owner on the event record as the record is created. The Finance owner field has no default, and that lane has no planners to fall back on (the assignment itself is step 5).

   Category and field ceilings. Your organization holds up to 12 active request categories, each drawing up to 40 fields from the shared library. Size the category set before this step rather than during it. A retired category keeps the requests submitted under it and stops counting against the 12. A speaker-program category counts against the 12 like any other (see step 13). So does a category added with Add category to recover a held arrival.

   Sizing the routing map. Two properties of the rules decide how many you end up writing, so size the routing map before this step rather than during it. A condition takes one or more values from its axis, and matches when the request's value is among them. A condition left unset matches any value. Count distinct routing chains rather than distinct values.

   A rule whose conditions include a budget band is bound to that band's currency. An organization requesting events in several currencies therefore plans one routing chain per currency. All of those chains count against the ceiling of 60 approval rules per organization. That is the number to size before the rules are written.

   The per-currency band sets in step 7 are not sized alongside them. They are configured first. Three things have nothing to read until the band sets exist. They are the Budget band field on this form, any approval rule carrying a band condition, and auto-approval, whose comparison runs on a band's To value. The rest of the budget suite follows the request form and the approval rules.

   Your first configuration step is replacing the default rule's placeholder approver.

   Who staffs the workspace. The workspace mapping also decides who ends up staffing the workspace. On a category mapped to Create at Start execution, whoever selects the action becomes the first Manager of the workspace it creates. That mapping is the one route from a strategic meetings management scope into workspace membership. A category whose workspaces have to be staffed centrally is mapped to Create at approval instead. The workspace it creates opens with no team until an organization Admin adds its first planners.

   See From approval to execution and auditing requests.

   Note: Roles come before rules in practice. Only holders of a strategic meetings management role can be named in an approval level or in the compliance gate. Grant the roles in Users and roles (step 5) before you build the rules that reference them, even though the suite is enabled first.

3. The organizational dimension lists. Customer-side setup in Onomi 360 under Policies > Dimensions. Depends on step 2. Typically one working session, and shorter where the lists already exist in another system and only need entering. The part to settle before the session is which dimensions your organization actually runs its program along.

   Prepare: your business units or divisions, and, where you run your program along them, your therapeutic areas and your brands. Each carries the name it is shown under and an optional code for your own systems to match on.

   An organization administrator enters them, as they enter every other Policies setting. Geography needs no list of its own: its values are countries, taken from the platform's country list, so there is nothing to maintain.

   Enter these lists before the settings that name a value from one. Each of those settings picks from the list rather than holding a value of its own:

   • the field values a request category offers or presets on the request form (step 2);
   • the geography, business unit, and, where you use them, therapeutic area or brand conditions on the compliance gate's routing entries and auto-clearance rules (step 2);
   • the scope on every role assignment (step 5);
   • and the groupings the calendar and the reports offer (step 17).

   As with roles, this list comes before the rules in practice even though the suite is enabled first. See Agency access and strategic meetings management scope.

4. The Markets list. Customer-side setup in Onomi 360 under Policies > Markets. Depends on step 2. Typically one working session, and shorter where your market grouping already exists in another system and only needs entering.

   A market is added on the Markets tab with Add a market, its three fields completed, then saved.

   Prepare: your market names, the countries in each, with each country in one market only, and the currency each market's amounts are set in.

   One market, one set of rules. Anything you set per market applies to every country in that market. A limit that differs country by country needs those countries in markets of their own, inside the 100-market ceiling. The currency matters for the same reason. Per-market caps are compared only in the market's own currency, so a grouping that spans currencies needs splitting into markets of its own.

   Setting the currency. Set each market's Currency explicitly at this step unless you configure the budget suite's currencies first. The field's documented default is your organization's reporting currency. That currency is set with the budget suite in step 7. At this point in the checklist there is nothing for the field to take.

   Get it right here. A meal cap is compared only when the market's currency matches the currency the request or the budget is in. A market left on a currency its requests never carry never applies its meal cap, and reports nothing wrong while it does so.

   The accommodation cap runs on the same rule. It is compared with the nightly rate on a request where that rate is stated in the market's currency. That is the currency a registrant entering it gives it in. The currency you set here is the one the cap is set and read in.

   A rate pre-filled from a claimed room block carries the currency the hotel quoted its bid in. Where that differs from the market's, the amounts are not compared. The check records that the cap did not apply, and no flag is raised. The travel team applies the cap when it books, as it does for a request that carries no rate at all.

   What reads the list. Define this list before the settings that read it. Those are the venue rules and meal caps set per market (step 10), the market-to-team mapping (step 11), and the travel policy's accommodation cap and journey bands (step 12).

   The compliance gate's routing entries are not among them. An entry is scoped on the geography values a request carries, so an entry meant to cover a market names that market's countries. The entries themselves are configured at step 2.

   Maintaining the list. Plan the map as an additive set inside the ceiling. A market is edited in place, and no control removes or retires one. A country is moved between markets with the documented move: remove it from its current market and save before adding it to the new one. A market that is no longer used is left on the list with its countries reassigned.

   Where your organization is approaching the ceiling of 100 markets, or has reached it, contact your SpotMe Account Manager. See Maintaining the Markets list, in Setting venue rules in Onomi 360.

5. Roles and scopes. Customer-side setup in Onomi 360 under Users and roles. Depends on step 2. The assignments are one working session. Deciding which dimensions your scopes use, and who is trusted at which level, is the part to start early.

   Prepare:

   • who holds each strategic meetings management role,
   • the scope per assignment (geography, business unit, and, where you use them, therapeutic area or brand),
   • who holds the Sourcing grant (your planners, or your agency of record),
   • a finance-role assignment whose scope covers the events of every category you map to Create at Start execution. On that mapping the workspace does not exist yet, so it has no planners. The action sits with holders of the finance role whose scope covers the event. An organization that grants planners only finds nobody able to start execution on the three default full-lifecycle categories (scientific, executive, and congress),
   • and a finance-role assignment whose scope covers the events of every category you map to record-only. That mapping creates no workspace and so has no planners, which leaves the finance role holding alone the writes a workspace planner would otherwise share on those events:
     • the cost lines;
     • the Finance owner field, which lists holders of the finance role whose scope covers the event and nobody else;
     • the Start date and the End date;
     • the venue entry;
     • the Travel module's per-event writes, where the tab carrying work on this lane is Room blocks, which holds a block created from a sourcing award on a record-only meeting;
     • and the preparation of the allocation.

   The attendee list and its Show and No-show state come with them, and are not one of those shared writes. That list exists on the event record only where there is no workspace. Attendee and attendance editing on a workspace-backed event is work in that workspace's Users module, which no strategic meetings management assignment opens.

   Close event, Mark reconciled, and Cancel event sit outside that set, because they are never planner writes on any lane. The role registry carries them in the finance-role row alone. On a record-only event the finance role holds them exactly as it does everywhere else, rather than holding them alone by exception.

   The Sourcing grant still carries its own writes on such a record, as its own row in The role model and role registry states (the Sourcing module including the award). An event no finance-role assignment covers can therefore be neither reconciled nor closed, and never starts its retention clock. This is the lane most of your meetings run in, since the self-service small-meeting categories are record-only by default.

   One grant belongs here for a team the checklist otherwise reaches only at step 15. Give the people who file your disclosures a Program lead assignment whose scope covers the events your transparency team files from. The unattributed remainder does not travel with the handoff, and is read on the Review tab of the event's Transfer of value module. Program lead is the one strategic meetings management assignment that opens the event records inside its scope and their per-event modules read-only, and writes nothing on an event record.

   Grant it deliberately, because what a person reads follows the assignment rather than the event being in view. This one also opens the calendar, Contacts, and reports across its scope (see How to manage transfer of value on your events). See The role model and role registry.

   Plan for movers and leavers in the same step. Scoped roles are removed or re-scoped in Onomi 360 under Users and roles, and that is the layer an offboarding checks first. A leaver who keeps an Approver, Compliance reviewer, finance, program-lead, or Sourcing assignment keeps everything its scope shows, whatever you do in Backstage.

   Check that layer, then work down the rest in order:

   • Settings > Team in each workspace and content hub they belonged to;
   • the API tokens the person created;
   • the Analytics API developer role;
   • the organization Members list;
   • and the leaver's identity at your identity provider.

   The identity provider is the layer that closes the meeting request portal. Disabling the identity there ends the federated sign-in path, and a requester holds no organization membership and no strategic meetings management assignment for the earlier layers to remove.

   A personal bearer token is created by its holder on the API tokens tab of their own profile in Backstage. It is retired there before the account is disabled, since no administrator list shows another person's tokens.

   The Analytics API developer role is a layer of its own for the opposite reason. The organization-scope and customer-scope roles (account_api_developer, customer_api_developer) are enabled by SpotMe through your Account Manager rather than by your administrators, so neither appears on any list your administrators work. Removing the person's organization membership retires neither the scope nor the bearer token those endpoints authenticate with. Ask your SpotMe Account Manager to remove both scopes and to retire that token (step 18 names the same grant on the joiner side).

   The portal is reached by single sign-on rather than through an organization account or a role assignment. Treat the provider-side disable as part of this step, rather than as something that has already happened.

   The procedure is in Assigning roles, enterprise sign-in, and provisioning, under Assigning and removing roles. It is also in Agency access and strategic meetings management scope, under Scoped visibility: what each role sees.

6. Portal languages and the organization default language. Customer-side setup in Onomi 360 under Policies > Languages. Depends on step 2. The built-in interface languages need no setup. This step is the languages you add beyond them, and the fallback the portal and notifications use. The settings take minutes.

   Where you add a language beyond the built-in set, your review turnaround is the whole duration of this step, so name the market reviewer early. With AI assistance enabled for your organization, an added language arrives as a complete draft, and the work is review rather than translation from scratch. Without it, the language starts empty, and the export goes out for translation instead.

   Prepare: the languages your requesters work in, the translations for any language beyond the built-in set, and your organization default language. See Running multilingual events across global markets.

Phase 2: the financial spine

7. Budget suite. Organization enablement. Depends on step 2: the budget enters through the request. Ask your finance team for the category hierarchy and its GL codes as soon as phase 1 starts. That list, not the configuration, is what this step waits on. Entering it is one working session.

   Prepare:

   • your budget category hierarchy with GL codes,
   • which of those categories count toward the meal cap (the Counts toward the meal cap setting on each category, no by default),
   • which category receives sourcing awards, through the Sourcing award target setting on each category, None by default. Set it to Venue on the category that receives venue spend, and to Accommodation on the category that receives room-block spend from a rooms-only sourcing request. Use one category per value: a request carrying both the meeting space and the bedroom need is a venue request whose whole award commits to the category set to Venue,
   • band sets per currency, the item phase 1 depends on. The request form's Budget band field, any approval rule carrying a band condition, and auto-approval all read them. Enter them before step 2's field set and rules are finished,
   • the reporting currency and reference-rate table,
   • finance codes for reinvoicing (cost centres and intercompany codes) where you cross-charge,
   • and your threshold and blank-cost policies (see Setting up budgets: categories, bands, and policies, which documents both types).

   Both per-category settings are designated here, with the rest of the hierarchy, by an organization Admin. The sourcing target belongs before your first sourcing request in step 10. An award writes the awarded amount into the Committed column of the category carrying the matching value, so until a category carries it an award has nothing to write to.

   This step is also what ends the lifecycle. It is therefore a prerequisite for closing an event, rather than an optional later phase. The closure that brings an event to Closed is recorded with Close event on the budget header. That status is reachable only where the budget suite is enabled for your organization. The Finance owner field the Reconciliation reminder addresses sits on the same header. Every retention period step 19 computes from the recorded closure has nothing to start from without it.

   See Reconciliation, invoices, and closing the event, which documents both settings.

8. CRM connection. Customer-side setup: the Veeva SpotMe Sync App installs as a managed package in your CRM and is configured by your own CRM team. Your CRM team's own release process sets the pace here, so plan the sandbox round trip and the production window with them rather than around them. Prepare: the matching policy, the field mapping, and the filtering-rule decision of which events synchronize and which lane (upstream approval in Veeva, or the portal lane) masters which events. See Integration patterns: connecting Onomi to your enterprise systems.
9. Transfer of value. Two parts. The category mapping and the registrant-type markings for transfer of value relevance are customer-side setup in Onomi 360 under Policies, agreed once with your transparency team, typically in one working session. Identity resolution against your HCP master is an implementation project, and the longer of the two by some margin.

   Prepare: the mapping decisions, and the list of registrant types your organization uses across its events, with which of them your transparency process discloses. Prepare too the identifiers you resolve against (Veeva ID, OneKey, NPI), and your consent wording.

   The ToV-relevant marking is set per type on the Registrant types table in Onomi 360. Those types are your organization's registrant types, the one list the rest of the platform reads. A registrant type your list is missing is settled with your SpotMe team rather than entered in this step. Please contact your SpotMe Account Manager. See Setting up transfer of value and cost category mapping.

Phase 3: sourcing, travel, and venue compliance

10. Venue sourcing. Organization enablement.

    Prepare: the request details your planners will source with, and who holds the Sourcing grant (planners, or your agency of record), assigned in Onomi 360 under Users and roles with a scope in step 5.

    Plan how the work reaches that holder as well as who holds it. 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.

    Venue rules. Venue rules are customer-side setup in Policies, and they read the Markets list from step 4. They are approved venue lists per market (entered or imported from CSV), meal caps per market, venue-type restrictions, and the Require listed venues and centralized-selection decisions per market. Allow one working session per market for the rules, and expect the cap amounts and the approved lists to come back from each country rather than from one central decision.

    A meal cap also depends on step 7. The reconciliation check sums the reconciled actuals on the cost lines whose budget category is marked Counts toward the meal cap. Until at least one category carries that setting, a cap you enter here has nothing to compare, and the reconciliation check does not run. The request-time check is unaffected, because it reads the estimate stated on the request.

11. The market-to-team mapping. Customer-side setup in Onomi 360, alongside the Markets list. Depends on step 4, because the mapping is built from the markets defined there. Each market names the team that books for it. A request raised in France reaches the France travel team, and one raised in Germany reaches the DACH team. Typically one working session, and the part to start early is agreeing which team or travel management company books for each market.

    Prepare: the team that books for each market, and each team's destination (a connected travel system, or a team email address).

    Plan the mapping as an additive one, for the same reason the market list is one. A market that gains a new booking team is re-pointed in place, and requests already raised keep the team they were routed to. A change of travel management company is therefore made market by market rather than in one cut-over.

12. Travel. The travel step and its reporting are customer-side setup. They read the Markets list from step 4 and the market-to-team mapping from step 11, and take about one working session. The connection to your TMC or travel system is an implementation project per environment. Start it alongside phase 2 if travel is in your first wave.

    Prepare: your travel policy, meaning the cabin and rail class allowed on each journey band, and the accommodation cap per market, set in that market's currency. Prepare too the event identifier your teams will attach to bookings, and the itinerary field mapping.

    Routing is not set per event. Each request resolves to a market from the country on the traveler's registration record, and that market names the team that books for it, under the mapping from step 11. A market with no team mapped has nothing to route its requests to, so check the mapping covers every market you operate in. See Setting up travel and capturing travel needs.

Phase 4: extensions

13. Speaker programs. Customer-side setup in Onomi 360. Depends on step 2 (a speaker program is a request category, so it submits through the request flow) and step 9 (speaker records resolve to HCP identities). The two enforcement decisions with your compliance organization are the long pole, not the setup.

    Prepare: the enforcement settings decisions with your compliance organization. Those are Eligibility enforcement and Repeat-attendance limit behavior, both set in Onomi 360 under Policies > Speaker programs. Prepare too the speaker eligibility criteria your compliance organization works to, the per-healthcare-professional repeat-attendance limit for the year, and the request category speaker programs are raised under.

    Where your organization has no speaker-program request category yet, an administrator creates it first with Add category on the Request form tab (see Configuring the request form and its categories). It counts against the 12 active categories like any other. It takes its field set, its approval rules, and its workspace mapping from step 2 exactly as the other categories do.

    Add that category to the compliance gate's Trigger conditions where these requests are to reach compliance review, rather than relying on the shipped default. That default fires on healthcare-professional or public-official attendees being present, so it matches only where that field is answered.

    The two enforcement settings are read wherever a speaker is chosen. Eligibility is read on the speaker's record. The repeat-attendance limit is read against the engagements that record already carries. An exception recorded against the limit carries a required mitigation, attributed and timestamped. No separate program record, program budget, or program-owner assignment is involved, so nothing here needs a grant beyond the ones step 5 already assigns. See How to run a speaker program.

14. AI assistance. Organization enablement, with the model configuration agreed with your SpotMe team. Additional customer-approved model providers are agreed separately with your SpotMe team as part of that model configuration. Your own model-governance approval usually sets the date, since enablement itself is a setting.

    Prepare: your model-governance approval, which teams adopt first, and where AI model calls are processed. That last one is settled with your SpotMe team as part of the model configuration. The model path sits outside the Onomi 360 application-data region, and an EU-headquartered controller needs that answer for its data protection impact assessment.

    Badge-scan field mapping enables per workspace after organization enablement. See Data residency, and Models and governance in How to use AI assistance in Onomi 360.

15. Disclosure handoff. Implementation project. Depends on step 9, and specifically on identity resolution being live, because the handoff carries resolved identities.

    Prepare: the destination transparency systems and the disclosure basis your transparency process defines. Prepare too the list of events whose allocations were confirmed while no destination was connected, which this step's position in the checklist makes ordinary.

    Connecting a destination does not deliver those allocations, because delivery is triggered by confirmation. Each event's finance owner reopens its allocation and confirms it again to deliver it. Nothing announces which allocations are in that state, so keep the list as you go rather than reconstructing it here.

    The people who file also need the grant step 5 lists for them, a Program lead assignment whose scope covers the events they file from. The unattributed remainder does not travel with the handoff, and is read on the Review tab of the event's Transfer of value module. See Running and correcting an allocation, which documents that sweep.

16. Payments and reimbursement. Organization enablement for the capture surfaces. The connections are implementation projects, one per destination. Those are your expense or finance system for claim routing, the ERP transfer for final costs and invoices, and a payment gateway where you run paid registrations. Scope them one at a time rather than together.

    Prepare: the destination systems and their owners; and, for the ERP transfer, the six things to settle before the first load.

    First, the mechanism your ERP posts settled invoices with, and its owner on your side. The post is outbound from the ERP. That mechanism includes the endpoint it posts to, which is settled with your SpotMe implementation team when the connection is scoped rather than read from a fixed published route of ours.

    Second, the two references the match runs on, in the order it runs them. The event reference resolves the event first, so an invoice lands on the event it was raised for rather than being searched for across the program. The cost-line reference is then matched inside the event it resolved to. Your ERP team owns the round trip of both: the event reference the invoice is posted against, and the cost-line reference it settles. Your Onomi administrator owns the event mapping.

    The cost-line reference is the one whose round trip has two halves, and they are owned differently. The outbound leg gets a cost line's reference to the system that raises the invoice. It is designed with your implementation team per deployment, rather than carried by a fixed route of ours. The reference itself is Onomi 360's own reference for the cost line. The commitment your process raises carries that reference out with the committed amount it was raised for, so the invoice comes back quoting the same value the connection matches on.

    No planner enters that reference on a cost line. Its form for your deployment is settled with your SpotMe implementation team when the connection is scoped. What you prepare here is your reference convention and the posting on your own side, rather than an export to switch on. The inbound half does not depend on how that was arranged. The invoice comes back carrying the reference, so it is matched to a line on a value both systems already hold.

    Third, the handling of the two ways a match can fail and the two refusals that follow a match that succeeded, which do not all end the same way. An invoice whose event reference resolves to an event, but whose cost-line reference matches no line on that event, is recorded against that event as unmatched and listed for the event's finance owner. An invoice whose event reference resolves to no event is refused at the connection, and returned to your posting system as a failed write. It is never recorded against an event.

    The other two are about the cost line rather than the invoice, since both references resolve and the line still refuses the amount. Both are recorded in the Unmatched invoices view rather than settling. The first is an invoice whose GL code matches no budget category. The second is an invoice against a line a confirmed allocation has already read, which is not applied over the confirmed figure.

    The first clears when the invoice is resent against a code a category carries, or when the event's finance owner enters the actual and dismisses the row with a reason. The second settles once the event's finance owner reopens the allocation and the invoice is resent, while nothing has been delivered. Once the handoff has been delivered to a connected destination, the reopen is no longer available. The correction then runs through the versioned Correct allocation path before the resend. That is the state a late invoice normally arrives in, because allocation runs after reconciliation.

    The mechanism behind these four is documented in How to use the Budget module. The reopen and the correcting version are in How to manage transfer of value on your events. The connection is in the ERP cost and invoice sub-pattern of Integration patterns: connecting Onomi to your enterprise systems.

    Fourth, the currency your ERP posts in. An event budget is kept in one currency, and nothing is converted. So an invoice whose currency differs from the event's budget currency is not applied to the cost line. It is recorded against the event alongside the unmatched invoices, and listed for the event's finance owner. The integration posts in the event's budget currency, which is the value the connection expects. Every invoice the match refuses is read in the Unmatched invoices view on the event's Budget module. Name who works that list before the first load.

    Fifth, the records the connection reaches. It addresses event records. A cost carried by no event record is never settled by an ERP invoice, and never raises an Unmatched invoices row.

    Sixth, the verification step. Post one invoice against a test event. Then confirm the line shows its Actual amount and its Invoice reference on that event's Budget module. The connection itself is documented in the ERP cost and invoice sub-pattern of Integration patterns: connecting Onomi to your enterprise systems.

    See How to manage payments, honoraria, and reimbursement on your events.

17. The program layer, reports, and dashboards. Customer-side setup in Onomi 360. The calendar, Contacts, and Reports need no configuration of their own. Neither do the three out-of-the-box dashboards on Insights, the request pipeline, spend, and engagement views, which arrive built and filterable. Depends on step 2 for the records they read.

    What this step asks you to decide is smaller than a configuration, and worth an early session anyway. Decide which saved views your teams work from. Decide which of them an administrator publishes as a template, so every reader opens the same starting point rather than building their own. A reader personalizes a dashboard for themselves, adding, removing, reordering, and resizing its panels, and saving the result as a view of their own. An administrator-published template is what a whole team inherits.

    Program level here means global and filterable, not an entity above events. The filters are the dimensions step 3 entered, therapeutic area, business unit, and geography among them. A program-level read is the same surface under a wider filter.

    Reading the numbers is a grant rather than a setting. The calendar, Contacts, and reports open on a Program lead assignment, and the cost-facing reports on a finance-role assignment, each bounded by the scope on it. Plan that grant with this step. The phase verification below, a saved custom report scheduled to your own address, is run on it. An administrator holding no such assignment reaches no numbers.

    Prepare: the saved views and dashboard templates your teams start from, and who publishes them.

    See How to use Onomi 360: the portfolio calendar, engagement view, and reports.

18. Analytics API and BI. Organization enablement through your Account Manager. Name the grant this step needs before you plan the users. Analytics API access is a separate grant from Developer API access. It is not one your administrators make themselves.

    The Analytics API is enabled per organization by SpotMe, and its developer role is enabled the same way. Ask your Account Manager to enable the API for your organization. Ask them to grant the organization-scope Analytics API developer role (account_api_developer) to the users and integration accounts that need it. Ask for the customer-scope role (customer_api_developer) where your reporting spans several organizations in one account.

    Prepare: the holders of that role, and a dedicated integration user per connected system. Prepare the organization ID those endpoints take as a parameter, shown in Backstage under Organization > Details. Prepare too where the bearer token those endpoints authenticate with is created for a holder of that role, settled with your SpotMe Account Manager when the API is enabled. Live feeds into your warehouse are activated with your Account Manager alongside the Analytics API.

    There is no per-workspace provisioning to do for this step. Reads are served at organization or customer scope with the organization ID as a parameter, so they do not depend on workspace membership.

    The operational REST API. Where the same integration account also calls the operational REST API, provision it for that surface as well. It holds the organization Admin or Organizer role, because Developer API access is granted only to those two. A service account provisioned as a Member or a Guest cannot create a token at all. Size that account's reach from the organization role it holds rather than from its workspace list, since both of those roles carry organization-wide rights.

    Adding the integration user to each workspace the integration touches is still worth doing, deliberately and event by event rather than assumed from the grant. It keeps the account's intended reach visible to an access review. It is not what bounds the credential.

    See Analytics API, and Integration patterns: connecting Onomi to your enterprise systems.

19. Data classification labels and retention per record class. Customer-side setup in Onomi 360. The levels and their handling rules sit under Policies > Classification, and the periods under Policies > Retention. One working session with whoever owns your records policy.

    Prepare:

    • your classification levels and handling rules,
    • the classification level that applies to each record class,
    • your retention period per record class,
    • for the event-record class, which compliance reviewers your View rule names alongside the finance-role holders, because the venue-rule result they read is recorded on that record,
    • and, for the event-record and confirmed-allocation classes, which Program lead assignments your View rule names alongside them. The unattributed remainder does not travel with the handoff, and the people who file your disclosures read it on the Review tab of the event's Transfer of value module before they file,
    • and, for the event-record, budget, and confirmed-allocation classes, which entries your Export rule names, so the finance-role holders who take the closure export are admitted.

    The three handling rules. The Share rule names who may pass a record to another user inside the platform. On the surfaces this documentation covers there is no such control. Plan it consistently with the level's View rule, and expect it to add no restriction on those surfaces. The View rule and the Export rule are the two that decide what a reader opens and what leaves the platform.

    On the money lane. Setting a View rule on the record classes the money runs through takes one piece of planning with them. A meeting your organization runs as record-only has no workspace, so the Workspace planners entry admits nobody on it. On the record classes the money runs through, a holder of the finance role whose scope covers the event is the only writer. That holder reconciles the cost lines and records the closure with Close event. The closure is what starts the retention clock on the classes that count from the close date.

    When you set a View rule on the event-record, budget, or confirmed-allocation record classes, name entries that admit the finance-role holders whose scope covers those events.

    On your compliance reviewers. The event-record class takes a second piece of planning, this one for your compliance reviewers. The venue-rule result on a venue is recorded on the venue entries in the event record's Venue section. The compliance reviewers whose scope covers those events read it there. A View rule on the event-record class therefore also names entries that admit them, alongside the finance-role entries named above.

    On the people who file your disclosures. The event-record and confirmed-allocation classes take one more piece of planning, this one for the people who file your disclosures. The unattributed remainder does not travel with the handoff. Those filers read it on the Review tab of the event's Transfer of value module before they file. The assignment that gives them that read is a Program lead assignment whose scope covers the events they file from, as How to manage transfer of value on your events sets out.

    That read sits inside the event-record and confirmed-allocation classes, so when you set a View rule on either class, name entries that admit those Program lead assignments alongside the finance-role and compliance-reviewer entries named above. A rule that admits the finance-role holders and the compliance reviewers but not the filers leaves a cost of the event outside the filed dataset with nobody able to see it.

    On the Export rule. Those cases all concern the View rule. The Export rule takes one of its own, because the record set a closure is evidenced by is produced as an export rather than read on a surface. It draws on three record classes: the event record, the budget, and the confirmed allocation. It inherits the strictest of the three levels, and the level that governs it is frequently not the one the rule was written for.

    When you set an Export rule on any of the three, name entries that admit the finance-role holders who take that export. A rule that does not admit them on the governing level leaves an event closable and its closure record unproducible.

    Planning the level set. Plan the level set as an additive one within the ceiling agreed for your organization. A level is edited in place, and no control removes or retires one once it has been created. A level your organization stops using stays in the list, keeps its place in the order, and counts against the ceiling. The way to take it out of use is to set the record classes that carry it to another level.

    Plan the order with the levels rather than revising it after. The order is set least to most restrictive, and the levels are reorderable in the list. An export inherits the highest level of the record classes it spans, so a reordering changes what every multi-class export inherits and which Export rule then governs it.

    The record classes. One list of record classes serves both settings. The classes are requests, approvals and their traces, budgets, and confirmed allocations. They also include transfer-of-value handoffs, consent capture records, event records with their attendee lists, and the audit records that evidence them.

    Setting the periods. The Retention tab lists one row per record class, each showing the period currently set on it. Open the class you want to change from its row, set its Retention period in years, and save. That is done per record class rather than once for all of them. Reopening the tab reads the period back on that class's row.

    Six of those classes ship at a 10-year Retention period by default: budgets, confirmed allocations, transfer-of-value handoffs, consent capture records, event records with their attendee lists, and the audit records that evidence them. Requests with their approval traces ship at seven years.

    What each period counts from. Two classes are worth naming here for the date their period is computed from. The event-record class is computed from the event close date. It applies whether or not the event had a workspace, and whether or not a request stands behind it. Audit records are computed from the date of the action each one logs and are kept until the record they evidence has expired.

    That rule runs one way only, and an audit record is not a referencing record. The audit entries that log the actions taken on a request do not extend that request's own period. A request deleted at the end of its seven years leaves its audit entries in place, running on their own clock.

Verifying each phase

Close each phase with its owning article's verification flow before starting the next:

• a routed and an auto-approved test request for phase 1 (the auto-approved one is run once a qualifying band exists, so after the per-currency band sets of step 7 are entered),
• a test budget line and policy trigger for phase 2,
• a sandbox CRM round trip for step 8,
• a test search against your venue rules for step 10,
• a saved custom report scheduled to your own address for step 17,
• and a pull of the events entity as CSV with your Analytics API token for step 18.

Do not start a phase until the verifications of the phases it depends on pass.

Working with your implementation partner

The split of work in this checklist holds when your rollout is delivered by an implementation partner rather than run directly with us. The product organization enables. The organization enablements stay ours to switch on. Your partner's team receives training, knowledge transfer, and direct access to our product specialists for the questions documentation cannot settle. Your implementation partner delivers the rollout. That means the customer-side setup, the preparation lists, the market-by-market policy work with your countries, and the coordination of the implementation projects scoped with our implementation team.

A partner-led plan usually takes the shape this checklist already has. A global template is configured once, through phases 1 and 2 and whichever phase 3 steps are in the first wave. Market waves then reuse it. The per-market work is additive: the Markets list entries, the venue rules and meal caps, the approved venue lists, and the accommodation caps. Each wave configures its own markets without touching the template, and each wave closes on the same phase verifications above.

Nothing in this checklist assumes historical data migration. Every step configures the platform forward, and the baselines fill in as events close. No step loads past events, budgets, or allocations. What your organization and your partner prepare are the decisions and lists named per step, rather than an extract of a system being replaced.

* Onomi 360 MeetingsEQ exclusive capabilities.