Configuring approval routing, the compliance gate, and auto-approval

Who reviews each request is computed rather than hard-coded. This guide covers the settings in Policies in Onomi 360 that compute it: the approval rules that route the budget chain, the additive compliance gate, and auto-approval. It closes with a verification run for the whole setup. Every condition these settings read is a field the request form collects; see Configuring the request form and its categories.

Configuring approval rules in Policies

Approval rules decide who reviews each request, and together they are the suite's multi-axis approval routing. A rule combines conditions with an ordered list of approval levels. The conditions are budget band, attendee type, request category, and Hospitality over market meal cap. The approver is computed from those axes together.

1. In Onomi 360, open Policies, then open the Approval rules tab. Existing rules are listed in evaluation order.
2. Select New rule, or open an existing rule to edit it. Each rule carries:
   • Rule name: shown to requesters and approvers in the "why this approver" trace, so name it in plain language, for example "HCP meetings above 10,000 EUR, two levels".
   • Conditions: the budget band (with its currency), the attendee type (HCP or public-official attendees present, or not), the request category, and Hospitality over market meal cap. Hospitality over market meal cap is the named condition that compares the Estimated hospitality per person on the request with the meal cap of the request's market. It matches when the estimate comes out above the cap. An over-cap result also writes the Over meal cap indicator on the request. What routed the request and what is visible on it are the same fact.

     Each condition takes one or more values from its axis, and matches when the request's value is among them. A condition you leave unset matches any value. That is how the built-in default rule below matches every request. All conditions on a rule must match for it to fire, and the axes work together. The same spend routes differently when HCP attendees are present. A meal over the market cap can route to a level the same meeting under the cap does not reach.

     Currency comes with the budget band, because a band is defined for one currency. A rule whose conditions include a budget band is bound to that band's currency. An organization requesting events in several currencies therefore writes one routing chain per currency. Every one of those chains counts against the ceiling of 60 approval rules per organization. Size your routing map on that: one chain per combination of conditions you route differently, multiplied by the currencies you request in, across your divisions and countries.

   • Approval levels: an ordered list of up to five approvers, each level naming a person or a role. Levels complete in order: level 2 is notified only once level 1 has approved. Add levels to build an escalation ladder that carries high-value requests to senior approvers.
3. Drag rules to set their order. Rules are evaluated top to bottom, and the first rule whose conditions all match routes the request. Place your most specific rules at the top.
4. Select Save. The rule appears in the list and applies to requests submitted from then on.

The grant and the selection are two separate things. Holding the Approver role is the permission to approve at all. The role is granted in Onomi 360 under Users and roles, with a scope. The approval levels here select among the people who hold it, and decide which requests reach each one. The picker at a level lists role holders only, so a person without the grant cannot be selected. Grant the role first, then name them in a rule.

A level that names a role rather than a person places one shared approval in the personal My approvals queue of every holder whose scope covers the request. Any one of them may act, and the trail records who acted and when. Reminders go to every holder whose personal queue still carries the approval. Escalation after three reminder cycles moves the approval to the next level, or to your organization administrators where no further level exists. A delegation set by one holder passes only that holder's own items for the date range, and leaves the other personal queues unchanged.

See Delegation, reassignment, and escalation in Approving requests and working your review queue. The role registry is documented in The role model and role registry, and the scope model in Agency access and strategic meetings management scope.

Every organization starts with a default rule that matches any request and routes it to a single approver you name. It sits last and is always there, so no request is ever left without a route. Replacing its placeholder approver is your first configuration step.

A rule you no longer want to route with is taken out of service with the controls on this tab. Narrow its conditions so the requests you want routed elsewhere no longer match it, or drag it below the rules that should match first. Either change applies to requests submitted after you save it. The requests already routed keep the chain they were routed on.

To run more than one approval chain, create one rule per chain and separate them by conditions. For example, one chain takes scientific requests with HCP attendees, and another takes executive requests carrying the budget bands your policy treats as high value. A request always follows exactly one rule, the first that matches. The compliance gate below is the only approval that adds itself on top of the matched chain.

Configuring the compliance gate

The compliance gate is the suite's additive compliance gate: a separate approval that runs alongside the budget chain rather than replacing it. The gate is a configuration surface rather than fixed behavior. What fires the gate, which triggered requests clear without review, and which team reviews the rest are all settings you edit. They are documented field by field below.

