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

Onomi 360 is the application where your event program comes together: one calendar across every event, engagement consolidated per HCP, and the dashboards and reports your leadership plans against. This guide covers the day-to-day flows: reading the calendar and looking up an HCP's engagement history. It covers reading a dashboard at the level you need and saving your own arrangement of it. It also covers building, scheduling, and exporting reports. For what Onomi 360 does and where its boundaries are, see 2025.10: Onomi 360 (October 7, 2025).

The name sits at two levels. Onomi 360 is the application. The Onomi 360 section of a release note versions the views over your event records inside it, rather than the application as a whole. Those views are the portfolio calendar, Contacts, the dashboards in Insights, and reports. That section also versions the data-delivery surface announced under it, the live feeds that run on the Analytics API.

Overview

Onomi 360 is its own application, sitting above your individual event workspaces. This guide covers four of its sections:

• The Portfolio calendar: every planned and completed meeting, congress, and webinar managed on the platform, in one view.
• Contacts, the HCP engagement view: a consolidated engagement timeline per HCP, spanning every event in your program.
• Insights: three dashboards that ship with the platform, each readable at global, regional, or country level and each personalizable and savable per user.
• Reports: standard reports across the event lifecycle, from intake to closure, and a builder for the cuts your own program needs.

Program level here means global rather than a layer of its own. It is one organization-wide view of every event, narrowed by therapeutic area, brand, business unit, geography, request category, and period. No grouping entity sits above the event records. Program leads work in the calendar and the reports day to day. Executives read the dashboards. Field and medical leadership use Contacts to prepare interactions.

Where strategic meetings management roles are assigned, each of these views follows the role's scope. A program lead scoped to a geography or business unit reads their slice of the calendar, Contacts, the dashboards, and the reports. An organization-wide assignment widens the scope rather than the surface set: it sees everything its role opens, across the organization, rather than everything in the application. The scope model is documented in Agency access and strategic meetings management scope.

Every section is a view of the event records themselves, so none of them needs feeding. There is no consolidation step and no quarterly collection of spreadsheets from markets.

Before you start

• Access to Onomi 360. Onomi 360 is reached at its own address and from the application switcher in Backstage. You sign in with your usual account, including through your organization's single sign-on. Requesters never need Backstage: the meeting request portal is reachable by link and single sign-on. Administration sits with your Backstage organization Admins, who hold the Onomi 360 Policies area. Strategic meetings management roles and their scopes are granted in Onomi 360 under Users and roles.
• Access follows scope. What you see follows your strategic meetings management role assignment and the scope on it. That scope is geography, business unit, and, where your organization uses them, therapeutic area or brand. Five surfaces answer to it: the Event requests, the portfolio calendar, Contacts, the dashboards in Insights, and reports. Which of those surfaces opens at all is decided by the assignment a person holds, and the scope on that assignment bounds what each surface it opens shows.
  • A Program lead assignment opens the portfolio calendar, Contacts, the dashboards in Insights, and reports across the scope on the assignment. It also opens the event records inside that scope and their per-event modules read-only.
  • An Approver opens the Event requests, holding its scope plus every request routed to them. The Approver also opens the event records inside the scope, and their per-event modules read-only. Those modules are the Budget module and its cost lines, the event's travel records, and the event's Transfer of value module. That module carries the per-healthcare-professional allocations, consent states, attendance states, and unattributed remainder. An Approver opens no portfolio calendar, no Contacts, no dashboards, and no reports.
  • A compliance reviewer's assignment opens the Event requests, the event records in scope, and the venue controls on them. It opens no portfolio calendar, no Contacts, and no dashboards.
  • A finance-role assignment opens the Event requests, the event records in scope, and the cost-facing reporting bounded by that scope. That reporting means the Spend dashboard, the reports in the Financials group, the costs entity of the report builder, and the reinvoicing summaries. The assignment opens no Contacts.
  • A Sourcing assignment opens the event records inside its scope and their per-event modules on the terms the role registry states. The Sourcing module is writable under the grant, and the rest of the record is read-only. That rest includes the Budget module and its cost lines, the event's travel records, and the event's Transfer of value module. That module carries the amount allocated to each healthcare professional in the transparency categories, each attendee's consent state, their attendance state, and the remainder left unattributed on the event. The assignment opens no program-layer section, so it adds no program-layer visibility of its own.

  A Sourcing assignment opens the event records inside its scope, and no list of its own. The events to source are reached two ways. One is a direct link to the event record, sent by the event's finance owner or by the planner handing sourcing over. The other is the event's workspace, where the holder is a member of one. An organization-wide assignment widens the scope rather than the surface set: it sees everything its role opens, across the organization, rather than everything in the application. Requesters always see their own requests.

  Workspace membership keeps governing the event workspaces themselves, and a scope opens no workspace that already exists. The single route from a scope to workspace membership is selecting Start execution on an event whose request category is mapped to Create at Start execution. The person who selects it becomes the first Manager of the workspace that action creates, as set out in Role-based access and visibility for internal and external stakeholders.

  The per-event strategic meetings management modules sit on an event record in Onomi 360: Request, Budget, Sourcing, Travel, and Transfer of value. They open on two paths. The first is to users whose scope covers that event, each writing there what their own role carries. The second is to the planners of that event's workspace, whose workspace Manager or Editor role opens that event's execution-adjacent modules and nothing portfolio-wide. Neither path widens the program-layer views, which stay bounded by strategic meetings management scope.

  Role-based access and visibility for internal and external stakeholders sets out four more things. It gives the precedence rule and the per-role answer stating which surfaces each assignment opens. It gives the role registry's per-role write column, stating what each role may write on an event in scope. It also gives a worked example.

