Setting venue rules in Onomi 360

Venue rules act wherever a venue reaches a request or an event record. This guide covers configuring them: the six per-market settings on the Venue rules tab, and the Markets list they are set on. It also covers what a requester can do in a restricted market, and how the rules apply to events approved upstream in your CRM. A rule that blocks refuses the choice outright. The way past a refusal is a compliant venue, or a change an organization administrator makes to the market's rules.

In life sciences, venue selection for an HCP event is governed by compliance policy as much as by logistics. Venue rules are therefore defined once, at organization level, and applied to every event. Each rule has a stated enforcement behavior: it either flags the record for review or blocks the choice. The glossary below names which. The venue rules described in this guide, with the approved and preferred flags they put in search results, are available since the 2025.11 release. The sourcing flow shipped one release earlier.

Who does what here is deliberately split. In Onomi 360 > Policies, organization administrators configure venue rules on the policy your compliance organization sets. A change to a meal cap or an approved venue list therefore has one editing group. Nobody overrides a rule on an individual event. A refusal is answered by choosing a compliant venue, or by an administrator changing the market's rules for everyone.

1. In Onomi 360, open Policies, then open the Venue rules tab.
2. Read the list the tab opens on. It shows one row per market, taken from the Markets list your organization maintains in Onomi 360 > Policies > Markets. That is the same list the meal caps below are set on, and the one the accommodation cap in your travel policy reads.

   Every market on that list is already here, and no market is created on this tab. Where a market you need is missing, add it on the Markets tab first. See Maintaining the Markets list below. Open a market's row to work that market's rule set. Check the market name on the row before you set anything, because every field below is held per market, the meal cap and the currency it is compared in included.

