From approval to execution and auditing requests

Approval is where a request becomes an event, and this guide covers everything from that point: the mapping that decides what approval creates, the event's dates, and full-lifecycle and record-only execution. It also covers events approved upstream in your CRM, cancelling an event, and following and auditing requests across your organization.

Configuring what approval creates

Approval creates the event record in Onomi 360 for a request submitted through the meeting request portal. An event approved upstream in your CRM arrives with its record already created (see Events approved upstream in your CRM). Whether approval also creates an event workspace is a setting, and it is what puts a request in the full-lifecycle lane or the record-only lane.

1. In Onomi 360, open Policies, then open the Event creation tab. The tab lists one mapping per active request category on your request form, including any category you renamed or added. Every active category therefore has exactly one mapping. A category retired while requests under it are still in approval keeps the mapping those requests are created under.

   A retired category drops off the tab, and the requests approved under it keep the behavior that was in force at approval. A request submitted under a category before its retirement keeps that category. Approved later, its event is created under the mapping that category carried when it was retired. Retirement never leaves an approved request without a workspace behavior.

2. Open a mapping and set its two fields.
3. Select Save. The mapping applies to requests approved from then on; requests already approved keep the behavior in force when they were approved.

Each mapping carries:

• Workspace behavior: what approval creates for this category. One of three values:
  • Create at Start execution: the event record is created at approval, and the event workspace is created when someone selects Start execution on the event record, which moves the request to In execution. Default for the full-lifecycle categories (scientific, executive, and congress). Use it where the event team decides when delivery starts. On this mapping the workspace does not exist yet, so it has no planners. Start execution is available to holders of the finance role whose scope covers the event, the same assignment that carries the writes on an event record with no workspace. Whoever selects it becomes the new workspace's first Manager (see From approval to execution).
  • Create at approval: the event record and the event workspace are both created as soon as the request reaches Approved. The workspace is created from the workspace template this mapping names, so registration, communications, and the agenda come from that template. It is created with no team, because nobody selected an action to become its first Manager.

    Its first planners are added centrally instead. An organization Admin adds them from the organization Members flow, or from Manage organization > Workspaces > Add a member. That flow is documented in Role-based access and visibility for internal and external stakeholders. The request still moves to In execution when Start execution is selected. That action is available to holders of the finance role whose scope covers the event. It reaches that workspace's planners (Manager or Editor) as well, once planners have been added centrally. Use it for categories where every approved request is delivered and waiting to create the workspace only adds a step.

  • Record-only: no workspace is created, because the meeting itself is the execution. Default for the self-service small-meeting categories (internal). Use it wherever a category never needs registration, an agenda, or a workspace team.
• Workspace template: the organization workspace template the workspace is created from, so registration, communications, and the agenda start from your standard setup rather than a blank page. Default: your organization's default workspace template. Not available on a record-only mapping, which creates no workspace. Change it where a category needs its own starting setup, for example a congress template.

  One constraint sits behind this field. The region an event workspace holds its workspace data in is fixed when the workspace is created, and cannot be changed afterwards. An organization running events in more than one region therefore settles one question with its SpotMe team before mapping categories to automatic workspace creation: which region the workspace templates named in those mappings create in. See Data residency at SpotMe.

Note: The mapping is keyed on request category, the same axis your approval rules and the compliance gate use, so one category reads the same way across the whole configuration.

From approval to execution

When a request submitted through the meeting request portal reaches Approved, Onomi 360 creates the event record automatically and links it to the request. The two are one record seen through two lenses. Requesters keep following status from My requests in the portal. Planners work on the event in Onomi 360, where the Request module opens the linked request record. An event approved upstream in your CRM arrives with its record already created (see Events approved upstream in your CRM).

On a request that was not fanned out into a series, approval also fixes the event's dates. A request in a series carries a single proposed date by construction, so only the first branch below ever reaches one (see Submitting, tracking, and withdrawing a request).

The request carries Proposed dates, which are proposals; the event record carries a Start date and an End date, which are facts.

• Where the request proposes one date, approval takes it for both.
• Where it proposes several, the event record takes the earliest proposed date for its Start date and its End date. That choice is recorded in the trail beside the approval. It holds whatever the compliance gate did, and whether a person or auto-approval gave the approval.

