How to plan your Onomi 360 implementation

An Onomi 360 rollout combines organization enablement, customer configuration, and connections to enterprise systems. This guide puts those activities in dependency order and identifies the decisions to prepare before each phase.

Use the sequence as a planning baseline, not as a requirement to launch every capability at once. Your organization can roll out by country, division, or request category and add optional capabilities later.

The three kinds of implementation work

• Organization enablement is a capability activated for your organization by your SpotMe Account Manager. After enablement, your administrators own its configuration.
• Customer-side setup is work your team completes in Onomi 360 or in your own systems. It normally needs product guidance, not development.
• Implementation project connects Onomi to an enterprise system or establishes a customer-specific data contract. Your technical owners and the SpotMe implementation team define and test it together.

Configuration is usually faster than the policy decisions behind it. Agree categories, thresholds, scopes, ownership, and market-specific rules before the working session in which they are entered.

Before phase 1: settle data locations

Agree the data location for the organization and its event workspace templates with your SpotMe team before either is created. Bring the requirements from your legal and data-protection teams and the regions in which your event workspaces will run.

These choices affect where organization records and workspace data are created. Review the available locations, transfer considerations, and change restrictions in Data residency.

The event platform's registration, attendance, and consent capabilities are an existing foundation, not a numbered Onomi 360 implementation step. Configure them per event workspace as described in HCP registration and validation on your events.

Phase 1: identity and operating foundations

Phase 1 establishes how people sign in, how requests become events, and which shared lists later policies can use.

Step 1: Enterprise sign-in and provisioning

Configure single sign-on (SSO) with your identity provider (IdP) team and your SpotMe Account Manager. Prepare the protocol, IdP metadata or client credentials, test users, and the workspace-matching approach.

The Onomi configuration normally fits in one working session, but the IdP change window often determines the delivery date. Decide whether user lifecycle management uses just-in-time (JIT) provisioning, System for Cross-domain Identity Management (SCIM), or an administrator-managed process. See Assigning roles, enterprise sign-in, and provisioning.

Step 2: Requests, approvals, and event creation

Enable Onomi 360 and the request and approval suite. Sign-in comes first because requesters use it to reach the meeting request portal.

Prepare the request categories, their field sets, approval routes, compliance gates, auto-approval policy, notification recipients, and the workspace behavior for each category. Decide whether approval creates a workspace immediately, creates it when Start execution is selected, or keeps the event record-only.

Also name the workspace template and data location used by each category that creates a workspace. A record-only category needs an explicit finance-owner process because it has no workspace planners.

Use these task guides for the configuration:

• How to set up and use meeting requests and approvals
• Configuring the request form and its categories
• Configuring approval routing, the compliance gate, and auto-approval
• Configuring notifications for requests and approvals
• From approval to execution and auditing requests

Step 3: Organizational dimensions

Create the shared Business unit, Therapeutic area, and Brand lists under Policies > Dimensions. Geography uses the platform country list.

The request form, role scopes, compliance routing, and reports all select values from these lists. Agree the canonical names and codes before configuration, especially if they arrive from a CRM or master-data system.

Step 4: Markets

Create the Markets list under Policies > Markets. A market gives venue, meal-cap, travel, and booking-team policies a common key.

Set each market's currency and agree how countries map to markets. If the reporting currency is not yet configured, record the intended value and verify the market currencies again during the budget phase.

Step 5: Roles and scopes

Decide who holds each built-in Onomi 360 role and how Geography, Business unit, Therapeutic area, and Brand bound its scope. Assignments can be organization-wide or limited to selected dimension values.

Complete this before approval routing because only a holder of the required role can be selected for that work. See Onomi 360 roles, permissions, and scope.

Step 6: Languages

Choose the organization default language and any portal languages added beyond the built-in interface languages. The default is also the fallback for request and approval notifications when a translation is unavailable.

Prepare translated category names, field labels, instructions, and notification content with the market owners who approve that wording. See Running multilingual events across global markets.

Phase 2: finance and compliance

Phase 2 establishes the financial record and the HCP identity and consent flows that disclosure and speaker programs depend on.

Step 7: Budget configuration

Enable the Budget suite and prepare the category hierarchy, general-ledger codes, budget bands by currency, reporting currency, finance codes, and policy thresholds. Configure budget bands before finishing request fields, approval rules, or auto-approval conditions that use them.

The Budget suite is also required for lifecycle closure because Close event, the Finance owner, and reconciliation controls are on the budget header. See Setting up budgets: categories, bands, and policies and Budget capture at request and working the budget during planning.

