Configuring the request form and its categories

The meeting request form and its categories are configured on the Request form tab of Event requests in Onomi 360. This guide covers that tab: the categories requesters choose from, the fields each category asks, what else reads those fields, and the category lifecycle. The approval settings that read what the form collects are configured in Policies; see Configuring approval routing, the compliance gate, and auto-approval.

The meeting request form is one standardized front door. Behind it sit category-branched request forms: the form adapts by request category, driving different fields and approval paths from one entry point.

1. In Onomi 360, open Event requests. As an organization administrator, select All requests to see requests across the organization.
2. Open the Request form tab. The portal address your requesters will use is shown at the top of the tab; share it through your usual internal channels. Below it, your request categories are listed. A new organization starts with four: internal, scientific, executive, and congress.

   

3. Select a category to open its field set. Each category presents its own selection and ordering of fields from a shared library, so a congress request asks different questions than an internal meeting.

   

4. Review each field in the set. For every field you can edit the Label, switch Required on or off, and drag the field to reorder it. The Label is the wording requesters see. On the dimension fields (Business unit, Therapeutic area, and Brand) you can also set a preset value for the category. A preset means the requester is not asked for something the category already determines.

   Weigh Required on the fields the rest of your configuration reads. A field left optional and unanswered reads to the settings that use it as a removed one does (see step 6). Switch it off on Budget band, and an event record created from a request that left it blank carries no approved band and no budget currency. That holds until the band is set afterwards on that event's budget header. The first band selection on a header carrying no band and no budget currency offers every band your organization has defined, in every currency. It sets the approved band and the budget currency together. See Where a budget header carries no band and no budget currency in Budget capture at request and working the budget during planning. That section also publishes the message a planner reads on trying to add a cost line to a header in that state.

   Switching it off on Proposed dates reads the same way on the dates lane. Approval has no date to take. The event record created from a request that left it blank carries no Start date and no End date until they are set on the record. Until they are, a blank-cost policy on that record reads the Budgeted column (see step 6).

   The core fields are:

   • Requester: who is requesting the meeting. Prefilled from the requester's SSO sign-in.
   • Event title: free text. Required by default.
   • Format: in person, virtual, or hybrid.
   • Proposed dates: one or more dates with a timezone. Several dates are alternatives, and the approval resolves them. One of them becomes the event record's Start date and End date (see From approval to execution and auditing requests). The event record's dates are taken from this field and from nothing else on the portal lane, so keep it required (see step 6). A request started with Duplicate last event is the one exception. There, several dates fan the request out into a series of one request per date. Each carries a single proposed date of its own (see Submitting, tracking, and withdrawing a request).
   • Country and city: where the meeting takes place. This is the geography the request carries.
   • Business unit: the business unit or division the meeting belongs to. The requester selects it from the list your organization administrators maintain in Onomi 360 > Policies > Dimensions (see Role-based access and visibility for internal and external stakeholders). Where a category always belongs to one unit, preset it for the category instead.
   • Therapeutic area and Brand: where your organization runs its program along them. The requester selects them from your configured lists, maintained on the same Dimensions page (see Role-based access and visibility for internal and external stakeholders). They can also be preset for the category, in the same way. Leave them out of a category's field set where they do not apply.
   • Venue: for a restaurant or another meeting whose venue is chosen directly rather than sourced, the venue is captured on the request itself. Enter it as free text, or pick it from your market's approved venue list where one exists.

     What the requester can enter depends on the venue rules your organization sets for that market. Each rule either flags or blocks:

     • An approved venue list flags an off-list venue by default.
     • Require listed venues blocks an off-list venue.
     • Centralized selection makes the market's approved list the selectable set, so the field offers that list and no free text.
     • Market meal caps flag rather than block.

     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 venue entered as free text on this field, 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. See Setting venue rules in Onomi 360.

     Two of the settings above decide what a requester can do with an off-list venue, and they combine in four ways:

     • Both off (the default). Enter the venue as free text and submit. The off-list choice is flagged on the record for review, and the request goes forward.
     • Require listed venues on, centralized selection off. The venue can be typed in, and it is then blocked, with the market named in the message: "This venue is not on the approved venue list for France. Select a listed venue." The request cannot be submitted with that venue. Select a listed venue instead, or ask an organization administrator to add this one to the market's approved venue list and select it once it is there.
     • Both on. The Venue field offers the approved list only, so the off-list venue cannot be typed in at all, and the same block applies to it everywhere else in the market. Ask an organization administrator to add the venue to the market's approved venue list, then select it.
     • Centralized selection on, Require listed venues off. The field offers the approved list only, so the off-list venue cannot be entered on the request. Ask an organization administrator to add the venue to the market's approved venue list, then select it.

     The rules and the four branches are documented in Setting venue rules in Onomi 360.

     The venue rule reads on the request as well. On a request that captures a restaurant or another venue directly, the venue reads on the request from submission. So does the result of the market's venue rules, Passed or Refused against the market's approved venue list. The compliance reviewer holding the gate on that request reads both, while the request is In review and with them at the gate.

     No reviewer sets that result and no reviewer decides it: it follows from the rules your organization configured for the market. A Draft request is visible only to its requester and editable by them alone. Its venue reaches nobody else until the request is submitted.

     The venue rule result carries onto the event record's venue entry once approval creates the event. An event that arrives already approved from your CRM has no request form and no Venue field, so none of the four branches above applies. The record-level venue rules still act on the venue that record carries. The market's approved venue list flags an off-list venue, and Require listed venues refuses one. The result reads on the event's venue entry. What runs on such an event, and what does not, is set out in Events approved upstream in your CRM in From approval to execution and auditing requests.

   • Estimated hospitality per person: the estimated food and beverage spend per person.

     Read the figure on one basis. It is the estimated hospitality per disclosable attendee for the whole meeting, compared with the market's meal cap. That cap is a per-event per-person limit. It does not express a per-meal or per-day policy.

     The figure is entered in the currency the request carries from its Budget band, and that is the currency the comparison reads. Both checks compare in the market's currency, and nothing is converted. So a request carrying a different currency is not compared with the cap. Nor is a request carrying no band, and therefore no currency at all (see step 6).

     This per-person estimate is the one figure evaluated against your market meal cap. The comparison is exposed as one named condition, Hospitality over market meal cap, and it reaches three places:

     • Approval routing. A rule can carry the condition.
     • The compliance gate. The condition can be a trigger condition, and its under-cap counterpart an auto-clearance condition. Both are configured in Configuring approval routing, the compliance gate, and auto-approval.
     • The record itself. An estimate over the cap writes an Over meal cap indicator on the request.

     The indicator is shown on the request record and is a filter in Event requests, so routed approvers and compliance reviewers see it in their personal queues, and administrators see it under All requests.

   • Expected attendees: an attendance band rather than an exact count.
   • HCP attendees: whether HCP or public-official attendees will be present, and in which band. This field triggers the compliance gate and is an axis in approval routing, so keep it required.
   • Speakers or honoraria: whether the meeting involves external speakers or any honorarium. Defaults to no. It is a condition compliance auto-clearance rules read, so keep it required in the categories where you use auto-clearance.
   • Budget band: the budget band for the meeting and the currency it is requested in. The bands offered are the ones defined for that currency, and the band is an axis in approval routing and in auto-approval. The bands come from the budget suite's per-currency band sets, so until those band sets are defined the field offers nothing, a band condition on an approval rule cannot match, and auto-approval cannot fire. Bands are defined in Setting up budgets: categories, bands, and policies.
   • Objectives: free text describing what the meeting is for.