3. Configure the rule fields on the row you opened, and work each market where you run events the same way.
   • Approved venue list: the venues your organization has approved for the market. Default: empty, meaning search in that market is unrestricted. Add a list where your SOPs require events to use approved venues; listed venues are flagged in search results. A market's list holds up to 500 venues. Its CSV import takes up to 500 rows per file, one venue per row with its name, city, and market. Rows naming a market outside the Markets list are skipped and named in the import summary. Enforcement: flags by default; an off-list choice is flagged on the record but not blocked.
   • Require listed venues: when switched on for a market, off-list venues are blocked. Enforcement: blocks. An off-list venue cannot be selected on a request in that market, shortlisted, recorded on an event record, or awarded. The refusal is final. What changes the answer is a venue on the list, or an organization administrator adding this one to it. Default: off (the approved list flags rather than blocks). See Choosing a venue in a restricted market below.
   • Preferred venues: the venues where your organization holds negotiated terms. Default: none. A market holds up to 500 preferred venues. Preferred venues are flagged in search results, so requesters and planners see the negotiated option first.
   • Venue type restrictions: up to 20 venue types and entertainment-oriented settings your compliance policies exclude, set per market. Default: no restrictions. The restriction covers every country the market holds.

     Enforcement: blocks. The rule is evaluated against the venue type the sourcing network holds for the venue, the type shown on its result card. It therefore acts where a venue reaches the record from the partner's network. Two moments count: when the venue is shortlisted on a sourcing request, and again when an award returns to the event record.

     A blocked choice returns the venue type and the market, for example "Venues of type casino and gaming are restricted for France. Select a venue of a permitted type."

     Three paths carry no venue type for the rule to read: free text on a request's Venue field, Add venue on the event record, and a row from the market's approved venue list. An approved venue list row, and the CSV import behind it, holds the venue name, the city, and the market and nothing else. The platform performs no type block on those paths, so the people recording the venue apply the market's restriction there.

     That matters most on the two lanes where a venue that was not sourced reaches the record with Add venue: a record-only meeting, and an event approved upstream in your CRM. On those the restriction is a policy your team applies rather than a check the platform runs. Require listed venues is unaffected and still blocks an off-list venue on those paths.

   • Meal caps: the per-person food and beverage limit, set per market, in that market's currency. That is the currency the market carries in the Markets list (see Maintaining the Markets list below). The cap is an event-total figure. Both checks below read the event's whole hospitality spend per disclosable attendee recorded present, so the cap is entered as a per-event per-person amount. Per-meal or per-day limits are not expressed by this control.

     Where your national policy states its limit per meal or per occasion, which figure to enter here is a decision for your compliance organization rather than a platform setting. One figure is held per market, and the two ways of resolving it fail in opposite directions. Entering the per-meal figure flags a multi-day congress whose individually compliant meals add up past it. Entering what a compliant event could reach in total leaves an individual meal uncontrolled.

     Record the choice and the reason for it, so anyone reading a flag later knows which basis the cap was set on. A cap applies to every country in the market it is set on, so countries grouped into one market are held to one limit. Where your policy sets a different limit in each country, each of those countries needs a market of its own. The Markets list holds up to 100 markets, which is the ceiling on that pattern.

     Both checks below compare in the market's currency, and nothing is converted. Where a request's currency or the event budget's currency differs from the market's, the amounts are not compared with the cap. A request's currency is carried from its budget band. The check records that the cap did not apply, and no flag is raised. Set each market's currency to the one the requests it checks actually carry. Split a grouping that spans currencies into markets of its own, so every cap has amounts it can be read against.

     Default: no caps. Enforcement: flags, and the cap is checked twice. At request time, the Estimated hospitality per person on the request is compared to the meal cap of the request's market. The requester gives it as one figure for the whole meeting. That comparison is a named condition, Hospitality over market meal cap, available on your approval rules and on the compliance gate's trigger conditions. Your organization therefore decides whether an over-cap request takes an extra approval level or goes to compliance review.

     An over-cap estimate warns the requester at submission, for example "Estimated hospitality per person (EUR 145) is over the meal cap for France (EUR 120). You can submit this request, and it will be flagged for review." The submission itself is never blocked. An over-cap result also writes the Over meal cap indicator on the request, naming the cap and the amount over it. The indicator is shown on the request record and is a filter in Event requests. See Configuring approval routing, the compliance gate, and auto-approval for both settings.

     At reconciliation the same cap is checked against real spend. The check divides the reconciled actuals on the cost lines whose category is marked Counts toward the meal cap by the attendees recorded present whose registrant type is marked transfer of value relevant. The figure it compares with the cap is therefore the event's total hospitality spend per disclosable attendee. That is a per-event per-person figure, rather than a per-meal or per-day one.

     Internal staff, agency registrant types, no-shows, and attendees whose attendance state has not been recorded stay outside the divisor. A per-person figure over the market meal cap raises the Meal cap exceeded flag on the event's budget.

     The notification goes to the recipients of every threshold policy kept in the event's budget currency whose scope covers a category that counts toward the meal cap. That includes a policy in that currency whose Applies to is the whole event budget, since a whole-budget policy evaluates every cost line and the event total. Where several policies match, each of their recipient lists is notified once.

     Where no policy in the event's budget currency covers any of those categories, the notification goes to the event's finance owner, who is the person the flag already waits on and who clears it. Where no attendee recorded present carries a registrant type marked transfer of value relevant, there is nothing to divide by. The check then records that the cap did not apply, and no Meal cap exceeded flag is raised.

     That check and that flag are documented in Reconciliation, invoices, and closing the event, including how those recipients are set, how the flag clears, and what stays on the record. This tab is where the cap itself is set per market. The Meal cap exceeded flag stays with finance and is not routed to compliance review. Where your policy requires a compliance reviewer to see over-cap spend, that referral is a step in your process rather than something the platform routes.

     Organizations that want compliance in the loop on real spend name their compliance reviewers among the notification recipients of a threshold policy that already covers one of those categories. Name them in each currency their events are budgeted in, since only a policy kept in the event's budget currency is read. Creating a policy only to hold those names has a side effect to plan for. A threshold policy carries a Limit, is evaluated every time a cost line is saved, and fires on ordinary spend as soon as a value in its scope crosses that limit. See How to use the Budget module.

     For an event that arrived approved from your CRM, see Venue rules on events approved in your CRM below.

   • Centralized selection: when switched on for a market, that market's approved venue list becomes the selectable set. The list is offered on the Venue field of the meeting request form and in venue search for the market. Free search of the sourcing partner network and free text are not offered there. A requester working in that market therefore chooses from the approved set.

     This setting controls what can be selected. It is not an enforcement setting. The enforcement of an off-list choice comes from the rules above: an approved list flags, and Require listed venues blocks.

     Those two places are the whole of its reach: it does not reach the venue entries on the event record. Those entries stay open to the planners of the event's workspace and to holders of the finance role whose scope covers the event. So a venue booked outside the sourcing flow, or a replacement recorded after a withdrawn award, is still entered there as free text or picked from the market's approved venue list. See Withdrawing a booking after an award in Sending the RFP, comparing bids, and contracting the venue. Searching for venues and choosing how to book names who records a venue there.

     The rules apply to such a venue like any other. The market's approved venue list flags it where it is off-list, and Require listed venues refuses it. The venue-rule result reads on that venue's entry on the event record. The list itself is the one an organization administrator maintains in Approved venue list above, in this same Venue rules tab. Default: off, meaning search in the market is open and the approved list flags rather than restricts.