Step 8: CRM and HCP master connection

Define which system owns HCP identity, consent, and upstream event approval. Your CRM or master-data system remains the system of record; Onomi receives the identifiers and statuses needed for event work and sends permitted updates back.

Prepare matching keys, field mappings, event filters, consent gates, environments, and error ownership. A managed package installation in Veeva or Salesforce follows the customer's CRM release process, so include sandbox and production windows in the plan. See Connecting CRM, HCP identity, and consent.

Step 9: Transfer of value

Map budget categories to disclosure categories and decide whether each mapping defaults to Individual or Shared attribution. Mark the registrant types that are transfer-of-value relevant.

Identity resolution against the HCP master must be working before allocations can be confirmed reliably. See Setting up transfer of value and cost category mapping and Running and correcting an allocation.

Phase 3: sourcing and travel

Step 10: Venue sourcing

Enable venue sourcing and agree the sourcing partner, supported markets, organization terms, contracting route, and ownership between internal teams and agencies. Then configure the market venue rules and approved lists.

Start with How to source a venue from your event and Setting venue rules in Onomi 360.

Step 11: Market-to-team mapping

For every market, name the internal team, agency, or travel management company that works its requests. This mapping depends on the Markets list from step 4.

Agree how an unmapped market is handled and who maintains the mapping as countries or suppliers change.

Step 12: Travel

Configure the travel step, travel policy, and the request fields used for accommodation and transportation. The step reads event dates, markets, room blocks, and the market-to-team mapping.

Treat a connection to a travel management company or travel system as an implementation project per environment. See Setting up travel and capturing travel needs and The booking loop, manifests, and travel reporting.

Phase 4: extensions and reporting

Step 13: Speaker programs

Configure the speaker-program request category, its approval and compliance rules, the speaker roster, and activity caps. The category counts toward the organization's active request-category limit.

Speaker identity depends on the same HCP master and resolution process used for transfer of value. See How to run a speaker program.

Step 14: AI assistance

Agree the enabled AI capabilities, model provider, data boundaries, and customer approval process with your SpotMe team. Organization enablement is quick; internal model-governance review usually sets the schedule.

See How to use AI assistance in Onomi 360.

Step 15: Disclosure handoff

Define each transparency destination, its country coverage, delivery format, credentials, and correction process. The handoff consumes confirmed transfer-of-value allocations, so step 9 and identity resolution come first.

See The disclosure handoff and accessing allocation data.

Step 16: Payments and reimbursement

Enable the payment and claim-capture surfaces you need. Treat each connection to an expense system, ERP, or payment gateway as its own implementation contract with explicit matching, status, and error-handling rules.

See How to manage payments, honoraria, and reimbursement on your events and Connecting finance, procurement, travel, and transparency systems.

Step 17: Program views and reports

Confirm which roles need the portfolio calendar, Contacts, Insights dashboards, and reports. Agree the shared dimensions used for filtering and the saved reports or dashboard views required at launch.

The standard views need no integration project. See How to use Onomi 360: the portfolio calendar, engagement view, and reports.

Step 18: Analytics API and BI

Enable Analytics API access separately from Developer API access. Name the integration users, environments, datasets, refresh schedule, BI destination, and monitoring owner.

Verify which records and fields each API surface exposes before building dashboards. See Using Onomi APIs, event streaming, analytics, and BI.

Step 19: Classification and retention

Agree the classification levels, handling rules, and retention periods with the owners of your records policy. Configure them only after the event lifecycle and closure point are understood, because retention can depend on recorded closure.

Include access, export, regional-transfer, and deletion behavior in the acceptance test. Your SpotMe team confirms the configuration available for your deployment.

Verify each phase

Use representative test users and records before moving to the next phase. Test at least one permitted path and one refused path for every rule.

For each phase, confirm:

• the expected actor can complete the task and an out-of-scope actor cannot;
• the event, request, financial, or HCP record lands in the intended system of record;
• audit entries name the action, actor, and time;
• notifications and integrations handle a failed or unmatched record visibly; and
• reports and exports return the same scoped population shown in the product.

Record the agreed configuration, integration contracts, customer owners, and support route in the deployment solution architecture.

Work with an implementation partner

An implementation partner may configure customer-owned systems, prepare mappings, and test connected workflows. The customer still owns policy decisions, credentials, production approval, and the system-of-record rules.

Give the partner only the roles and environments required for its work. Review agency and partner boundaries in Agency access and strategic meetings management scope.

* Onomi 360 MeetingsEQ exclusive capabilities.