• The data comes from the event records. The calendar, Contacts, and the reports read from the events managed on the platform. Engagement signals populate as events run. Session attendance, Q&A questions, and survey answers are captured during event execution in each event's workspace. Booth conversations arrive from congress capture with the Universal lead capture module.
• Filter values come from the event records too. Therapeutic area, brand, business unit, geography, and request category are read from each event's record. Keeping those fields consistent across your events keeps the filters clean.

  Two of them are worth naming precisely. The Geography filter reads the record's Country and city field. The Request category filter reads the category the request was raised under. On an event approved upstream in your CRM, it reads the category the inbound mapping carried (see Integration patterns: connecting Onomi to your enterprise systems).

  They are the same dimensions your role scopes and your compliance routing run on. A division head scoped to one business unit can therefore filter the calendar and the reports to it.

If you cannot open these sections, or do not see them inside Onomi 360, ask your organization Admin, or contact your SpotMe Account Manager. Signing in without an assignment that opens them reaches a page. It reads "You do not have access to the program layer of Onomi 360. The portfolio calendar and Contacts are opened by a Program lead assignment, and the dashboards and reports by a Program lead assignment or, for the cost-facing ones, a finance-role assignment, whose scope covers them. Ask your organization Admin." A saved link gives the same answer, so nothing hangs on the route you took to get there.

That answer covers the four sections this guide describes: the portfolio calendar, Contacts, Insights, and reports. It covers nothing else in the application, the natural-language question panel included. That panel rides the portfolio calendar and reports rather than opening as a section of its own (see How to use AI assistance in Onomi 360). Two surfaces sit outside it:

• The Event requests is a separate section of Onomi 360, listed in the left navigation and documented in How to set up and use meeting requests and approvals. It is opened by an Approver, a Compliance reviewer, or a finance-role assignment, and by your organization administrators for administration. It is not one of the sections this message covers.
• The meeting request portal is a separate surface, reached at its own address with single sign-on and needing no role assignment. Anyone in your organization submits and follows their own requests there, as documented in Role-based access and visibility for internal and external stakeholders.

To open them, sign in to Onomi 360. It opens on the Portfolio calendar, with the four sections this guide covers listed in the left navigation. The rest of the navigation has its own articles. The Event requests and Policies are covered in How to set up and use meeting requests and approvals.

The portfolio calendar

The calendar shows every meeting, congress, and webinar managed on the platform, planned and completed alike. That includes events run by a local affiliate or an agency on your behalf. Each entry shows the event's name, request category, dates, and geography, and whether it is planned or completed.

The distinction is by date. Planned covers events whose End date is still ahead, including events running today. Completed covers events whose End date has passed. That field sits on the event record, and is documented in From approval to execution and auditing requests.

