Approving requests and working your review queue

This guide covers the approver's and the compliance reviewer's work: acting on a routed request from the notification email or from a personal queue in Event requests. It also covers the three mechanisms that keep an approval moving.

Each role reads the same records through its own view. My approvals lists requests waiting on your decision as an approver. My compliance reviews lists compliance approvals routed to you because you belong to the matching reviewer group. The requester's own list, My requests in the portal, is covered in Submitting, tracking, and withdrawing a request. How the routing behind all three is configured is covered in Configuring approval routing, the compliance gate, and auto-approval.

Approving a request

Approval and workflow. The approver flow below and the mechanisms that keep approvals moving are the approval and workflow half of the suite. So is each compliance reviewer's personal queue.

1. When a request routes to you, the Request submitted notification arrives by email. The request record itself shows the "why this approver" trace, so you can see which rule brought it to you.
2. Select Approve or Decline directly from the email; no login is required. Approve records your approval and shows a confirmation page with the request's new status. Decline first opens a page asking for your reason. A decline cannot be saved without one ("A reason is required to decline this request."). The reason is shown to the requester and stays on the record.

   Each email action link is single-use, expires after 30 days, and acts only as the approver it was addressed to. A forwarded link does not let someone else act. A link that has been used, has expired, or was forwarded shows "This approval link is no longer valid. Open the request in Onomi 360 to act on it." Act from Event requests instead.

3. Alternatively, work your queue in Onomi 360: open Event requests and select My approvals, which lists every request waiting on your decision. Each row carries what it takes to decide: the requester, the request category, where and when the meeting is, the budget band and whether HCPs attend, and how long the request has been waiting. Anything past the 10-day first-decision target is flagged. Filter to Past the 10-day target to clear the late ones first.

   Approve and Decline sit on the row, and Decline asks for its reason before it records anything. To see the full field set, the "why this approver" trace, and the compliance panel before deciding, open the request and act from the record. Acting from the email, from the row, and from the record all land in the same log.

   

4. What happens next depends on the chain. If yours was the last required approval, the request moves to Approved and the requester is notified. If the rule has further levels, the request stays In review and the next-level approver is notified. If the compliance gate fired, the request completes review only when the compliance approval is also in place.

Reminders arrive on the configured cadence while a request waits on you. To verify your action, open the request in Event requests. The log shows your approval or decline with the timestamp and, for a decline, the reason.

Delegation, reassignment, and escalation

Three controls keep an approval moving while the person it is waiting on is unavailable: delegation, reassignment, and escalation.

An approval level that names a role, rather than a person, places one shared approval. It sits 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. The mechanisms below all work on that approval.

• Delegation. Before an absence, delegate your approvals for a date range: in Event requests, open My approvals, select Delegate, and set the delegate and the dates. Requests routing to you during the range go to your delegate. Approvals already pending when the range starts stay with you. Every request approved under a delegation records the delegation on its trail. A delegation passes your own items only. Where the shared approval appears in several personal queues, the other holders keep it unchanged, and your delegate joins them for the range. You hold one delegation at a time, so ranges cannot overlap. Entering dates that overlap an existing delegation shows "You already have a delegation covering these dates. Edit that delegation or choose a different range."
• Reassignment. Organization administrators can reassign a pending approval to another holder of the role the approval requires, for example when an approver has left the organization. The reassignment is recorded on the request. Reassignment is administration rather than approval. Administrator access carries no approval right of its own. Reassigning a shared approval removes it from the original personal queues, and places it in the new holder's queue.
• Escalation. After three reminder cycles without action, the request escalates. The Approval escalated notification goes to whoever the escalation reaches, and the escalation is recorded in the trail. Where the level names a role, the shared approval escalates as a whole rather than one holder being singled out. A budget approval escalates to the next approval level, or to your organization administrators where no further level exists. A pending compliance approval in a reviewer group escalates to the organization administrators, because a gate approval has no further level.
• What an administrator does with an escalation. Organization administrators hold organization-wide visibility of requests in Event requests, for administration only. They open an escalated or stalled request, and reassign a pending approval to another holder of the required role. They also re-route a request that could not be routed. Administrator access carries no approval right and no module write of its own.

  An administrator opens the escalated request there and reassigns it. They select a holder of the role the approval requires: Approver for a budget approval, or Compliance reviewer for a compliance approval. The request moves to that person's queue. An administrator who does not hold the Approver role cannot approve the request, only reassign it. That keeps the grant and the selection separate here, as everywhere else in this configuration. Both the escalation and the reassignment are recorded on the request. The clause is documented in Role-based access and visibility for internal and external stakeholders.

• A request that could not be routed. Where the rule that matched names a role with no holder in the request's scope, the request stays Submitted with no approver holding it. It shows "This request could not be routed. The rule that matched names a role with no holder in this request's scope." Nothing announces it. No notification is sent, because the request changes no status and there is no approver to send one to. It enters neither the reminder cycle nor the escalation that follows, because reminders go to every approver with the approval still pending, and here there is none.

  Your administrators find these requests by looking for them, in Event requests under the organization-wide administrative visibility above, filtered to Submitted. A request that routed leaves Submitted as soon as routing completes. Submitted is therefore a transient status, and a row resting there is a request that did not route. Work that filter on a regular cadence: it is part of administering the module, in the same way as reviewing the approval rules themselves.

  An administrator resolves a row there by re-routing the request to a holder of the required role. The alternative is for the requester to withdraw it and submit again, once the rule or the grant is corrected.

Your compliance review queue

Requests that fire the compliance gate carry a separate compliance approval, independent of the budget chain. Policies defines the default reviewers and any scoped reviewer groups. A request routed to one of those groups appears in My compliance reviews for every reviewer in the group. It remains one shared approval: when one reviewer acts, it leaves the other reviewers' queues. A routed request is visible and workable by that reviewer, even when it falls outside their normal scope. The reviewer's scope still bounds every other event record they can read (see Configuring approval routing, the compliance gate, and auto-approval, and Role-based access and visibility for internal and external stakeholders).

My compliance reviews carries one kind of work: requests awaiting your compliance decision. A venue rule's result is recorded on the venue itself rather than decided by a reviewer, so no venue decision reaches this queue. A venue that a market's rules refuse is refused outright, and a listed venue is chosen instead (see Setting venue rules in Onomi 360).

1. You learn that an item is waiting from two notifications. The Request submitted notification goes to every reviewer in the routed group. The Reminder notification repeats on your organization's configured cadence until a reviewer acts.

   After three reminder cycles without a reviewer acting, the pending compliance approval escalates to your organization administrators. Their organization-wide view of Event requests exists for this kind of administration. They open the escalated request and reassign it to another holder of the Compliance reviewer role. They do that without holding an approval right of their own (see Delegation, reassignment, and escalation, and Role-based access and visibility for internal and external stakeholders).

   To work the queue, in Onomi 360, open Event requests, then select My compliance reviews. Every pending compliance approval routed to a reviewer group you belong to appears here. Any reviewer in that group can act, and the first decision completes the shared approval for the group.

2. Open a request to read its record: the submitted field values, the "why this approver" trace, and the state of the budget chain.
3. Select Approve, or Decline with a reason. Your action is recorded on the request's log as the compliance approval, separate from the budget approvals.
4. Because the gate is additive, the request moves to Approved only when every required approval is in place, budget and compliance alike. Until then it stays In review.

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.