Nobody is asked to name a date. An approver acting from the notification email or from the record selects Approve, or Decline with a reason. Neither action carries a date step.

Every branch above sets the Start date and the End date to the same day. Correcting the two dates on the event record therefore has two reasons, and the first is the common one. A meeting that runs over more than one day has its End date set there after approval, because approval had no second date to take. The second is a meeting that runs on one of the other proposed dates, where both dates are corrected there.

After approval the two dates are edited on the event record. The planners of the event's workspace (Manager or Editor) can edit them, and so can holders of the finance role whose scope covers the event. On a record-only event, which has no workspace, the finance-role holders edit them alone. A change is recorded with who made it and when.

Keep them current, because five things read them.

• The Reconciliation reminder starts from the passing of the event's End date, and on a cancelled event from the cancellation. It runs while the closure has not been recorded, whether or not the budget carries unreconciled cost lines, and repeats until the closure is recorded (see How to use the Budget module).
• Onomi 360's calendar classifies an event as Planned or Completed by its End date (see How to use Onomi 360: the portfolio calendar, engagement view, and reports).
• The travel step pre-fills a registrant's outbound and return dates, and the check-in and check-out dates in its accommodation section, from the event's Start date and End date. A room block's Stay window is pre-filled from the same two dates (see How to manage travel and accommodation for your event).
• A blank-cost policy reads the Budgeted column while the event is planned, and the Actual column from the End date. On a cancelled event it switches from the cancellation. Which budget flag a finance owner sees switches at that boundary (see How to use the Budget module).
• And retention runs from the closure the reminder drives toward.

Leaving a multi-day meeting on the same-day End date approval set therefore pre-fills one night on its travel step and on its room blocks. It also shows the event as Completed on the calendar while it is still running, and starts its reconciliation reminder on its first day.

A record-only event has no workspace, so it has no workspace end date either. The Start date and End date on its event record are what the reminder and the calendar read. The workspace end date that drives workspace archival is a workspace field, and a separate thing.

Tip: Ask for a single proposed date on the request categories you select for auto-approval. Nobody names a date on those requests, so a request submitted with one proposed date needs no correction on the event record afterwards. It matters most on the internal category, which is the one auto-approval ships selected and the one that carries the volume.

What happens next follows the mapping your organization set for the request's category in Policies > Event creation (see Configuring what approval creates). The mapping is what decides whether an approved request gets a workspace, and when:

• Create at Start execution, the default for the full-lifecycle categories (scientific, executive, and congress): the workspace waits until someone selects Start execution.
• Create at approval: the workspace exists as soon as the request is approved, and its first planners are added to it centrally.
• Record-only, the default for the self-service small-meeting categories (internal): no workspace at all.

Full-lifecycle events

1. In Onomi 360, open the event created from the approved request. Its request status shows Approved.
2. Select Start execution. The action sits on the event record, and who can select it follows what already exists.
   • On a category mapped to Create at Start execution there is no workspace yet, so there are no planners of it either. The action is available to holders of the finance role whose scope covers the event. That is the same assignment that carries the writes on an event record with no workspace.
   • On a category mapped to Create at approval the workspace is already there, but it opens with no team. The action reaches that workspace's planners (Manager or Editor) only once planners have been added to it centrally by an organization Admin. Until then the finance-role holders are the actors there too.

   The role registry is documented in The role model and role registry.

3. The request status moves to In execution. Where the category is mapped to Create at Start execution, the event workspace is created from the workspace template named in the mapping. Registration, communications, and the agenda then start from your standard setup rather than a blank page.

   A workspace created this way starts with a team of one: the person who selected Start execution becomes its first workspace Manager. Only a workspace Manager manages a workspace's team, so that first Manager adds the planners who will run the event.

   Where the category is mapped to Create at approval, the workspace already exists and Start execution moves the status only. That workspace is created with no team, because nobody selected an action to become its first Manager. Its first planners are added centrally by an organization Admin (see Configuring what approval creates).

4. Run registration, logistics, and on-the-day execution in the workspace. The request record in Onomi 360 keeps carrying the status and the money story, and the requester's portal view updates with it.

Record-only meetings

