Notifications based on the approval

[PALAVALASAB]

Hi guys,

I need to send a notification to the remaining approvers once an approver approves or rejects a RITM. The notification content should differ based on whether the request was approved or rejected.

For example, if there are two approvers for a RITM and one of them approves it, the other approver should receive a notification stating that the request has been approved and no further action is needed.

[PALAVALASAB]

Hi @MaxMixali ,

where can I write the script for recipients, I can't find any tab for the scripting.

[MaxMixali]

ServiceNow – Notify Remaining Approvers When One Approver Acts on a RITM
Requirement
Send an email to all remaining approvers when an approver Approves or Rejects a Requested Item (RITM). The message must differ for Approved vs Rejected and should tell remaining approvers that no action is needed.

Approach A (Recommended): Flow Designer on sys_approval_approver
-----------------------------------------------------------------
Why: Easy to maintain; works for single and multiple approvers; no custom mail code.

1) Trigger
- Table: sys_approval_approver
- When to run: On Update
- Condition: State changes to Approved OR Rejected
(Use the “Updated to value” condition on the State field)

2) Get the parent RITM
- Action: Look Up Record
- Table: sc_req_item
- Condition: sys_id = current.sysapproval

3) Find remaining approvers
- Action: Look Up Records
- Table: sys_approval_approver
- Conditions:
• sysapproval = (RITM sys_id from step 2)
• state = requested
- Store results in data pill array, e.g., remainingApprovers

4) Branch by decision (Approved vs Rejected)
- IF current.state == approved → Send Notification “RITM Approved – FYI”
- ELSE IF current.state == rejected → Send Notification “RITM Rejected – FYI”

5) Send Notification action (two separate actions or one with dynamic template)
- Recipients: Map to remainingApprovers.approver (user)
- Subject/Body examples:
• Approved: “Request ${RITM.number} approved. No further action required.”
• Rejected: “Request ${RITM.number} rejected. No further action required.”

Notes:
- Add guards to avoid sending if there are no remaining approvers.
- If you use Group approvals, filter only “requested” individuals (expand approvals) or handle group logic separately.

Approach B: Notification on sys_approval_approver with Scripted Recipients
--------------------------------------------------------------------------
1) Create two Notifications (Table: sys_approval_approver)
- “Notify Remaining Approvers – Approved”
• Condition: [State] changes to “approved”
- “Notify Remaining Approvers – Rejected”
• Condition: [State] changes to “rejected”

2) Scripted Recipients (same script in both; content differs per notification)
```javascript
(function () {
var recipients = [];
// Guard: ensure this is for a RITM
var ritm = new GlideRecord('sc_req_item');
if (!ritm.get(current.sysapproval)) return recipients;

var others = new GlideRecord('sys_approval_approver');
others.addQuery('sysapproval', current.sysapproval);
others.addQuery('state', 'requested'); // remaining approvers
others.query();
while (others.next()) {
if (others.approver && others.approver.email)
recipients.push(others.approver.toString());
}
return recipients;
})();
```

3) Email templates
- Approved template: Short FYI, “no action required”
- Rejected template: Short FYI, “no action required”
- Include key info: ${current.sysapproval.number}, ${current.sysapproval.short_description}

Approach C (Programmatic): Business Rule + GlideEmailOutbound (if you must)
---------------------------------------------------------------------------
Table: sys_approval_approver | When: after update
Condition: current.state changes AND (approved OR rejected)
Script:
```javascript
(function executeRule(current, previous) {
if (current.state == previous.state) return;

// Only process RITM approvals
var ritm = new GlideRecord('sc_req_item');
if (!ritm.get(current.sysapproval)) return;

var others = new GlideRecord('sys_approval_approver');
others.addQuery('sysapproval', ritm.sys_id);
others.addQuery('state', 'requested');
others.query();

while (others.next()) {
var mail = new GlideEmailOutbound();
mail.setFrom(gs.getProperty('glide.email.username'));
mail.setTo(others.approver.email);
if (current.state == 'approved') {
mail.setSubject('Request ' + ritm.number + ' approved – no action required');
mail.setBody('FYI: Request ' + ritm.number + ' has been approved by another approver. No further action is needed.');
} else if (current.state == 'rejected') {
mail.setSubject('Request ' + ritm.number + ' rejected – no action required');
mail.setBody('FYI: Request ' + ritm.number + ' has been rejected by another approver. No further action is needed.');
}
mail.send();
}
})(current, previous);
```

Edge Cases & Tips
-----------------
- Parallel vs. serial approvals: The above logic targets remaining “requested” approvers; serial flows usually don’t leave others pending.
- Group approvals: If you use group approvals, expand approvers to individuals first or adapt logic to target group members still “requested”.
- Re-approval loops: Add a guard (e.g., business rule/Flow state change check) so reopens don’t resend spam.
- Work notes: Optionally add a work note to RITM documenting the notification.
- Performance: Prefer Flow Designer and Notifications over custom email loops for maintainability and logging.

TL;DR
-----
Trigger on sys_approval_approver state change → find remaining “requested” approvers → send state-specific FYI that no action is needed. Do it in Flow Designer (simplest), or use a Notification with Scripted Recipients.