One case falls outside both, and two things produce it. The first is an event that arrived already approved from your CRM with neither date mapped. The second is an event created from an approved request whose category omitted Proposed dates or left it optional and unanswered, so approval fixed no dates. Either way the event is classified as neither Planned nor Completed. It sits in neither view until those dates are set on its event record. For the first case, see Events approved upstream in your CRM in From approval to execution and auditing requests. For the second, see step 6 of Configuring the request form and its categories.

1. In Onomi 360, open the Portfolio calendar. It opens on the current period in the Month view. Use the toggle at the top to switch to the List view. That view shows the same events as rows, with their name, request category, start and end dates, geography, business unit, brand, and therapeutic area.

The overview keeps attention items and portfolio totals above the calendar. Scroll down when you need the complete month and its upcoming-events rail.

2. Switch to World map to see the geographic spread of activity. The map uses the same portfolio data and active filters as the calendar, colors events by request category, and highlights events that are live. Use the range selector to move between live activity, the past quarter, the next quarter, and the full year.

Scroll down to give the map the full working area while keeping the same filters and range selection.

3. In the filter bar, narrow the view. Each filter is a multi-select: Therapeutic area, Brand, Business unit, Geography, Request category, and Period. Filters combine, so one therapeutic area in one region for the second half of the year is a three-filter view, not an export. The calendar updates as you set each filter, the active filters stay visible in the bar, and Clear all resets them. The filters you set are kept while you move between the Month and List views, and for the rest of your session. They are cleared when you sign out.
4. Use the Planned and Completed toggles to show upcoming events, past events, or both together on the same timeline.
5. Select any event to open its event record. The record is the same kind of record whoever executed the event. One run by an agency for one country team opens the same way as the global congress your central team executed.

Note: An empty calendar is a scope and filter answer rather than a fault. Where the period holds no events inside your scope, the calendar reads "No events match your scope for this period." Where your scope holds no events yet, it reads "No events in your scope yet."

Clear the filters, then check the scope on your role assignment with your organization Admin.

Tip: To see the organization's activity in one therapeutic area for a period, combine the Therapeutic area and Period filters; the filtered view covers every market's events, whoever executed them.

Note: For a cut of the portfolio you need every week, build the same filters into a custom report, save it, and schedule it (see Reports and exports below).

To verify a filtered view, set a single filter, for example one therapeutic area. Check that the calendar narrows to matching events. Open one of them and confirm its event record carries the value you filtered on.

Contacts

Contacts consolidates, per person, the signals your events captured: what each HCP attended, asked, and answered, across every event in your program.

Finding an HCP

1. In Onomi 360, open Contacts.
2. Search by name or email address. Matching profiles appear as you type, each showing the profile details your events hold, such as country and institution. Two people with the same name are easy to tell apart.
3. Select the person. Their record opens on the Timeline tab, with the consolidated timeline in view.

Note: The view searches the identity-resolved profiles built from your own events. A person who has never taken part in one of your events has no profile here.

Reading the timeline

The record opens on the Timeline tab, with Profile, Transfer of value, and Insights beside it. Above the timeline, the record answers what a planner asks before an invitation goes out:

• who the person is, with their tier, specialty, institution, the identifiers your sources hold, and the compliance state for engagement;
• what they have taken part in this year, with events year to date, meetings and their attendance states, sessions attended, congress interactions, and transfer of value year to date;
• what they are already booked for, with the status of each upcoming engagement; and
• where their knowledge has moved.

Where your events asked the same knowledge or confidence question before and after a session, the knowledge-progression panel shows the movement. It runs from the first recorded baseline to the latest check, on a ten-point scale. The key insights beside it are short observations read from the entries on this record and from nothing outside it.

The timeline holds the signals from every event in your program, in one place, event after event. Each entry carries the date, the event it was captured at, and the signal type. It carries the person's role and your organization's role at that event. It carries whether the interaction sat on your medical or your commercial lane, and the signal itself:

• Sessions: the sessions attended and the ones skipped, with the session title.
• Questions: the question asked in a symposium Q&A, as it was asked.
• Surveys and knowledge checks: the answers given.
• Booth conversations: the topics raised in a conversation captured at a congress booth.
• Meetings: the meetings the person took part in, with the attendance state recorded for them.