5. Optionally, add a field to the set. Select Add a field, choose the field from the shared library, then set its Label, switch Required on or off, and drag it into position. The field is asked from the next time a requester opens the form.

   One library field carries the faculty selection: Faculty. It lists the speakers your organization holds records for. Beside each one it shows their eligibility status and their Engagements count, the engagements that speaker already carries. A speaker whose eligibility status is Not eligible cannot be selected on the request, and the form says so. Add the field to every category whose meetings involve external speakers, the Speaker program and Symposium categories among them.

   The eligibility status itself is held on the speaker's own record and comes from your speaker qualification process. The field displays it and acts on it rather than setting it. See How to run a speaker program.

6. Optionally, remove a field from the set. Select the field, then select Remove. The field is no longer asked, and requests already submitted keep the value they carried, on the record, in Event requests, and in exports.

   Check what else reads the field before you remove it. A named set of settings and records reads one:

   • a trigger condition on the compliance gate;
   • a condition on an approval rule, and auto-approval;
   • a condition on a compliance auto-clearance rule;
   • the budget of the event the request creates; and
   • the event record's Start date and End date, which approval fixes from Proposed dates.

   Further readers sit behind the dimension fields: the compliance gate's routing entries, the scopes on strategic meetings management role assignments, and the program-layer filters and reports. The Note after step 11 sets those out. Behind Venue sit the market's venue rules.

   Each stops acting on that category's requests, and the consequences run in opposite directions.

   On the compliance lane. An auto-clearance rule whose condition reads a field the category no longer carries cannot clear that category's requests, so they route to compliance review.

   A trigger condition that reads a removed field never fires for that category. That makes HCP attendees the field to weigh hardest, because the gate's shipped default trigger condition reads it. Remove it from a category, and the default trigger never fires there. That category's requests then reach no compliance review at all, unless another trigger condition covers them.

   An approval-rule condition reading a removed field stops routing on it the same way. The condition cannot match, so the rule it sits on cannot fire for that category. Routing falls to the next rule that matches.

   On the money lane. The budget reads Budget band. The approved band and its currency carry over to the event as the budget band on the budget header. The currency selected on a request becomes the budget currency of the resulting event. Budget band is the field to weigh beside HCP attendees, on the money lane rather than the compliance one.

   A category whose field set omits it, or leaves it optional and unanswered, produces event records that carry no approved band and no budget currency. Four things follow on those records:

   • No cost line. No cost line can be created. Every amount on a cost line is held in the budget currency, and a header carrying none gives a budgeted, committed, or actual amount no currency to be recorded in.
   • No over-band flag. The flag has nothing to read and does not fire.
   • No threshold or meal-cap check. A threshold policy watching the budgets kept in its own currency records that it did not apply, and so does the reconciliation meal-cap check.
   • No sourcing award. A sourcing award is refused rather than applied.

   Every one of those holds until the band is set afterwards on that event's budget header. That first band selection is described in step 4 and documented in Where a budget header carries no band and no budget currency, in Budget capture at request and working the budget during planning.

   Three further consequences land earlier, on the request rather than on the event record, so setting a band afterwards does not reach them:

   • No meal-cap comparison. The request carries no currency either. So the request-time comparison of Estimated hospitality per person with the market meal cap does not happen, and no Over meal cap indicator is written.
   • No auto-clearance. The under-cap form of the Hospitality over market meal cap condition is not met, so every auto-clearance rule carrying it stops clearing that category's requests. Those requests route to compliance review.
   • No auto-approval. Auto-approval has no band to compare, so no request under that category can qualify against the Budget threshold, and every one routes to a human approver. That matters most on the internal category, the one auto-approval ships selected on.

   On the dates lane. Proposed dates sits on the same footing. Approval fixes the event record's Start date and End date from it, and nothing else on this lane fills them.

   A category that omits the field, or leaves it optional and unanswered, produces an event record with no Start date and no End date. Such a record:

   • starts no reconciliation reminder;
   • is classified as neither Planned nor Completed on the portfolio 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 recoveries 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).

   On the venue lane. Removing Venue acts on two things at once. The request captures no venue, so the market's venue rules have nothing to act on at request time. They move to the venue recorded on the event record instead (see Setting venue rules in Onomi 360).

   See Configuring approval routing, the compliance gate, and auto-approval, and How to use the Budget module.