4. Select Save. The rules apply to every event in the organization from then on. A change to a rule or a cap is recorded in the audit trail, with who made it and when. It applies from the moment it is saved. A check already recorded on a request or on a budget keeps the values it ran against. An audit of an earlier event therefore reads the cap that was in force at the time rather than today's.

   

5. Verify the rules on a live search: open an event in a market with an approved list and run a venue search. Approved and preferred venues show their flags in the results.

Maintaining the Markets list

Markets are organization-level, and there is one list of them. A market is a named grouping of countries. Every rule and cap on the Venue rules tab is held per market, so the list is built before the rules that read it. An organization administrator maintains the markets. Everyone else sees the list read-only.

1. In Onomi 360, open Policies, then open the Markets tab. Select Add a market and complete its fields:
   • Market name: how the market appears wherever a market is chosen, for example "DACH" or "France". Use the names your policies already use, because approvers and reviewers read them.
   • Countries: the countries that belong to the market. A country belongs to one market at a time, so every request, every event, and every registration record resolves to exactly one market.

     The rule is enforced rather than advisory. Adding a country that is already in another market is refused, and the message names the market it sits in, for example "France is already in the market Southern Europe. Remove it there first, or choose another country."

   • Currency: the currency the market's amounts are set and read in. Where your organization's reporting currency is already set, in Onomi 360 > Budget > Currencies (see Setting up budgets: categories, bands, and policies), the field defaults to it.

     Your markets may be built before the budget suite is configured, which is the order the implementation checklist follows (see How to plan your Onomi 360 implementation). There is then no reporting currency for the field to take, so set each market's currency explicitly to the currency the policies for that market are written in. Every amount configured per market is entered in it and compared in it, the meal cap above and the accommodation cap in your travel policy included.

2. Select Save. The market is available immediately wherever a market is used, and its row appears on the Venue rules tab for you to set that market's rules on.

A market is edited in place. No control removes or retires one, so plan the list as an additive set. Move a country between markets by removing it from its current market and saving, then adding it to the new one. Leave a market you no longer use on the list, with its countries reassigned. The list holds up to 100 markets, which is the ceiling on the country-by-country pattern the meal caps above describe. Where your organization is approaching that ceiling, or has reached it, contact your SpotMe Account Manager.

Four things read this list.

• The venue rules and the meal caps sit on the Venue rules tab, which shows one row per market and creates none.
• The accommodation cap in your organization travel policy is held per market and compared in that market's currency.
• The journey band the travel policy's cabin and rail class rule reads is resolved from the list, as within market or beyond market, by comparing the registrant's country with the event country.
• The market shown on a registrant's travel records is resolved from the country on their registration record. It is the one the request queue, the Completeness view, and the arrivals and departures manifests display. On an international event, it also determines which team works the request.

The travel readers are documented in Setting up travel and capturing travel needs and The booking loop, manifests, and travel reporting. Requests are worked on the event in the event workspace by people who hold the travel role there. There is no booking-desk record, organization-level desk list, or desk set on an event.

The compliance gate's routing entries do not read this list either. A routing entry is scoped on the geography a request already carries. An entry meant to cover a market therefore names that market's countries in its Geography scope. Changing which countries a market groups means revisiting the entries written to follow it (see Configuring approval routing, the compliance gate, and auto-approval).

Where your organization's terms live

The terms your organization has negotiated for its venue bookings are held with the sourcing partner, not on a tab in Onomi 360. They are the payment, cancellation, and attrition terms, the data-protection clauses, and anything else your legal team requires a venue to accept before it bids.

They are embedded in every RFP the partner sends on your behalf. A venue acknowledges them when it submits its proposal. The acknowledgement and the date it was given are recorded on that venue's entry on the event. Every bid you compare was therefore made against terms the venue has already accepted. See Sending the RFP and comparing bids in Sending the RFP, comparing bids, and contracting the venue.

