How to set up and use meeting requests and approvals

Onomi 360's request and approval suite gives your organization one front door for every meeting and event request. It computes approval routing rather than hard-coding it. The record explains every decision. The suite spans two capability areas. Meeting request and intake is the front door and the form behind it. Approval and workflow is the routing, gates, and notifications that govern what was asked for.

This overview covers the roles in the flow, the two lanes, the request lifecycle, and what to have in place before you configure the module. The guides in this series, mapped below, cover setup in Onomi 360 and the requester flow in the meeting request portal (meeting request and intake). They also cover the approver and compliance reviewer flows (approval and workflow), and how to follow and audit requests across your organization.

Overview

The roles in the flow

Five roles meet in this flow. Requesters submit and track meeting requests in the meeting request portal. Approvers receive routed requests and act on them, from the notification email or from My approvals in Event requests in Onomi 360. Compliance reviewers handle the separate compliance approval that fires when healthcare professional (HCP) or public-official attendees are present. They work it from My compliance reviews in the same area. Administrators configure the form, routing rules, and notifications. Planners pick up approved requests as they move into execution.

The two lanes

The self-service lane covers the low-complexity majority of your meetings. The volume it carries is submission volume, and the portal takes requests at that scale. Occasional requesters submit, track, and withdraw their own small meetings on a no-license tier, without workspace access or a full license. The workflow is simplified, and policy is enforced automatically: low-risk requests approve themselves. Every meeting is still tracked in your CRM, through the same Veeva SpotMe Sync App connector as any event. It travels on that connector's Meeting record sync, outbound flow (see From approval to execution and auditing requests).

Your organization configures which requests run in this lane. It maps each request category to what approval creates. The categories mapped to record-only run without a workspace (see Configuring what approval creates in From approval to execution and auditing requests).

What follows the meeting is not requester work, and it is worked one record at a time. On a record-only meeting, a holder of the finance role whose scope covers the event works the event record. They add each attendee with Add attendee, and set the Show and No-show state. The save on Add attendee is what submits an attendee to identity resolution. Both are described in How to manage transfer of value on your events. The event's named finance owner reconciles its cost lines and closes the record, as described in How to use the Budget module.

Where a row comes back unresolved, that guide publishes two routes. First, confirm that resolution against your HCP master is configured for your program. Contact your SpotMe Account Manager where resolution is not yet set up. The second route applies when an individual cost line rests on that attendee and blocks confirmation. Exclude the line with Exclude line and record a reason. The event's finance owner holds Exclude line.

Name that finance owner on each record-only event as the record is created. The Finance owner field has no default, and nobody holds it until someone is named. Plan the lane on both halves: the requests that arrive through the portal, and the records your finance-role holders work afterwards.

The full-lifecycle lane picks up where logistics begin. The same request record flows into approval routing, registration, budget, and execution. A compliance-heavy program with venues, HCP travel, and layered approvals therefore uses the same front door and data model as a small self-service meeting.

The request lifecycle

Every request moves through the same request lifecycle statuses, and the record carries dual status tracking. The lifecycle statuses are one field on the record, the request status. The registration status of the resulting event is a separate field alongside it. Both are visible in the requester's history. A setting that reads a status therefore says which of the two it reads. For example, the Reconciliation reminder in How to use the Budget module runs from a date on the event record. It does not read a request status.

A request in a category mapped to record-only produces no registration journey, because no workspace is created for it. The registration status field on that record stays empty, and the request status is the whole of what the requester follows. The self-service small-meeting categories ship mapped to record-only, so that is the normal state on most records rather than a fault.

• Draft: saved in the portal but not submitted. Visible only to the requester, and editable. Nothing on a Draft request opens to anyone else.
• Submitted: the pre-routing state. The request has left the requester and routing is being computed.
• In review: the request has been routed, and at least one required approval, budget or compliance, is still outstanding. That holds whether or not an approver has acted yet. Routing is what separates the two states. A request is Submitted until routing completes, and In review from then until the last required approval is in place. The first approver is notified as the request enters In review.
• Approved: every required approval, budget and compliance alike, is in place.
• Declined: an approver declined with a reason; the requester can edit and resubmit. A resubmitted request is checked against the current values of its fields, so a retired category has to be re-selected before it can be resubmitted.
• In execution: Start execution has been selected on the approved event and delivery has started. The action sits on the event record, and is available to holders of the finance role whose scope covers the event. Where the category is mapped to Create at approval, a workspace already exists. Its planners (Manager or Editor) can use the action once planners have been added centrally. Until then, a holder of the finance role whose scope covers the event acts there. See From approval to execution and auditing requests. Requests in categories mapped to record-only never pass through this status, because there is no workspace to start.
• Closed: the event has wrapped up and the record is complete.
• Withdrawn: the requester withdrew the request before approval completed. The record and its trail are kept.
• Cancelled: an approved or in-execution event was cancelled. The record keeps its full trail, and any costs already incurred reconcile on the cancelled record. Cancelled is the final value of the request status. Cancelled is terminal, so Close event on a cancelled event closes its budget lines and records the closure without changing the status, and reporting and audit filters keep the cancellation.