7. Optionally, add a category. Select Add category and name it. The new category starts from the core fields listed above, with the dimension fields presettable for the category, and you add the rest from the shared library with Add a field.

   The new category appears in the portal's category picker, in Event requests filters, and as a condition value in your approval rules. It arrives on the Event creation tab mapped to Create at Start execution from your default workspace template. Change that mapping where the category needs another behavior (see Configuring what approval creates in From approval to execution and auditing requests).

   Your organization holds up to 12 active categories, so retire one you no longer use to free a place.

   Speaker programs are one of the categories worth adding, and adding one takes no special step. A speaker program is a request category rather than a record type of its own. Name the category Speaker program and give it the field set its requests need, the Faculty field among them (see step 5). Map it on the Event creation tab as you would a congress.

   Where your organization runs both symposia and speaker programs, keep them as two category values, Symposium and Speaker program, rather than one combined value. The two usually route to different approvers and sit at different budget bands. The request category is the axis the portfolio calendar, the dashboards, and the reports filter and group on. A combined value cannot be told apart afterwards in any of them. Speaker programs are documented in How to run a speaker program.

8. Optionally, retire a category you have stopped using. Select the category, then select Retire.

   The category leaves the portal's category picker, so no new request can be submitted under it. A request already carrying it asks the requester to choose another category before it can be submitted. That applies whether the request is still Draft or was declined and reopened for editing.

   Nothing already submitted and still in approval changes. Those requests keep the category on their record and stay readable in Event requests and in reports. They keep the category as a filter value, and they keep the approval trail they were routed under. A request submitted under the 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 (see Configuring what approval creates in From approval to execution and auditing requests).

   Where your organization also approves events upstream in a CRM, revisit the connector's inbound field mapping in the same change. A retired category is no longer an active category. A record still arriving with that value creates nothing and is held instead, in the Held arrivals view of Event requests, with the value that failed to resolve. The same applies when you rename a category, if your mapping sends the name. See Events approved upstream in your CRM in From approval to execution and auditing requests.

