This guide explains 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 describes the three mechanisms that keep an approval moving.
Each role sees 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, the mechanisms that keep approvals moving, and each compliance reviewer's personal queue are the approval and workflow half of the suite.
- When a request is routed to you, you get the Request submitted notification by email.
The request record itself shows the "why this approver" trace, so you can see which rule brought it to you.
- 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.
- You can also work your queue in Onomi 360: open Event requests and select My approvals, which lists every request waiting on your decision.
Each row shows what you need 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 are 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.
- 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 remains In review and the next-level approver is notified.
If the compliance gate was triggered, 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. You can verify your action by opening 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, not a person, places one shared approval. It appears in the personal My approvals queue of every holder with the request in their scope.
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, you can 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 remain with you. Every request approved under a delegation records the delegation on its trail.
A delegation passes your own items only. If 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, not approval. Administrator access on its own gives no approval right. 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.
If the level names a role, the shared approval escalates as a whole.
A budget approval escalates to the next approval level, or to your organization administrators if 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 have 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 on its own gives no approval right and no edit access in any module.
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. The role assignment and the selection remain 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. If the rule that matched names a role with no holder in the request's scope, the request remains 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 role assignment is corrected.
Your compliance review queue
A request that triggers the compliance gate has 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 in your queue, even when it falls outside your normal scope.
Your scope still bounds every other event record you 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 lists one kind of work: requests awaiting your compliance decision.
A venue rule's result is recorded on the venue itself, not decided by a reviewer, so no venue decision appears in 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).
- 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. You see every pending compliance approval routed to a reviewer group you belong to.
Any reviewer in that group can act, and the first decision completes the shared approval for the group.
- Open a request to read its record: the submitted field values, the "why this approver" trace, and the state of the budget chain.
- 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.
- 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 remains 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.
Comments
0 comments
Please sign in to leave a comment.