Note: Approval does not have to run in Onomi 360. Your governance model may approve events upstream in Veeva CRM Events Management or Veeva CRM Medical Events. The approved event record then flows to Onomi 360 for execution. It arrives already Approved and linked to its upstream reference. Event requests shows its origin.

In that posture the routing rules, the compliance gate, and auto-approval do not evaluate the request, because governance runs upstream. The lifecycle continues from Approved to Closed, passing through In execution where the category creates a workspace. Registration statuses and engagement write back to the CRM record, on the events backed by a workspace with a registration journey. The audit trail records the upstream origin and everything that happens from arrival onward.

An upstream event whose category is record-only has no workspace, and therefore no registration journey, so it has no registration status to write back. Its meeting record and its attendees reach the CRM on the Meeting record sync, outbound flow, as they do on any record-only meeting. For upstream-approved events, the approval trail stays in Veeva. The Event requests queue, compliance gate, and pre-approval statuses govern only the portal lane.

Events approved upstream in your CRM documents what such a record carries and which controls still act on it. Find that section in From approval to execution and auditing requests. See also Integration patterns: connecting Onomi to your enterprise systems.

Before you start

Check the following before you configure the module:

• Administrator access. Configuration lives in Onomi 360, in Event requests and Policies areas, and requires organization administrator access. Workspace-level access is not enough.
• Module enablement. The request and approval suite is enabled per organization. If you do not see the Event requests in Onomi 360, please contact your SpotMe Account Manager.
• Single sign-on (SSO). Requesters reach the meeting request portal by link and sign in with your organization's SSO. No workspace access or license is needed.
• People to name. Have your approvers and compliance reviewers ready. First, grant them the Approver and Compliance reviewer roles in Onomi 360 under Users and roles. Only role holders can be named in an approval level, the default reviewer list, or a routing entry. Every approval rule names an approver per level, and the compliance gate needs at least one reviewer before triggered requests can complete review.
• Rollout. To plan a phased rollout for your organization, please contact your SpotMe Account Manager.

Setting up requests and approvals in Onomi 360

Configuration is organization-level, and it follows the suite's rule of configuration, not code. Fields, thresholds, labels, routing rules, and notification recipients are edits your administrators make themselves, never development requests. The configuration work falls into the suite's two capability areas, and the guides in this series carry it. Meeting request and intake is configured on the Request form tab (Configuring the request form and its categories). Approval and workflow is configured in Policies. See Configuring approval routing, the compliance gate, and auto-approval. See also Configuring notifications for requests and approvals. Configuring what approval creates is in From approval to execution and auditing requests. Changes apply to requests submitted after you save them.

The guides in this series

The meeting request and approval guides split the module by task, and each of them assumes the module introduction above.

• Configuring the request form and its categories covers the Request form tab and category-branched field sets. It explains the core fields, what reads them, and the category lifecycle (adding, retiring, renaming, and portal availability).
• Configuring approval routing, the compliance gate, and auto-approval covers approval rules and their levels. It explains the additive compliance gate, its routing entries and auto-clearance rules, auto-approval, and end-to-end verification.
• Configuring notifications for requests and approvals: the lifecycle templates and their triggers, per-language maintenance, the reminder cadence and escalation, and action-link validity.
• Submitting, tracking, and withdrawing a request covers the requester flow in the meeting request portal. It includes duplicating a recurring meeting, tracking request and registration statuses, and withdrawing a request.
• Approving requests and working your review queue covers action from a notification email or Event requests. It includes My approvals, My compliance reviews, delegation, reassignment, and escalation.
• From approval to execution and auditing requests explains what approval creates per request category and how event dates work. It also covers record-only meetings, events approved upstream in your CRM, cancellation, and organization-wide request tracking and audit.

For what the module does and where its boundaries are, see the Meeting requests and approvals release notes.

* Onomi 360 MeetingsEQ exclusive capabilities.