There is no terms-authoring screen in Onomi 360. The six settings above are the whole of what an organization administrator edits on the Venue rules tab, and terms are not among them. Loading the terms, and changing them later, runs as a configuration task with your SpotMe implementation team:

1. Agree the terms text with your legal and compliance teams, in the language and at the version your organization wants venues to accept.
2. Send that text to your SpotMe implementation team, and say what scope it applies to: your whole organization, or an affiliate or a market whose local terms differ.
3. Your implementation team loads the terms with the sourcing partner at that scope and confirms back which scope holds which version.
4. Verify on your next RFP. Open the request before you send it and read the terms block on it, then check the acknowledgement on the proposals that come back.

A change follows the same route: repeat steps 1 to 3, and the new version is embedded in the RFPs sent after it is loaded. A request that has already gone to market keeps the version its venues acknowledged, and that acknowledgement is what stays on the record.

Note: Because the terms are held with the sourcing partner, Onomi 360 neither stores nor versions the terms text, and there is nothing to export from it. Keep your own record of which version was in force from when, and read the acknowledgement on the venue entry as the evidence that a given venue accepted the terms it bid against.

Choosing a venue in a restricted market

Two of the settings above restrict venue choice, and they do different jobs. Centralized selection controls the selectable set: the market's approved venue list, with no free search of the sourcing partner network and no free text.

Enforcement is a property of each rule rather than of that setting.

A venue entered on the request as free text, or picked from an approved venue list row, is not a venue the network holds a type for (see Venue type restrictions above).

A market that must not book an off-list venue runs both settings. Require listed venues blocks at the three points that put a venue on the event record. Those are shortlisting on a sourcing request, an award returning to the record, and Add venue. An instant booking passes none of those, because it is confirmed on the sourcing partner's surface and comes back as a status. Centralized selection is what closes that route, since venue search then returns the approved list only and there is no off-list venue to book. The trade-off is stated above: free search of the sourcing partner network is not offered in that market. See Searching for venues and choosing how to book.

So what a requester or planner can do with an off-list venue, a restaurant that is not on the market's approved list for example, depends on which of the two settings the market has on:

• 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 same branches govern the Venue field on the meeting request form; see Configuring the request form and its categories.

Venue rules on events approved in your CRM

Your governance model may approve events upstream in Veeva CRM Events Management or Veeva CRM Medical Events. Such an event arrives in Onomi 360 already Approved and linked to its upstream reference, with no request form behind it. The routing rules, the compliance gate, and auto-approval do not evaluate it. See From approval to execution and auditing requests for that posture.

The venue rules that operate on the record apply to these events like any other. They read the venue on the event and the market it sits in, rather than a request. The market's approved venue list flags an off-list venue, and Require listed venues blocks one. The result reads on that venue's entry on the event record.

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 people recording the venue apply the market's restriction. See Setting venue rules in Onomi 360 above.

Two things work differently. The request-time hospitality check does not run, because there is no request to carry an Estimated hospitality per person figure. Neither the Hospitality over market meal cap condition nor the Over meal cap indicator applies to an upstream-approved event.

The hospitality control that does apply is the reconciliation check on real spend. It sums the reconciled actuals on the cost lines whose budget category is marked Counts toward the meal cap. It takes them per attendee recorded present and marked transfer of value relevant. Where that figure comes out over the market meal cap, the check raises the Meal cap exceeded flag on the event's budget. See Reconciliation, invoices, and closing the event.

That check reads the event's whole hospitality spend, as the request-time check reads the whole meeting's estimate, so the cap is a per-event per-person figure on this posture as on any other.

A blocking rule behaves here as it does anywhere else, and there is nothing to route. Require listed venues refuses an off-list venue on the record, and the refusal reads on that venue's entry. The venue reaches the event only once it is on the market's approved venue list.

Recording the replacement belongs to the planners of the event's workspace where the category creates one, and to holders of the finance role whose scope covers the event. Where the category is record-only and there is no workspace, it belongs to the finance role alone. An event arriving approved from your CRM therefore always has someone who can record a compliant venue on it.

For what this module does and where its boundaries are, see How to source a venue from your event.

* Onomi 360 MeetingsEQ exclusive capabilities.