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

Who reviews each request is computed, not hard-coded.

This guide explains 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. You see the existing rules listed in evaluation order.
2. Select New rule, or open an existing rule to edit it. Each rule has:
   • 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 puts 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. Leaving every condition unset 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 is routed 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 with a budget band among its conditions is bound to that band's currency. An organization requesting events in several currencies therefore creates one routing chain per currency.

     Every one of those chains counts against the limit 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. You can add levels to build an escalation ladder that takes high-value requests to senior approvers.

3. Drag rules to set their order. Rules are evaluated top to bottom, and the request follows the first rule with every condition matching. Place your most specific rules at the top.
4. Select Save. You see the rule in the list, and it applies to requests submitted from then on.

Who can be named as an approver

The role assignment and the selection are two separate things. Holding the Approver role is the permission to approve at all. The role is assigned 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 role assignment cannot be selected. Assign the role first, then name them in a rule.

A level that names a role, not a person, places one shared approval in the personal My approvals queue of every holder with a scope that covers the request.

Any one of them may act, and the trail records who acted and when. Reminders go to every holder with the approval still in their personal queue.

Escalation after three reminder cycles moves the approval to the next level, or to your organization administrators if 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 reference is documented in Onomi 360 roles, permissions, and scope, and the scope model in Agency access and strategic meetings management scope.

The default rule

Every organization starts with a default rule that matches any request and sends it to a single approver you name.

It is last and always there, so no request is ever left without a route. Replacing its placeholder approver is your first configuration step.

Taking a rule out of service

You can take a rule you no longer want to route with 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.

Running more than one approval chain

To run more than one approval chain, create one rule per chain and separate them by conditions.

For example, you can run one chain for scientific requests with HCP attendees, and another for executive requests in 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 and does not replace it. The gate is configuration, not fixed behavior.

What triggers the gate, which triggered requests clear without review, and which team reviews the rest are all settings you can 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 triggers the gate. Then set the Default compliance reviewers: triggered requests that match no routing entry go to their personal My compliance reviews queues.
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, if your organization uses them, therapeutic area or brand. Leave the list empty and every triggered request goes 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 goes 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 has a compliance approval alongside its budget chain.

   The approval appears in My compliance reviews for each person in the matching reviewer group.

The fields on the Compliance section

The section has four fields:

• Trigger conditions: what triggers the gate on a submitted request. By default, the HCP attendees field shows HCP or public-official attendees present. A request that matches any listed condition triggers the gate.

  You can 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 puts 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 who receive a triggered request in their personal queues when no routing entry matches. The list starts 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 sends to a reviewer is visible and workable in that reviewer's personal queue, even when it falls outside their normal scope.

  The visibility is the same 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 assign the role first. Change the list whenever your reviewer team changes.

  As with approval levels, the role assignment and the selection are separate.

  Compliance reviewer is a role assigned 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. By default there are none, so every triggered request goes 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, if 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, if you use them, the Therapeutic area and Brand on it.

  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, not the market itself.

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

  If more than one entry could take the same request, one rule settles it.

  Entries are evaluated in list order, and the first entry with a scope matching the request is the one that receives it. A request matching no entry goes to the default compliance reviewers.

  Drag entries to reorder them, so your most specific entries are 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. By default none are defined, so every triggered request goes to compliance review. Each rule has 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, if your organization uses them, therapeutic area or brand.

  A rule therefore clears requests only in the part of the organization with a policy that allows it. A rule with no scope set applies organization-wide.

  Every condition uses 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 keeps a full rule trace, showing which rule cleared it and on which values.

  If the request's market has no meal cap configured, the under-cap condition is not met, so a rule that includes it cannot clear the request, and the request goes to compliance review.

  Rules are listed in evaluation order. The first rule with scope and conditions both matching is the one that clears the request, so drag your most specific rules to the top.

  You add rules with Add rule, deliberately and with your compliance organization.

Gate changes and requests already submitted

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.

Sizing reviewer groups and routing entries

Size the two lists as groupings. One compliance gate serves the whole organization.

Its limits are organization-wide totals, not 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: its countries on the geography dimension, its business unit, and, if you use them, its therapeutic area or brand.

You can put up to 25 values on each dimension of a scope, the same limit as a role assignment.

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 builds its review map as one entry per team, not one per country.

If a team's country list runs past the 25 values one entry's geography scope allows, 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 applies everywhere is one rule, not one per geography.

A scoped rule is needed only if a part of the organization clears on different terms.

A request with a geography, business unit, or other dimensions matching no routing entry is not left unrouted. It appears in the personal queue of every person selected under Default compliance reviewers.

How reviewers hear about waiting work

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 remains 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 remains 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 goes 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 that omits Budget band from its field set, or leaves it optional and unanswered, produces requests with no band.

   Those requests never qualify, however the threshold is set, and every one goes to a human approver (see step 6 of Configuring the request form and its categories).

   A requester selects a band, not 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.

   If the compliance gate cleared automatically, the trace also names the auto-clearance rule that cleared it.

Note: Auto-approval acts on 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 remains 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 is a good test. 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 uses the budget band, and the bands come from the budget suite's per-currency band sets.

   Run this step only once a band with a To value 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. On a record-only category you see the event record with no workspace and no Start execution action.

   On a category mapped to a create behavior you see the workspace, either already created or waiting on Start execution.

   Confirm the record also has 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 with the event in their scope.

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