A meeting in a category mapped to record-only stays on its event record. No workspace is created, because the meeting itself is the execution. That is the self-service lane, and its status path is shorter than the full-lifecycle one. The event record is created on approval, as for any request. The meeting never passes through In execution, because there is no Start execution to select and no workspace to run.

The record is still reconciled and closed, in Onomi 360, on the event record itself. The finance owner reconciles each cost line with Mark reconciled, then selects Close event, which moves the record to Closed. The steps are the same as for any event and are documented in Reconciliation, invoices, and closing the event. The closure that brings an event to Closed is recorded with Close event on the budget header. That status is therefore reachable only where the budget suite is enabled for your organization. See Before you start in How to use the Budget module, and How to plan your Onomi 360 implementation for where that enablement sits in a rollout.

The meeting record and its attendees sync to your CRM through the same Veeva SpotMe Sync App connector as any event, on its Meeting record sync, outbound flow. They land as the CRM objects your organization configures. That connector is the documented route for the record-only lane. It is the mechanism behind "every meeting is still tracked in your CRM": tracking needs no planner and no workspace.

What travels is the meeting record and its attendees. The flow does not write the event's lifecycle status back. A meeting cancelled or withdrawn in Onomi 360 after its record has synced leaves the CRM record holding the state it already carries. That is a reconciliation to build into your own CRM process.

Where your organization's HCP master is Salesforce, event and attendee data syncs to Salesforce and is automatically associated with Contact and Account objects. The route that carries a record-only meeting's record and its attendees on that lane is settled with your SpotMe team during implementation. The flow itself is documented in Integration patterns: connecting Onomi to your enterprise systems.

Events approved upstream in your CRM

Where your organization approves events upstream in Veeva CRM Events Management or Veeva CRM Medical Events, the event record arrives in Onomi 360 already Approved. What it carries is what your integration mapping sends.

Map the dimension set first: the geography (country and city), the business unit, and, where your organization runs its programs along them, the therapeutic area or brand. Map the request category, the budget band and its currency, and the dates with them.

Mapping the band and its currency is a prerequisite rather than a refinement. With no request behind the event, they are what the event's approved band and its budget currency are taken from. How the budget band, the over-band flag, and the reconciliation meal cap behave on such an event is set out elsewhere. See Events approved upstream in your CRM, in Budget capture at request and working the budget during planning.

Mapping the dates is a prerequisite on the same footing. The Start date and End date they set on the event record are read by the same five readers listed under From approval to execution above. Those are the Reconciliation reminder, the calendar's Planned and Completed classification, the travel step's pre-filled dates, the column a blank-cost policy reads, and the retention clock.

An event arriving with no Start date and no End date:

• starts no reconciliation reminder;
• is classified as neither Planned nor Completed on the calendar;
• pre-fills no travel dates; and
• leaves a blank-cost policy on the record reading the Budgeted column until the dates are set.

On the record-only lane, nothing prompts the closure, because the Reconciliation reminder runs from the End date. The record is closed only when its finance owner selects Close event. Until they do, its retention clock never starts.

Two remedies are documented. The first is the rule that applies to the dates on any event record. Start date and End date are edited on the event record by the planners of its workspace, and by holders of the finance role whose scope covers it. On a record-only event the finance-role holders edit them alone. Setting the dates restores the readers that were waiting on them, the Reconciliation reminder among them.

The second is the closure itself, and it does not wait on the dates. The event's finance owner reconciles any cost lines, then records the closure with Close event. The only condition is that every cost line is reconciled. So a record whose dates were never set can still be closed, and its retention clock started (see Reconciliation, invoices, and closing the event).

Those attributes arrive through the inbound field mapping your CRM and event teams configure on the connector, not through the request form. The mapping is therefore a governance decision rather than a technical detail. Scoped visibility reads them exactly as it reads the dimensions a portal request carries. A dimension the mapping does not carry is a dimension you cannot scope, route, or report along. An event that arrives without a business unit sits outside every business-unit scope, outside every routing entry that names one, and outside every report grouped by it. The mapping is documented in Integration patterns: connecting Onomi to your enterprise systems, which is where the attributes it carries are listed.

The inbound mapping carries the event's own attributes and no attendee list. The attendees of an event that arrives this way are added on the event record after it arrives. Where the category is record-only, they are added with Add attendee, one at a time, by a holder of the finance role whose scope covers the event. Where the category creates a workspace, they arrive through the workspace's registration paths.

