Configuring notifications for requests and approvals

Every notification the request and approval suite sends is maintained on the Notifications tab in Policies in Onomi 360. This guide covers that tab: the lifecycle templates and their triggers, the per-language maintenance, the reminder cadence and the escalation it drives, and how long email action links stay valid. The work each notification announces is documented in the other guides in this series.

Notifications

Onomi 360's notification engine sends two families of notification about a request, its event, and its budget. Only the first is configured here.

The lifecycle templates

The lifecycle templates are the ones on this Notifications tab. A status change on a request, or on the event it creates, sends a template to defined recipients. Reminders keep pending approvals and open reconciliations moving.

They are triggered by a status change on a request or on the event it creates. Four exceptions fire on their own triggers, and each is marked in the template list below:

The budget-policy notifications

The budget-policy notifications are the second family. They are a threshold policy on a cost-line save, a blank-cost policy, the over-band flag, a refused sourcing-award write, and the Meal cap exceeded flag raised at reconciliation.

They fire on an action rather than on a status change. The actions are a cost-line save, the reconciliation check behind the Meal cap exceeded flag, and a platform write the budget refused.

The reconciliation check is evaluated whenever the reconciled actuals on the counting categories change. That is on Mark reconciled, which brings that line's Actual amount into the sum. It is also on a later cost-line save that changes the Actual amount on a line already marked reconciled.

Four things make the budget refuse a platform write:

• no category carrying the Sourcing award target the award needs;
• a retired target category;
• an award currency differing from the event's budget currency; and
• a budget header carrying no band and no budget currency.

All four notify the event's finance owner, with the Finance owner not set hold on the budget header where no owner has been named.

Their recipients come from the policy that raised the notification, rather than from a template on this tab. For the reconciliation flag they come from the threshold policies kept in the event's budget currency, whose scope covers a category that counts toward the meal cap. Where neither applies, the Finance owner field on the budget header supplies them. They are documented in How to use the Budget module.

Messages that carry no template on this tab

A message a module sends to a registrant, to a guest, or to a travel team belongs to neither family, and carries no template on this tab. Three of them come from the event's Travel module:

• To a registrant. The delegated travel step, as a link to a standalone travel page.
• To a travel team. A routed travel request, sent to the team's Destination, which can be a team email address.
• To a guest. On a room block created from a sourcing award, an attendee confirmation link for their stay and requirements. It is sent on the sourcing connection when that guest's room is claimed during registration, or assigned to them by a planner.

All three are documented in How to manage travel and accommodation for your event.

Editing the templates and the reminder cadence

1. In Onomi 360, open Policies, then open the Notifications tab. The templates are listed by what triggers them. That is a status change on a request or on the event it creates, except for the four exceptions above. Each exception states its own trigger in its entry:
   • Request submitted: to the approver at the first level of the rule that routed the request. Where that level names a role, it goes to every holder of the role whose scope covers the request. Where the compliance gate fires, it also goes to every reviewer in the group the gate routed to. Where several people receive it, they hold one shared item in their personal queues. Whoever acts first acts for the level, and the item leaves the other queues. This is the email that carries the inline Approve and Decline actions.
   • Approval required: to the approver at the next level, when the previous level approves. Where that level names a role, it goes to every holder of the role whose scope covers the request. It fires when a level of the matched approval rule completes while the request stays In review, rather than on a status change.
   • Request approved: to the requester, when every required approval is in place.
   • Request declined: to the requester, including the decline reason.
   • Request resubmitted: to the routed approvers, when a declined request re-enters routing.
   • Reminder: to every approver with the approval still pending, and to every compliance reviewer whose personal queue contains the pending approval. At a level naming a role, that is every holder of the role whose scope covers the request. It repeats on the cadence you set below until an approver or a reviewer acts. Its subject line carries the request's category and budget band, so an approver reading on a phone can tell one waiting request from another before opening it.
   • Request withdrawn: sent when the requester withdraws the request and it moves to Withdrawn. It goes to every approver holding a pending approval on the request, and to every compliance reviewer whose personal queue contains its pending compliance approval. It is what tells them the item has left their queue. Those two are the whole of its reach (see Submitting, tracking, and withdrawing a request and Approving requests and working your review queue).
   • Approval escalated: sent when a request escalates after three reminder cycles without action. It goes to whoever the escalation reaches: the approver at the next approval level, or your organization administrators where no further level exists. The approver who did not act is copied.
   • Event cancelled: sent when an approved or in-execution event moves to Cancelled. It goes to the approvers who approved the request, the event's finance owner, and the planners of the event's workspace. Registrants are reached separately, through the workspace's own communications. The venues on an active or awarded sourcing request are reached through the sourcing flow (see How to source a venue from your event).
   • Reconciliation reminder: to the event's finance owner, from the passing of the End date on the event record. On a cancelled event it runs from the cancellation. It runs while the closure has not been recorded, whether or not the budget carries unreconciled cost lines. No status change triggers it, because no status marks the end of the event. The request status stays In execution, or Approved on a record-only event, until the closure is recorded. It repeats on the Reminder frequency you set below until the closure is recorded.

     The event's finance owner is its only default recipient, and the Finance owner field has no default. While the field is empty, the reminder is held rather than sent elsewhere. It goes out as soon as an owner is named, on the same footing as the held budget-policy notifications that address the owner. That reminder is the only thing driving a record-only meeting to closure. An organization running record-only categories at volume therefore names the finance owner on each record-only event as the record is created. No meeting on that lane then sits with the field empty and its reminder held. The field belongs at approval rather than at closure.

     An event with nobody named shows that state on its own budget header, which carries a Finance owner not set indicator while the field is empty. See How to use the Budget module.

2. Open a template to edit its subject and text, and to add or remove recipients. Requesters and routed approvers are the default recipients of their own templates. Add further recipients where you need them. Templates are maintained per language: each language your organization enables carries its own subject and text. Which language a given notification sends in, and which recipients that reaches, is documented in Languages on the meeting request portal and notifications, in Running multilingual events across global markets. That section also covers how to plan the translation work against it.
3. In the Reminders setting, keep Send reminders on (the default) and set the Reminder frequency. By default a reminder is sent every two days until the approver acts. After three reminder cycles without action, the request escalates (see Delegation, reassignment, and escalation in Approving requests and working your review queue).

   The same frequency governs the Reconciliation reminder. That reminder has no escalation, because there is no further level to escalate a reconciliation to.

   Send reminders governs the approval reminder cycle only. Switching it off stops the Reminder template and the escalation that follows it. It leaves the Reconciliation reminder running on the Reminder frequency. That separation is deliberate. On a record-only meeting the reconciliation reminder is the only thing driving the record to closure, and retention runs from the closure it drives toward.

4. Email approve and decline links remain valid for 30 days. Links are single-use and act only for the approver they were addressed to.
5. Select Save. Edited templates apply from the next notification sent.

Note: The approver notification email carries inline email approve and decline actions, with no login required. The approver flow in Approving requests and working your review queue describes how they work.

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.