Each entry names its source event, and selecting an entry opens the detail. Session attendance, Q&A questions, and survey answers are captured during event execution in that event's workspace. Booth entries come from congress capture with the Universal lead capture module.

A meetings entry comes from the attendee row on the event record. That entry carries the event it names and the attendance state recorded on that row (Show, No-show, or No state recorded). The entry exists because the attendee row exists, not because a state has been set on it. A row still at No state recorded produces an entry reading No state recorded, until someone sets the state. The states and what each one means are set out in the attendance check in Before you allocate in Running and correcting an allocation.

A meeting your organization runs as record-only, with no workspace, produces one. That attendee row with its attendance state is the whole of what such a meeting captures. There is no registration, no session, and no behavioral signal on that lane, as set out in Integration patterns: connecting Onomi to your enterprise systems.

What an expanded entry holds follows the kind of event it came from, because that is what the event captured:

• Congress: the badge capture with the moment it happened, who it was captured for, and the identity it resolved to. The entry also holds the lead form answers, the content the person opened at the booth, and any meeting requested there.
• Symposium: the sessions registered and attended, the live and on-demand viewing time, the polls answered, the questions asked as they were asked, and the pre- and post-session survey answers.
• Standalone events: the attendance state with the time it was recorded, the meeting and its owner, and the request the meeting came from. The entry also holds the case forms submitted for discussion, which carry de-identified case descriptions and never patient data.

Each detail is read from the event that captured it rather than assembled here. Where a detail is empty, that event did not capture that signal. Consent is not one of these details and reads nowhere on the timeline. It sits in the record's profile details: the consent state, the wording version presented, and where and when it was captured. The profile details also hold a link to the consent record itself. Consent is documented in HCP registration and validation on your events.

How long an entry stays on the timeline follows from where its source data lives.

• Some entries are captured during event execution in that event's workspace: Sessions, Questions, Surveys and knowledge checks, and the Booth conversations captured with the Universal lead capture module. They follow the workspace lifecycle, so they leave the timeline when the workspace is deleted.
• A Meetings entry is built from the attendee row on the event record. That row is a strategic meetings management record class, retained per record class independently of workspace lifecycle. The entry stays for the retention period configured on that class, and is read on that event record.

After a Forget me, the erased person is no longer returned by this view's name or email address search, and no timeline opens for them. The erasure deletes the app profile and removes the name and the email address from the attendee rows. The retained Meetings entries stay on their own event records, read there against the master identity reference. See the Data privacy guide.

Where your program needs engagement history beyond that window, load it into your own warehouse through the Analytics API while the workspace still exists. Entries sourced from a workspace outside your organization's region are read into this view under the transfer mechanism in your data processing agreement. That mechanism is the standard contractual clauses where the two regions require them. The workspace's own data stays in its region.

What syncs onward

Structured signals from this timeline are written back to your CRM, and what reaches it is narrower than what you read here. The write-back carries the engagement activities your CRM connection is configured to receive. Your team defines which events and activities are relevant, and saves them as the objects or attributes your operating model needs. The write-back carries them for the attendees whose consent permits the sync, because a declined or missing consent withholds that data. The history your field teams see in the CRM is therefore a configured subset of this timeline rather than a copy of it.

A Meetings entry reaches your CRM a different way, whatever the consent state on the row reads. The meeting record and its attendee row travel on the connector's Meeting record sync, outbound flow rather than as engagement write-back. That holds on an event backed by a workspace and on a meeting your organization runs as record-only. On a record-only meeting that flow is the whole of the CRM path, because with no workspace there is no engagement to write back.

The write-back is configured together with your integration team as part of your CRM connection. See the CRM as the HCP master pattern in Integration patterns: connecting Onomi to your enterprise systems, and HCP registration and validation on your events for the consent model itself.

To verify the view, pick an event that finished recently. Look up an attendee who asked a question or answered a survey there. Check that the entry appears on their timeline naming that event.

Dashboards

Insights holds the dashboards that ship with the platform. Each one reads the same event records the calendar and the reports read, so nothing is assembled or uploaded to keep a dashboard current. Each one is read at global, regional, or country level from the same screen. What a dashboard shows is yours to change. Panels are added, removed, reordered, and resized without an administrator. The arrangement is saved as a view that opens the same way the next time you sign in.