1. In Onomi 360, open Policies, then open the Approval rules tab and go to the Compliance gate section.
2. Set the Trigger conditions, which decide what fires the gate, and the Default compliance reviewers, whose personal My compliance reviews queues receive triggered requests that match no routing entry.
3. For each review team that owns compliance review inside a scope of its own, select Add entry on Routing entries. Name the entry, set its scope and its reviewers, then drag it into order. A scope is built from geography, business unit, and, where your organization uses them, therapeutic area or brand. Leave the list empty and every triggered request routes to the default compliance reviewers.
4. For each auto-clearance rule your compliance organization allows, select Add rule on Auto-clearance rules. Name the rule, set its Scope and its conditions, then drag your most specific rules to the top. Leave the list empty and every triggered request routes to compliance review.
5. Select Save. From now on, every submitted request that matches a trigger condition either clears under an auto-clearance rule or carries a compliance approval alongside its budget chain. The approval appears in My compliance reviews for each person in the matching reviewer group.

The section carries four fields:

• Trigger conditions: what fires the gate on a submitted request. Default: the HCP attendees field shows HCP or public-official attendees present. A request that matches any listed condition fires the gate. Change it to extend the gate to requests your policy also treats as compliance-relevant, for example a request category, a budget band, or Hospitality over market meal cap. Hospitality over market meal cap is the same named condition your approval rules use. It matches when the Estimated hospitality per person comes out above the meal cap of the request's market, and it writes the Over meal cap indicator on the request. Review any change with your compliance organization. Removing the default condition stops HCP-present requests from reaching compliance review.
• Default compliance reviewers: up to 25 reviewers whose personal queues receive a triggered request when no routing entry matches. Default: empty. Every reviewer sees the same pending approval in My compliance reviews, and any one of them can act. The first decision completes the shared approval and removes it from the other reviewers' queues.

  A request the compliance gate routes to a reviewer is visible and workable in that reviewer's personal queue, even when it falls outside their normal scope. That holds whether it arrived through a routing entry or through the default reviewer list. The reviewer's scope still bounds every other event record they can read (see Role-based access and visibility for internal and external stakeholders). Only people holding the Compliance reviewer role are listed for selection, so grant the role first. Change the list whenever your reviewer team changes.

  As with approval levels, the grant and the selection are separate. Compliance reviewer is a role granted in Onomi 360 under Users and roles, with a scope. Holding it is the permission to review at all. The default reviewer list and routing entries select among role holders, and decide which approvals appear in each person's queue. A person who does not hold the role cannot be selected as a reviewer or named in a routing entry.

• Routing entries: optional entries that route the gate by scope. Default: none, so every triggered request routes to the default compliance reviewers. Each entry names a scope and up to 25 reviewers who own it. The scope is built from the same dimensions as strategic meetings management role assignments: geography, business unit, and, where your organization uses them, therapeutic area or brand. A request from a given geography appears in the personal queue of every reviewer on the matching entry.

  Those dimensions are read from the request itself: geography from its Country and city, then the Business unit and, where you use them, the Therapeutic area and Brand it carries. Market is not one of them. The Markets list in Onomi 360 > Policies is what your per-market rules read. Those rules are the meal caps and the venue rules, the travel teams and travel routing, and the accommodation cap. An entry meant to cover a market therefore names that market's countries in its Geography scope, rather than the market itself. Where you change which countries a market groups, revisit the entries that were written to follow it. The market list is documented in Setting up travel and capturing travel needs.

  Where more than one entry could take the same request, one rule settles it. Entries are evaluated in list order, and the first entry whose scope matches the request is the one that receives it. A request matching no entry routes to the default compliance reviewers. Drag entries to reorder them, so your most specific entries sit above the broader ones. Each entry shows how many requests are waiting on its reviewers, so you can see where review is queuing. Select Add entry when different teams own compliance review for different parts of your organization. The scope model is documented in Agency access and strategic meetings management scope.

• Auto-clearance rules: optional rules that clear a triggered request without review. Default: none defined, so every triggered request routes to compliance review. Each rule carries a name, a Scope, and its conditions.

  The Scope is built from the same dimensions as the routing entries and as strategic meetings management role assignments: geography, business unit, and, where your organization uses them, therapeutic area or brand. A rule therefore clears requests only in the part of the organization whose policy allows it. A rule with no scope set applies organization-wide.

  Every condition reads a field the request form collects:

  • the Format field (in person, virtual, or hybrid);
  • the Estimated hospitality per person staying under the market meal cap; and
  • the Speakers or honoraria field showing none.

  A request clears the gate automatically when it falls inside a rule's scope and meets every condition of that rule. Its record carries a full rule trace, showing which rule cleared it and on which values. Where the request's market has no meal cap configured, the under-cap condition is not met, so a rule carrying it cannot clear the request and the request routes to compliance review.

  Rules are listed in evaluation order. The first rule whose scope and conditions both match is the one that clears the request, so drag your most specific rules to the top. Rules are added with Add rule, deliberately and with your compliance organization.

A change to a trigger condition, an auto-clearance rule, or a routing entry is recorded with who made it and when. The change applies from that point forward. A request already submitted keeps the gate behavior that was in force when it was submitted, so a rule added today does not clear a request that is already in review.