An event created from an arrival is listed under All requests in Event requests, as a row of its own at status Approved. The row carries its upstream reference and its arrival timestamp, in place of a submitted request and an in-platform approval trail. The approval trail stays in the CRM, while the compliance gate and pre-approval statuses govern the portal lane only. An export from All requests carries the upstream reference and arrival timestamp, which lets one audit extract cover both lanes.

The row is reached by the request-status filter at Approved and by the category and date-range filters. It is not reached by the Over meal cap filter, because that indicator is never written here. It never appears under Awaiting compliance review, because the gate does not evaluate it. An arrival that never created an event is not in this list at all: it is read in the Held arrivals view described below.

Governance runs upstream for these events, so the controls that evaluate a submitted request do not run on them. Those controls are the approval rules, the compliance gate, and auto-approval. Neither does the request-time hospitality check, because there is no request carrying Estimated hospitality per person. The Hospitality over market meal cap condition has nothing to evaluate, and the Over meal cap indicator is never written. The hospitality control that does act on these events is the reconciliation check on real spend. It raises the Meal cap exceeded flag on the event's budget (see How to use the Budget module).

The controls that act on the record do run, because the record is here. The venue rules of the market on the record act on the venue that record carries. An approved venue list flags an off-list venue, and Require listed venues refuses it. The result reads on that venue's entry on the event record, as on any other event.

The venue-type and entertainment restrictions reach less far on this lane. They are evaluated against the venue type the sourcing network holds, so they block a venue sourced from the network. A venue that is not sourced reaches the record here with Add venue, as free text or from the market's approved venue list. It carries no venue type for the rule to read. No type block runs on that path, so the market's restriction is applied by the people recording the venue.

Your budget policies and their locks act on the budget as usual, and transfer-of-value allocation runs from the budget actuals. See Setting venue rules in Onomi 360 and How to use the Budget module.

What approval creates is decided here rather than upstream, and on the same key as for a portal request. The Event creation mapping in Policies is keyed on the request category, and the request category is one of the attributes the inbound field mapping carries. An arriving event therefore follows the mapping of its category exactly as an approved portal request does. That is a workspace created at approval, a workspace created when someone selects Start execution, or record-only with no workspace.

That key carries a prerequisite. The category value the connector sends has to resolve to one of your active request categories. The connector's inbound field mapping is configured by your CRM team rather than by the request form. So a record can arrive carrying a category value that matches no active category: a value that was retired, renamed, or never mapped among them. The arrival then fails rather than guessing. No event record is created, the arrival is held, and the connector's response names the value that failed to resolve. The failure is visible on both sides, instead of landing as a silently miscategorized event.

Held arrivals have their own place to be read, and your organization administrators are the people who read it. In Onomi 360, they open Event requests and select Held arrivals. That separate view lists the arrivals the connector could not create, rather than requests.

Each row shows the value that failed to resolve and the field it arrived in. It also shows the reference of the source CRM record and the arrival timestamp. These rows are not requests and carry no request status. The filters by request status, category, and date range do not reach them, so the view is where they are read. A held arrival is kept for 30 days and is then discarded.

To recover one, correct the connector's inbound field mapping, or add the category with Add category on the Request form tab. Then have your CRM send the record again. The arriving record creates the event as it should have the first time, and the held row clears. Adding it is the route whether the category never existed or was retired.

Review the mapping the added category arrives with before you have the record sent again. A category added with Add category arrives on the Event creation tab mapped to Create at Start execution from your default workspace template. Check that this is the behavior the upstream events in that category need, and change it on the Event creation tab where it is not. The self-service lane usually needs record-only rather than a workspace-creating mapping. A category added this way counts against your 12 active categories.

A row your organization administrators do not intend to recover is dismissed by them, and the reason they give is recorded on the dismissal.

Where the category does resolve, the Event creation tab carries a mapping for it, because it carries one mapping per active category. Where the category is mapped to record-only, the consequence is the one the In execution status definition states, in How to set up and use meeting requests and approvals. The event never passes through In execution, because there is no Start execution to select and no workspace to run. It is reconciled and closed on its event record with Mark reconciled and Close event, as for any record-only meeting. See Configuring what approval creates.

Cancelling an event