Opening a dashboard

1. In Onomi 360, open Insights. It opens on Request pipeline, with Spend and Engagement beside it in the view switcher. The time of the last refresh sits above the widget grid.
2. Select the dashboard that answers your question:
   • Request pipeline: intake, approval progress, and what is waiting. The headline figures are requests year to date, and the number waiting on approval with how many of those are past the service target. They also include the median time to approval against that target, the first-pass approval rate, and the requests returned for changes. The panels below hold Requests by stage, Ageing of the approval queue, Cycle time to approval, and Requests by category.
   • Spend: approved budget against actuals. The headline figures are the approved budget for the financial year, actual to date, and the amount committed but not yet invoiced. They also include variance on the closed quarters, and cost per attendee against its comparison period. The panels hold Budgeted against actual by period, Reconciled against unreconciled, Spend by region and country, Spend by business unit, Cost per attendee, and Top events by spend.
   • Engagement: events, attendees, and reach. The headline figures are events delivered, attendees engaged, and unique HCPs reached deduplicated across events. They also include the attendance and survey response rates against their comparison periods. The panels hold Events and attendees over time, HCP reach by therapeutic area, and Attendance rate by request category.
3. Set the Aggregation control to Global, Region, or Country. Global reads everything inside your scope as one set of figures. Region rolls the same measures up per region. Country breaks them down per country. One dashboard therefore answers a global, a regional, and a local question, rather than a second dashboard being built for each level. Panels that carry a geographic breakdown of their own, Spend by region and country among them, follow the control.
4. Narrow the data in the filter bar. The dimensions are the six the calendar and the reports use: Therapeutic area, Brand, Business unit, Geography, Request category, and Period. Filters combine, and every panel recalculates together. One business unit in one region for one quarter is a three-filter read rather than a rebuilt dashboard.

Note: A dashboard reads captured actuals. Attendance forecasts are not part of these views, or of the reports. A forecast is produced per event and read on that event's own record in Onomi 360, in the Attendance forecast panel, shown with the baseline it draws on. It is documented in How to use AI assistance in Onomi 360.

Note: Cross-event figures convert amounts into the reporting currency your organization defines, using the reference-rate table your administrators maintain. Each event budget stays in its own currency and is never converted. The reporting currency and the rate table are documented in the Reporting currency and reference rates section of Setting up budgets: categories, bands, and policies.

Personalizing and saving a view

Nothing in this section waits on an administrator. Every panel carries a drag handle at its top left and a resize grip at its bottom-right corner. Its menu holds Resize, Duplicate, and Remove widget. Add widget closes the grid and opens the widget library, which holds 18 widgets across requests, approvals, sourcing, spend, and attendance.

1. Arrange the dashboard. Drag a panel by its handle to move it, and drag the grip in its bottom-right corner to resize it. Select Remove widget in a panel's menu to take it off the view.
2. Select Add widget and pick from the library, either to put a panel back or to add one the shipped dashboard does not carry.
3. Select Save view and name it. The view holds the panels you kept, the order and the size you gave them, the filters, and the aggregation level. It opens that way the next time you sign in, rather than reverting to the shipped arrangement.
4. Move between your views from the view picker at the top of the page. Your own views are listed under My views, with the templates your administrators publish under Published templates below them.

A saved view persists, and a filter you set without saving does not. Filters set on a dashboard behave as they do on the calendar and in reports. They are held for the rest of your session and cleared at sign-out. A cut you want back every week belongs in a saved view. Where you need the rows rather than the picture, it belongs in a saved report.

Using an administrator template

Your administrators publish dashboard templates per role. A new holder of a role then opens something already arranged for that work, instead of a blank page. A template is a starting point rather than a fixed layout.

1. Open a published template from the view picker. It opens with the panels, the order, and the sizes the administrator published.
2. Change it as you would any dashboard, then select Save as a new personal view to keep the result. Your personalization sits on top of the template rather than replacing it. The published template is untouched for everyone else reading it.
3. To go back to the layout as published, select Reset to the published template. That discards the arrangement you had on top of it and leaves your other saved views alone.
4. Administrators reach Manage published templates in the same menu, which is where a template is published to a set of roles, republished, or withdrawn.