Size the two lists as groupings. One compliance gate covers the whole organization. Its ceilings are organization-wide totals rather than a count per scope dimension, per market, or per business unit: 10 auto-clearance rules and 20 routing entries in all.

A routing entry names a scope. A scope is a set of values on each dimension: the countries it covers on the geography dimension, its business unit, and, where you use them, its therapeutic area or brand. One scope holds up to 25 values per dimension, the same ceiling a role assignment holds.

A team that owns compliance review for a set of countries is described by one entry, naming those countries in the entry's Geography scope. An organization running three divisions across 100 or more countries writes its review map as one entry per team, rather than one per country. Where a team's country list runs past the 25 values one entry's geography scope holds, add a further entry for it.

An auto-clearance rule works the same way from the other direction. A rule left without a scope applies organization-wide, so a policy that holds everywhere is one rule rather than one per geography. A scoped rule is needed only where a part of the organization clears on different terms. A request whose geography, business unit, or other dimensions match no routing entry is not left unrouted. It appears in the personal queue of every person selected under Default compliance reviewers.

Reviewers learn about waiting work through the templates in the Notifications tab. When a triggered request enters their personal queues, the Request submitted template goes to every reviewer in the matching group. The Reminder template repeats on your configured cadence until one reviewer acts. The first decision removes the item from the other reviewers' queues.

Important: Add at least one reviewer before sharing the portal. While the reviewer list is empty, a triggered request stays In review with its compliance approval outstanding and nobody to act on it. The section shows the warning "No compliance reviewers are assigned. Requests that reach the compliance gate will wait for review until you add a reviewer."

Configuring auto-approval

Auto-approval rules let low-risk requests approve themselves under policy, so the process cost stays proportionate to the meeting.

1. In the Approval rules tab, go to the Auto-approval section.
2. Switch on the Auto-approval toggle. It is off by default: until you enable it, every request routes to a human approver.
3. Set the Budget threshold, an amount per currency, and select the Request categories that qualify. By default only the internal category is selected. Add categories deliberately, in line with your policy. A request qualifies when its budget band qualifies against the threshold and its category is one you selected.

   A category whose field set omits Budget band, or leaves it optional and unanswered, produces requests carrying no band. Those requests never qualify, however the threshold is set, and every one routes to a human approver (see step 6 of Configuring the request form and its categories).

   A requester selects a band rather than an amount, so the comparison runs on the band's bounds. A band qualifies only when its To value is at or under the threshold. A band that straddles the threshold does not qualify, and the open-ended top band never qualifies. Bands and their bounds are defined per currency in Setting up budgets: categories, bands, and policies.

4. Select Save. Qualifying requests now move straight from Submitted to Approved at submission. Each record keeps a visible trace, showing which auto-approval rule fired. Where the compliance gate cleared automatically, the trace also names the auto-clearance rule that cleared it.

Note: Auto-approval covers the budget chain, and the compliance gate keeps its own logic. A qualifying request with HCP or public-official attendees present moves straight to Approved only when a compliance auto-clearance rule also clears the gate (see Configuring the compliance gate). Otherwise it stays In review with its compliance approval outstanding, even though no budget approver is needed.

Verifying your setup

Before sharing the portal widely, run one request through each lane.

1. Open the portal from the address on the Request form tab, and submit a test request that should route. A scientific request with HCP attendees and a budget above your auto-approval threshold will do. Confirm four things:
   • the request shows In review once routing completes;
   • its "why this approver" trace names the rule and approver you expect;
   • the approver received the notification email; and
   • the compliance approval appears in My compliance reviews for each expected reviewer.
2. Submit a second test request that meets the auto-approval conditions. Auto-approval reads the budget band, and the bands come from the budget suite's per-currency band sets. Run this step only once a band whose To value is at or under the threshold exists in the currency you are testing. Confirm it shows Approved immediately, with the auto-approval rule named in its trace.
3. Open the event created from the approved test request, and confirm it matches the category's mapping. A record-only category shows the event record with no workspace and no Start execution action. A category mapped to a create behavior shows the workspace, either already created or waiting on Start execution. Confirm the record also carries the Start date and End date the approval fixed. Then confirm that someone can act on Start execution.
   • On a Create at Start execution category the action is available to holders of the finance role whose scope covers the event. Check that at least one such holder exists before you hand the category to requesters.
   • On a Create at approval category, confirm that the workspace was created from the template the mapping names, and that it opens with no team. Then have an organization Admin add a planner to it centrally, and confirm that planner can select Start execution. Until a planner is added, the finance-role holders are the actors there as well.
4. Decline the first test request with a reason such as "configuration test". The test, its routing, and your decline stay in the audit trail.

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.