9. Optionally, rename a category to match your organization's vocabulary. The category name appears in the portal's category picker, in the Event requests filters, and in approval rule conditions. Where events also arrive from your CRM, check the connector's inbound field mapping against the new name before you save, for the reason given in step 8.
10. Optionally, set whether the category is offered to requesters. With the category open on the Request form tab, set Available in the portal. Default: Yes, so the category appears in the portal's category picker and a requester can submit under it. Set it to No where the records in that category are never raised through the portal. The category is no longer offered in the picker, so no portal submission can be made under it. It stays active, keeps its mapping on the Event creation tab, and counts against your 12 active categories. A category you want out of use altogether is retired rather than switched off here (see step 8).
11. Select Save. The updated form is what requesters see the next time they open the portal.

Note: Country and city, Business unit, and, where you use them, Therapeutic area and Brand are the dimensions the rest of your configuration reads. The compliance gate's routing entries and the scopes on strategic meetings management role assignments match against them. The program-layer filters and reports in Onomi 360 group by them.

A dimension no request carries is a dimension you cannot route or report along. Alongside those dimensions, the request category the form collects is the axis Onomi 360's portfolio calendar and reports offer as a filter. The field an approval rule routes on and the field those views filter on are the same field. Keep the dimensions your organization routes by required. The dimension set is documented in Agency access and strategic meetings management scope.

Note: Approved venue lists, centralized selection, and market meal caps are venue rules, available since the 2025.11 release. Each is set per market. They act on a request only where the market it carries has them configured.

In a market with no approved venue list and no meal cap, the Venue field captures free text, and the hospitality estimate is recorded on the request without a cap check. A configured cap has a second condition, its currency. A cap is set in the currency of its market. Both checks compare in the market's currency, and nothing is converted. A request carries its currency from its budget band. Where that currency, or the event budget's currency, differs from the market's, the amounts are not compared with the cap. The check records that the cap did not apply, and no flag is raised. Setting them up, and setting each market's currency to the one the requests it checks actually carry, is documented in How to source a venue from your event.

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.