What a template shows is still bounded by each reader's own scope, so one published template serves a global team and a country team without either seeing the other's events.

Exporting a dashboard to PDF

Select Export PDF. The file carries the dashboard as you are reading it: the panels in your arrangement, the filters and the aggregation level you set, and the period they cover. A figure in the file therefore traces back to the view that produced it. PDF is the output a dashboard produces. Where you need the rows behind a panel rather than the picture, run the matching report and export that (see Reports and exports below).

To verify a dashboard, open Engagement and set one Therapeutic area filter and a Period covering completed events. Check that the events-delivered figure matches the completed events the portfolio calendar shows for the same two filters. Then select Save view, sign out and back in, and confirm the view opens with the arrangement, the filters, and the aggregation level you saved.

Reports and exports

Standard and custom reporting sit side by side in this section, and the two kinds of report belong to different people.

• The standard reports are defined once for your organization rather than per user. Their definitions are shared, and each assignment opens the ones its surfaces include. What each reader sees inside one is bounded by their own scope. A Program lead assignment opens the 20 standard reports listed below. A finance-role assignment opens the cost-facing ones bounded by that scope: the five reports in the Financials group, alongside the costs entity of the report builder and the reinvoicing summaries.
• A custom report you save is yours. It is visible to the person who saved it, in that person's own Reports list. There is no control for sharing a saved definition, publishing it to a library, or transferring it to a colleague.

Plan a program that runs across many countries and divisions on that. A cut a central team wants everyone to run is either one of the standard reports or a definition each reader rebuilds in their own list. A schedule is not transferable, and it stops with the role assignment of the person who created it. A recurring delivery your team depends on, a monthly reinvoicing run among them, is kept running by a second holder maintaining their own saved copy and their own schedule of it.

Running a standard report

1. In Onomi 360, open Reports. The list opens on the standard reports, grouped by product area, with your saved custom reports below them. Each row names what the report covers, its owner, its schedule, when it last ran, and the formats it exports in.
2. Standard reports cover the questions every event team asks, and run without extra configuration or licensing. There are 20 of them, in five groups:
   • Requests and approvals. The Event request report lists every request with its category, requester, business unit, and current status. The Approval cycle time report gives working days at each approval step, against the service target. The Approval history report gives the decision, the decider, the timestamp, and the reason for every step taken. The Declined and returned requests report lists declined and returned requests with the mandatory reason, and the resubmissions that followed.
   • Sourcing and RFPs. The Venue availability report lists the properties returned for a search, with rates, capacity, and approved-list status. The Bid comparison report puts all bids received against one RFP side by side on price and terms. The Contracted venues and savings report lists awarded venues with the negotiated cost against the first quoted one, and the saving.
   • Registrations and attendance. The Registration report gives registration status, source, and attendee details. The Capacity utilization report gives registrations and attendance against capacity, per event and per session. The Attendance report gives attendance outcomes by event and participant. The Check-in report gives check-in timestamps and channel. The Survey responses report gives response rates and question-level results.
   • Events, live and past. The Events in execution report lists approved events now running, with owner, location, and open tasks. The Completed events report lists delivered events with attendance, spend, and closure state. The Arrival and departure manifest lists confirmed travel and accommodation per traveller, by arrival day.
   • Financials. The Costs report gives budgeted, committed, and actual costs, read from the cost lines on event records. The Budget against actual report gives variance by budget category and sub-category, per event and cross-event. The Spend by cost centre report gives reconciled and unreconciled actuals by cost centre and intercompany code. The Spend by vendor report gives actuals by vendor, with the purchase order and invoice references. The Transfer of value report gives per-HCP allocated value by category, with the consent state at allocation.
3. Select a report, set its scope in the filter bar (the same dimensions as the calendar and the dashboards: Therapeutic area, Brand, Business unit, Geography, Request category, and Period), and select Run. The report opens on screen, and the Export button sits on the same view.

