From approval to execution and auditing requests

Approval creates an event record and links it to the request. The request category determines whether the event also receives a workspace, and when that workspace is created.

This guide covers event creation, event dates, full-lifecycle and record-only execution, events approved upstream in a CRM, cancellation, and audit access.

Configure what approval creates

1. In Onomi 360, open Policies > Event creation. You see one mapping for each active request category.
2. Open a category mapping and select its Workspace behavior:
   • Create at Start execution creates the event record at approval and waits to create the workspace until an authorized person selects Start execution.
   • Create at approval creates the event record and workspace together.
   • Record-only creates the event record without a workspace.
3. For a workspace-creating option, choose the organization workspace template, then select Save.

The mapping applies to requests approved after the change. A request submitted under a category that is later retired keeps the category's mapping at retirement.

Choose the workspace behavior

Use Create at Start execution when the delivery team should decide when workspace work begins. The holder of the finance role who selects the action becomes the workspace's first Manager and can add the rest of the team.

Use Create at approval when every approved request in the category needs a workspace immediately. The workspace starts with no team, so an organization Admin adds its first planners centrally before they can work in it.

Use Record-only for meetings that need an approved event and financial record but no registration, agenda, communications, or workspace team.

The selected template fixes the starting configuration and the region in which the workspace data is created. Settle template regions with your SpotMe team before using automatic workspace creation; see Data residency.

Check the event dates created at approval

For a request with one proposed date, approval uses it as both the event's Start date and End date. For several alternatives, approval initially uses the earliest proposed date for both fields and records that choice in the trail.

Correct the dates on the event record if the meeting lasts several days or another proposed date was chosen. Workspace Managers and Editors can edit them, as can holders of the finance role whose scope covers the event. On a record-only event, only the finance-role holders can edit them.

Keep the dates current because they control:

• Planned and Completed placement on the portfolio calendar;
• default travel and room-block dates;
• the start of reconciliation reminders;
• which lifecycle column a blank-cost policy checks; and
• retention behavior that depends on closure.

An event without dates appears in neither Planned nor Completed, supplies no travel defaults, and starts no date-based reconciliation reminder. The finance owner can still close it after every cost line is reconciled, but setting the dates restores the missing date-based behavior.

Start a full-lifecycle event

1. Open the event created from the approved request.
2. Select Start execution.

   For Create at Start execution, a holder of the finance role with the event in scope selects the action and becomes the workspace's first Manager. For Create at approval, a workspace Manager or Editor can select it after an organization Admin has added the first planners; finance-role holders with the event in scope can also act.

3. The request moves to In execution. If the workspace did not yet exist, Onomi creates it from the template in the category mapping.
4. Run registration, logistics, communications, and delivery in the workspace. The linked request continues to show status and approval history in Onomi 360 and in the requester's portal view.

Role boundaries are listed in Onomi 360 roles, permissions, and scope.

Work with a record-only meeting

A record-only meeting never receives a workspace and never enters In execution because there is no Start execution action. Its event record is created at approval and remains the working record.

The finance owner works its cost lines, marks each one reconciled, and selects Close event. The Budget suite must be enabled because the finance owner, reconciliation controls, and closure action are on the budget header. See Reconciliation, invoices, and closing the event.

Attendees can be added directly to the record by a holder of the finance role with the event in scope. Event and attendee records can synchronize to the configured CRM, but a later cancellation or closure status is sent only if the agreed connector contract includes it. See Connecting CRM, HCP identity, and consent.

Handle events approved upstream in a CRM

An event approved in Veeva or Salesforce can arrive in Onomi 360 already Approved. It has no portal request or Onomi approval trail, so the integration mapping must supply the attributes the downstream record needs.

Map the required attributes

Map the upstream reference, request category, start and end dates, budget band and currency, geography, business unit, and any therapeutic area or brand used for scope or reporting. A missing dimension cannot be used to route, scope, or group the event.

The inbound event does not bring an attendee list through the request form. Add attendees on a record-only event, or collect them through workspace registration when the category creates a workspace.

The arrival appears under All requests at Approved with its upstream reference and arrival timestamp. The approval history remains in the CRM.

Know which controls do not run

Request approval rules, the compliance gate, auto-approval, and the request-time hospitality check do not run because no portal request was submitted. The event therefore receives no request-time Over meal cap indicator.

Record-level controls still run. Budget policies act on the event budget, reconciliation can raise Meal cap exceeded, and market venue rules act when a venue is added or returned from sourcing.

Resolve the category before event creation

The inbound request-category value selects the same Event creation mapping used by a portal request. It can create a workspace at approval, wait for Start execution, or keep the event record-only.

If the value matches no active category, Onomi creates no event and puts the arrival under Event requests > Held arrivals. The row names the source record, arrival time, field, and value that did not resolve.

Correct the connector mapping or add the required category, verify its event-creation behavior, then send the CRM record again. Held arrivals are retained for 30 days; an administrator can dismiss an arrival that should not be recovered and record the reason.

The complete inbound contract is described in Connecting CRM, HCP identity, and consent.

Cancel an event

Once a request is Approved or In execution, cancel the event instead of withdrawing the request.

1. Open the event and select Cancel event. The event's finance owner and other holders of the finance role with the event in scope can use the action.
2. Enter a cancellation reason and confirm. The event moves to Cancelled, and the record stores who cancelled it, when, and why.

Cancellation preserves the record and its audit history:

• Budgeted and committed amounts remain. Cancellation and no-show charges are captured as actuals and reconciled before the finance owner records closure.
• Active sourcing requests are closed with venues. Awarded bookings follow their cancellation terms, and any fee lands in the budget.
• Travel and accommodation are cancelled through the processes that booked them, with fees recorded as actuals.
• Registrants on a full-lifecycle event are informed through the workspace's communication process.

See How to source a venue from your event, How to manage travel and accommodation for your event, and How to use the Budget module.

Follow and audit requests

1. Open Event requests. My tasks shows the current user's approval, compliance, or administrative work.
2. Select All requests to see submitted requests and upstream-approved events within the scope of the user's role assignment. Drafts remain visible only to their requester, and failed CRM arrivals remain under Held arrivals.
3. Filter by status, category, dates, or the program dimensions available to the role.
4. Open a record to read its routing explanation, decisions, decline reasons, comments, and status history. Each logged action records the actor and time.
5. Select Export to download the filtered audit population. One export can contain up to 10,000 records; narrow larger populations by period, geography, or business unit and export them in separate runs.

Note: My tasks is personal. All requests follows the scope of the user's role assignment, while requesters can always see their own submissions in the portal.

Organization administrators have organization-wide administrative visibility. They can reassign a stalled approval to another holder of the required role or reroute a request that could not be routed, but administrator access alone does not grant approval or module-edit permission.

For the overall request lifecycle, see How to set up and use meeting requests and approvals.

* Onomi 360 MeetingsEQ exclusive capabilities.