Once a request is Approved or In execution, it is cancelled rather than withdrawn, because money and logistics may already be attached. Withdrawing a request before its approval completes is covered in Submitting, tracking, and withdrawing a request.

1. In Onomi 360, open the event and select Cancel event. A cancellation reason is required, and the action asks you to confirm. Cancellation is available to the event's finance owner, and to the other holders of the finance role whose scope covers the event. Those are the same holders who close an event (see How to use the Budget module). Anyone else sees the control disabled with a message naming the required role: "You do not have permission to cancel this event. Cancellation is available to the event's finance owner and to holders of the finance role whose scope covers this event."
2. The status moves to Cancelled, and the record shows who cancelled it, when, and why. The Event cancelled notification goes to the approvers who approved the request, the event's finance owner, and the planners of the workspace.

Cancellation touches the connected modules; nothing is deleted:

• Budget. Budgeted and committed amounts stay on the record. Cancellation and no-show costs are captured as actuals through reconciliation, and a cancelled event reconciles and closes its money the same way as a delivered one. Closing the money on a cancelled event closes its budget lines without changing the status, so reporting and audit filters keep the cancellation.

  That closure is recorded with Close event on the budget header, as the closure that brings an event to Closed is. It is therefore available only where the budget suite is enabled for your organization (see Before you start in How to use the Budget module).

• Sourcing. Active RFPs are closed toward the venues. Awarded bookings move to cancellation under the terms of the award, with any cancellation fees landing in the budget as actuals. See How to source a venue from your event.
• Travel. Booked travel and accommodation are cancelled through the processes that booked them. The travel records on the event are marked cancelled, and any fees are captured as actuals. See How to manage travel and accommodation for your event.
• Registration. Registrants on a full-lifecycle event are informed through the workspace's standard communications, and registrant-level statuses are handled in the workspace.
• Audit. The cancelled record keeps everything: the request, its approvals, the cancellation with who, when, and why, and every cost incurred.

Following and auditing requests

1. In Onomi 360, open Event requests. It opens on My tasks, your personal queue of request work. Approvers see requests waiting in My approvals. Compliance reviewers see the shared approvals routed to them in My compliance reviews. Organization administrators see escalations and routing failures that require administrative action. When one person completes a shared approval, it leaves every other recipient's queue.
2. To follow or audit requests beyond your own queue, select All requests. It lists every submitted request and upstream-approved event inside your role scope. A Draft request stays with its requester and is not listed. An arrival that never created an event is listed separately under Held arrivals for organization administrators.
3. Use the filters to build the view you need, for example by request status, category, or date range. The request-status filter offers the statuses a submitted request carries, and Draft is not among them. The view keeps your column layout and sort order between visits.
4. Open any record to read its story end to end. It carries the "why this approver" trace showing which rule produced the routing, the auto-approval rule trace where one fired, decline reasons, and comments. Every request, approval, decline, and status change is logged with who acted, when, and why.
5. Select Export. A spreadsheet file downloads with the records in view and their logged events, ready for an audit review. One export covers up to 10,000 records. A larger run is refused rather than quietly cut short: the export stops with "This export exceeds 10,000 records. Narrow the filters, then export again." For a full-year or multi-country audit extract, run the export in narrowed passes, by period, geography, or business unit, and combine the files. This export covers both lanes, including record-only meetings that the Analytics API does not address.

Note: My tasks is always personal. All requests follows the scope on the user's role assignment: a role scoped to a geography or business unit sees the requests inside that scope, while organization-wide oversight roles see every request. Requesters always see their own submissions in the portal, whatever scope they hold.

Organization administrators hold organization-wide visibility under All requests, for administration only. They open an escalated or stalled request, and reassign a pending approval to another holder of the required role. They also re-route a request that could not be routed. Administrator access carries no approval right and no module write of its own. The scope model, and the administrator clause with it, are documented in Role-based access and visibility for internal and external stakeholders.

The trail covers both lanes: a self-service meeting that auto-approved under policy is as traceable as a logistics-heavy program with a full approval chain. Once delivery starts, planners also reach the same record from the event side. In Onomi 360, open the event and select the Request module to open the linked request record.

For what this module does and where its boundaries are, see How to set up and use meeting requests and approvals.

* Onomi 360 MeetingsEQ exclusive capabilities.