Five reports read the registration journey: Registration, Capacity utilization, Attendance, Check-in, and Survey responses. They read what is captured against a registration on events backed by an event workspace, so meetings your organization runs as record-only are outside them. The attendance recorded per attendee on a record-only event record is read on that record, on the Meetings entries in Contacts, and through the CRM sync. The Financials reports read the cost lines on event records, so they cover record-only meetings too.

A standard report is run and exported on demand. Recurring delivery is scheduled on saved custom reports. Where you need a standard report's cut every week, build the same data, columns, and filters as a custom report. Save it, and schedule the saved report (see Building a custom report and Scheduling and exporting below).

A standard report can be rebuilt that way where the builder holds a Data entity covering what it reads. That is the case for the registration, capacity utilization, attendance, survey response, event, and cost reports. The Check-in report is the clearest case of one that cannot. Check-ins are not one of the builder's Data entities, so that report is run and exported on demand only. It has no saved or scheduled equivalent. The platform records check-ins and the report reads them, while the report builder does not offer them as a report entity.

Building a custom report

1. In Reports, select New report. The builder opens.
2. In Data, choose the entity the report reads: events, registrations, attendance, survey responses, engagement signals, or costs. The available columns update to the chosen entity. The attendance entity reads the attendance captured against a registration on events backed by an event workspace, as the Attendance report does. Meetings your organization runs as record-only are outside it. The attendance recorded per attendee on a record-only event record is read on that record, on the Meetings entries in Contacts, and through the CRM sync. The costs entity reads the cost lines on event records, as the Costs report does.
3. In Columns, pick the fields to include and drag them into order.
4. In Filters, narrow the data by the same dimensions as the calendar, plus the fields of the chosen entity.
5. In Layout, choose the row grouping (for example by event, by country, or by month) and the sort order. The preview updates as you work.
6. Select Save and name the report. It appears in your Reports list alongside the standard reports.
7. For a variant of a report already saved in your own Reports list, open it there and select Duplicate. The variant then does not have to be rebuilt in the builder from scratch. The copy opens in the builder under its own name, and the original is unchanged.

Scheduling and exporting

1. Open a saved custom report and select Schedule.
2. Set the Frequency (daily, weekly, or monthly, with the day and time), the Recipients (email addresses), and the Format (XLSX, CSV, or PDF).

   Recipients receive the report as an attachment on that schedule. The same panel turns the schedule off again, and shows the Last run date and its outcome. That is where you check a delivery a recipient says never arrived. A monthly schedule set for a day the month does not have runs on that month's last day, and it runs once.

   Each run is generated under your own scope and classification clearance, so read the Note on scheduled deliveries below before you set a recipient list wider than your own team.

3. Optionally, for a one-off export, select Export on any report, standard or custom, and choose XLSX, CSV, or PDF. The file downloads in your browser.
4. Financial exports and reinvoicing sit with finance teams, and cross-charging and reconciliation are answered at two different levels.
   • Across events, a reinvoicing summary is a custom report grouped by country, cost centre, and intercompany code, built as described in Building a reinvoicing summary below.
   • For a single event, the financial record is the event's own records, exported from the event page once reconciliation is complete. Those records are the participants with the attendance recorded for each, the final budget with the actual amount on every cost line, and the invoice references those actuals were settled against.

   Nothing further is generated on top of them. There is no separate closure output to produce, and none to keep in step with the records. What closes the event is Close event on the budget header, and the records exported after it are what evidence the closure. Both the closure and the records behind it are documented in Reconciliation, invoices, and closing the event.

None of this needs an additional reporting license: standard reports, the custom builder, scheduling, and exports are part of Onomi 360.

Note: A scheduled delivery carries the scheduler's access, not the recipient's. A run is generated under the scope and the classification clearance of the person who created the schedule. It is evaluated at the moment it runs, rather than when the schedule was saved, so a scope that widens or narrows in between changes what the next run contains.

Where that person's strategic meetings management role assignment is removed, the schedule stops running, and the Last run entry records that it stopped and why. Recipients are mail addresses rather than platform identities, and the platform applies no per-recipient check to them. Everyone on the list receives the file exactly as the scheduler's scope produced it. Keep the mailing lists you schedule to under the same control as the data itself. Where classification rules exclude records the delivery may not carry, the delivered file states that an exclusion was applied. That is the same notice an on-screen report carries.

