Setting venue rules in Onomi 360

Venue rules act whenever a venue arrives on a request or an event record.

This guide explains how to configure them: the six per-market settings on the Venue rules tab, and the Markets list they are set on.

It also explains 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.

You therefore set venue rules once, at organization level, and they apply 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. You see one row per market, taken from the Markets list your organization maintains in Onomi 360 > Policies > Markets.

   The meal caps below are set on that same list, and the accommodation cap in your travel policy uses it too.

   Every market on that list is already here, and no market is created on this tab.

   If 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 you set every field below 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 you run events in the same way.
   • Approved venue list: the venues your organization has approved for the market. The list starts empty, meaning search in that market is unrestricted.

     Add a list if your SOPs require events to use approved venues; listed venues are flagged in search results. You can add up to 500 venues to a market's list.

     The 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. By default the list flags: an off-list choice is flagged on the record, and not blocked.

   • Require listed venues: when switched on for a market, off-list venues are blocked.

     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.

     By default it is off, and the approved list only flags. See Choosing a venue in a restricted market below.

   • Preferred venues: the venues your organization has negotiated terms with. The list starts empty. You can add up to 500 preferred venues to a market.

     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, which you set per market.

     By default there are no restrictions. The restriction applies to every country in the market.

     This rule blocks. It is evaluated against the venue type the sourcing network provides for the venue, the type shown on its result card.

     It therefore acts when a venue arrives on 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 have 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, has 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.

     The gap matters most in two cases: a record-only meeting, and an event approved upstream in your CRM. On both, a venue that was not sourced arrives on the record with Add venue.

     Your team then applies the restriction as a policy, and the platform does not check it. Require listed venues is unaffected and still blocks an off-list venue on those paths.

   • Meal caps: the per-person food and beverage limit you set per market, in that market's currency.

     The market's currency comes from the Markets list (see Maintaining the Markets list below). The cap is an event-total figure.

     Both checks below use the event's whole hospitality spend per disclosable attendee recorded present, so you enter the cap as a per-event per-person amount. You cannot set a per-meal or per-day limit here.

     If your national policy states its limit per meal or per occasion, your compliance organization decides which figure to enter here, because the platform has no setting that resolves it.

     You enter one figure per market, and the two ways of resolving it fail in opposite directions.

     Entering the per-meal figure flags a multi-day congress with individually compliant meals that 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 share one limit.

     If your policy sets a different limit in each country, you need a market of its own for each of them.

     The Markets list takes up to 100 markets, which is the limit on that pattern.

     Both checks below compare in the market's currency, and nothing is converted.

     If 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 takes its currency 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 its requests actually use.

     Split a grouping that spans currencies into markets of its own, so every cap has amounts it can be read against.

     By default no caps are set. A cap flags, and it 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.

     The 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 puts the Over meal cap indicator on the request, naming the cap and the amount over it.

     You see the indicator on the request record, and it 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. Onomi adds up the reconciled actuals on every cost line in a category marked Counts toward the meal cap.

     It divides that total by the number of attendees who were recorded present and have a registrant type marked transfer of value relevant.

     The result it compares with the cap is the event's total hospitality spend per disclosable attendee. It is a per-event per-person figure, not a per-meal or per-day one.

     Internal staff, agency registrant types, no-shows, and attendees with no recorded attendance state stay outside the divisor.

     A per-person figure over the market meal cap puts 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 with a category that counts toward the meal cap in its scope.

     A policy in that currency with Applies to set to the whole event budget counts too, since a whole-budget policy evaluates every cost line and the event total.

     If several policies match, each policy's recipient list is notified once.

     If no policy in the event's budget currency covers any of those categories, the notification goes to the event's finance owner.

     That owner is the person the flag already waits on, and the one who clears it.

     If no attendee recorded present has 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.

     The check and the flag are documented in Reconciliation, invoices, and closing the event, including how those recipients are set, how to clear the flag, and what remains on the record.

     You set the cap itself per market on this tab.

     The Meal cap exceeded flag remains with finance and is not routed to compliance review.

     If your policy requires a compliance reviewer to see over-cap spend, that referral is a step in your process, and the platform does not route it.

     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 for those names has a side effect to plan for.

     A threshold policy has a Limit, is evaluated every time a cost line is saved, and notifies its recipients 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 remain open to the planners of the event's workspace and to holders of the finance role with the event in their scope.

     A venue booked outside the sourcing flow, or a replacement recorded after a withdrawn award, is therefore 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 if it is off-list, and Require listed venues refuses it.

     You see the venue-rule result 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.

     By default it is off: search in the market is open, and the approved list flags but does not restrict.

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 shows the cap that was in force at the time, not 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.

   You see the approved and preferred flags on the venues 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.

You set every rule and cap on the Venue rules tab per market, so build the list before the rules that use 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, not advisory. Adding a country that is already in another market is refused, and the message names the market it is in, for example "France is already in the market Southern Europe. Remove it there first, or choose another country."

   • Currency: the currency you set and read the market's amounts in.

     If 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.

     You may build your markets 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.

     You enter and compare every amount configured per market 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 you can set that market's rules on its row on the Venue rules tab.

Editing a market

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 takes up to 100 markets, which is the limit on the country-by-country pattern the meal caps above describe.

If your organization is approaching that limit, or has reached it, contact your SpotMe Account Manager.

What reads the Markets list

Four things read this list.

• The venue rules and the meal caps are on the Venue rules tab, which shows one row per market and creates none.
• The accommodation cap in your organization travel policy is set per market and compared in that market's currency.
• The travel policy's cabin and rail class rule uses a journey band, 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 already on the request.

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 kept 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.

Loading and changing the terms

There is no terms-authoring screen in Onomi 360. The six settings above are the whole of what you can edit 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 with local terms of its own.
3. Your implementation team loads the terms with the sourcing partner at that scope and confirms back which version applies to which scope.
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 remains on the record.

Note: Because the terms are kept 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, not 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 provides 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 in the sourcing partner's own system 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.

What a requester can do with an off-list venue

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 how such an event is handled.

The venue rules that operate on the record apply to these events like any other. They use the venue on the event and its market, not a request.

The market's approved venue list flags an off-list venue, and Require listed venues blocks one. You see the result on that venue's entry on the event record.

The venue-type and entertainment restrictions do not go as far on these events. They are evaluated against the venue type the sourcing network provides, 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 has 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.

The hospitality checks on an upstream event

Two things work differently. The request-time hospitality check does not run, because there is no request with an Estimated hospitality per person figure on it.

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 with a budget category marked Counts toward the meal cap.

It takes them per attendee recorded present and marked transfer of value relevant.

If that figure comes out over the market meal cap, the check puts the Meal cap exceeded flag on the event's budget. See Reconciliation, invoices, and closing the event.

The reconciliation check uses the event's whole hospitality spend, as the request-time check uses the whole meeting's estimate, so the cap is a per-event per-person figure on these events as on any other.

Recording a replacement venue

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 you see the refusal on that venue's entry.

The venue arrives on 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, if the category creates one, and to holders of the finance role with the event in their scope.

If the category is record-only and there is no workspace, only the finance role can record it.

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.