Submitting, tracking, and withdrawing a request

This guide is the requester's. It covers submitting a meeting request in the meeting request portal. It also covers tracking the request through the lifecycle, and withdrawing it when the meeting is no longer needed. The module gives each role its own view of the same records, and this is the first of the three. My requests in the portal is your own submissions. It shows the request status beside the registration status of the event an approval creates. My approvals in Event requests is the approver's personal queue, and My compliance reviews is the compliance reviewer's personal queue. Both are covered in Approving requests and working your review queue.

Submitting a request

Meeting request and intake. Requesters work in the meeting request portal, a lightweight web portal reachable by link and SSO. No workspace access is needed, and occasional requesters submit on the no-license tier. This section is the intake half of the suite. The approval and workflow half is covered in Approving requests and working your review queue, and in From approval to execution and auditing requests.

1. Open the meeting request portal from the link your organization shares and sign in with your usual company credentials (SSO). The portal opens on your My requests list, which shows every request you have made and its current status.
2. Select New request.
3. Choose the request category: internal, scientific, executive, or congress (your organization may have renamed these or added its own). The form adapts to your choice, presenting the field set for that category.
4. For a recurring meeting, select Duplicate last event instead, then pick the earlier event or request to copy. A pre-filled copy opens with fields, content, and configuration carried forward; adjust the dates and anything that changed.

   Selecting Duplicate last event is what puts the request in the series branch, and it is the only thing that does. On the copy it opens, Proposed dates states that each date entered creates a separate request, and shows how many the submission will create. Several dates here fan the request out into a multi-date series, rather than offering alternatives.

   At submission the series becomes one request per date. Each carries a single proposed date, each is routed and approved on its own, and each produces one linked event record. From there each one is an ordinary request, so it is cancelled, reported, and exported like any other. To offer alternative dates instead, start from New request, where several proposed dates are alternatives the approval resolves.

   Where a single date on a duplicated request does not hold, it is corrected on one of two documented routes:

   • While the request is still in approval. The routed approver declines it with a reason. That reopens it for editing and re-entry into routing under the rules in force at resubmission, carrying its prior comments forward (see the Note on a submitted request below).
   • Once it is approved. The event record's Start date and End date are edited on the 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 the finance-role holders edit them alone (see From approval to execution and auditing requests).

   

5. Complete the form. Required fields are marked. You can leave at any point: the request stays in your My requests list with status Draft, visible only to you and editable until you submit.
6. Select Submit. The request moves to Submitted while routing is computed, then to In review. The record shows a "why this approver" trace, naming the rule that routed it and who reviews it next.
7. Track the request from your My requests list as it moves through the lifecycle: In review while approvals progress, then Approved or Declined. In execution follows once delivery starts, and Closed after the event wraps up.

   The same record also carries the registration status of the resulting event, as a separate field. So "where is my request" and "how is my event doing" have the same answer in the same place. Where the request has produced an event, the row carries Open event, which opens that event record in one step. The same control sits on the request record itself. A request in a category mapped to record-only has no workspace, and therefore no registration journey. That field stays empty, and the request status is the whole of what you follow.

Note: A low-risk request can approve itself. If it meets the auto-approval conditions, it moves straight to Approved and the record shows which rule fired.

Restaurant meetings. A restaurant meeting captures its venue on the request. Enter the restaurant in the Venue field, as free text or from your market's approved venue list, then give the Estimated hospitality per person. What the field offers depends on your market's venue rules.

Where your organization has switched on Centralized selection for the market, the field offers that market's approved venue list and no free text. You pick the restaurant from that list. Where Require listed venues is on instead, an off-list restaurant is blocked, and the request cannot be submitted with it. Pick a listed restaurant, or ask an organization administrator to add this one to the market's approved venue list and pick it once it is there.

The venue-type and entertainment restrictions are evaluated against the venue type the sourcing network holds. They block at shortlisting and when an award returns to the event record. A restaurant entered as free text, or picked from a row of the market's approved venue list, carries no type for them to read. There, the market's restriction is applied by the people recording the venue. Approved lists and meal caps flag.

The estimate is checked against your market meal cap at request time, as the named condition Hospitality over market meal cap, which your approval rules and the compliance gate can both use. An estimate over the cap writes an Over meal cap indicator on the request, shown on the record and filterable in Event requests for the approvers, compliance reviewers, and administrators who work it. The same cap is checked again against actuals at reconciliation. Going over it there raises the Meal cap exceeded flag on the event's budget (see How to use the Budget module). Restaurants are not sourced through the sourcing flow; see How to source a venue from your event.

Note: The portal renders in the platform's built-in interface languages, plus any languages your administrators add. It follows your browser language, with fallback to your organization's default language. For language coverage across the platform, see Running multilingual events across global markets.

Note: The portal also offers AI-assisted request creation, available since the 2026.01 release. It is a conversational intake that fills the form for you and suggests dates with the trade-offs explained. A request created that way is the same request, routed and audited under the rules this series documents. See How to use AI assistance in Onomi 360.

Note: A submitted request is with its approvers and is no longer editable from the portal. If the meeting is no longer needed, withdraw the request (see Withdrawing a request and cancelling an event). If something material changes, ask the routed approver to decline it with a reason.

A declined request reopens for editing and re-enters routing under the rules in force at resubmission, carrying its prior comments forward. If your request is declined, the decline reason is shown on the record. Edit the request and resubmit. The earlier comments stay on the record, so no context is lost between rounds.

Withdrawing a request and cancelling an event

A request is withdrawn before its approval completes, and an approved or in-execution event is cancelled. Neither route deletes the record or its trail. Withdrawing is covered below. Cancelling an event is worked on the event record, and is covered in From approval to execution and auditing requests.

Withdrawing a request

While a request is Draft, Submitted, or In review, the requester can withdraw it.

1. In the portal, open the request from My requests and select Withdraw. A withdrawal reason is required.
2. The status moves to Withdrawn, pending approvals leave the approvers' queues, and the Request withdrawn notification tells the approvers and any compliance reviewers holding it. The withdrawal reason is shown on the request record beside its status as well as in the trail. The record stays in your history and in the Event requests with its full trail.

A withdrawn request's record and trail are kept under your organization's retention configuration for requests and approvals. The period runs from the withdrawal date. A request that never reached a decision is retained on the same terms as one that did.

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.