Note: A scheduled run that finds no rows does not send an empty file. Recipients get the message "This scheduled report returned no rows for the selected period." in place of the attachment. The Last run entry records the same, so an empty result is never read as a failed delivery.

A report whose filters have gone stale, for example a therapeutic area your program has retired, produces exactly this result.

For analytics teams who want the data in their own stack rather than in reports, live feeds to your BI environment with a documented schema are part of the platform's integration surface. They have been available since the 2026.01 release. See the Analytics API and Integration patterns: connecting Onomi to your enterprise systems. Those feeds carry the workspace-backed event and engagement data: the events, registrations, attendance, and engagement signals your event workspaces hold.

The strategic meetings management records are read in the reports above rather than in the feeds. They are read across the five groups: requests and approvals, sourcing and RFPs, registrations and attendance, events live and past, and financials. They are also read in the reinvoicing summaries prepared for cross-charging and reconciliation. Two of those record classes keep a fuller home outside the reports.

• The audit-grade record of a request means the request together with its logged events. It is taken out through the Event requests export of the records in view. One export covers up to 10,000 records, and a larger run is refused rather than truncated. For a bigger extract, run narrowed repeat exports by period, geography, or business unit. The export is not schedulable. See How to set up and use meeting requests and approvals.
• The confirmed per-healthcare-professional allocations and the transfer-of-value handoff are worked on the event record's own Transfer of value module. The Transfer of value report reads from that module rather than replacing it. See How to manage transfer of value on your events.

To verify a schedule, schedule a small report to your own address for the next delivery slot. Confirm the report arrives in the chosen format, and matches what the same report shows on screen.

Building a reinvoicing summary

A reinvoicing summary is a custom report rather than a surface of its own, so it is built, saved, scheduled, and exported exactly like the reports above.

1. In Reports, select New report, and in Data choose the costs entity. The entity itself carries every cost line on the event records in the cut you set, reconciled or not. The reconciled state is therefore set as a filter in step 3 below. That filter is what makes this a reconciled-costs summary.
2. In Columns, add the fields the cross-charge is made on. The event country, the Cost centre, and the Intercompany code are available here. In Layout the same three are available as row groupings, so a summary can be grouped by any one of them or by them in turn. The Cost centre and the Intercompany code are mastered on the event budget header (see the Finance codes for reinvoicing section of Setting up budgets: categories, bands, and policies). The event country is read from the event record's Country and city field.
3. In Filters, set the cut the summary covers: the Period, the Geography, and the Business unit. Then narrow it to the reconciled lines, on the same rule as any other custom report. The filters cover the dimensions of the calendar plus the fields of the chosen entity.

   The reconciled state of the cost line is one of the costs entity's own fields. It is the state Mark reconciled sets on a line, where the line shows as reconciled (see step 2 of Reconciling the budget in Reconciliation, invoices, and closing the event). Without that filter the cut carries the budgeted and committed amounts on lines nobody has reconciled yet. The cross-charge then goes out on figures that have not settled.

4. Select Save and name the report. It appears in your Reports list, and it schedules and exports like any other saved custom report. That is how a monthly reinvoicing run reaches your finance team without being rebuilt each month (see Scheduling and exporting above). It belongs to you like any other saved report. A run your finance team depends on month after month is kept going by a second holder maintaining their own saved copy and their own schedule of it (see Reports and exports above).

A summary reports in the event currency with the reporting-currency equivalent alongside. Each equivalent shows the reference rate it was converted at and that rate's effective date. A figure therefore traces back to the row of the reference-rate table it came from. The reporting currency and the rate table are mastered once, in Onomi 360. See the Reporting currency and reference rates section of Setting up budgets: categories, bands, and policies.

Running one needs an assignment whose surfaces include the cost-facing reports. That is a Program lead whose scope covers the events, a holder of the finance role whose scope covers them, or either of those assignments held organization-wide. What each assignment opens is set out in Agency access and strategic meetings management scope.

To verify a summary, build it over a cut holding at least one cost line that has not been reconciled, and group by cost centre. Confirm the summary leaves that line out while the event's Budget module still shows it. Confirm too that the total matches the reconciled costs on the events in the cut.

* Onomi 360 MeetingsEQ exclusive capabilities.