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.

[Ankur Bawiskar]

@PALAVALASAB 

so what did you start with and where are you stuck?

[Bhuvan]

@PALAVALASAB 

If you have Flow Designer Flow for this, create Flow logic based on the approval status and send email notifications accordingly.

If you have configured Flow but it is not working, share more details.

If this helped to answer your query, please mark it helpful & accept the solution.

Thanks,

Bhuvan

[MaxMixali]

ServiceNow – Notification to Remaining Approvers on RITM Approval or Rejection

Requirement
When one approver acts (approves or rejects) a Requested Item (RITM), send a different notification to the *remaining* approvers to inform them of the action taken and whether further action is needed.

Solution Overview
This can be achieved using a combination of:
1. Flow Designer or Workflow to detect approval state change.
2. Notification with scripted recipients or notification trigger script.
3. Optional: business rule on sys_approval_approver table.

Approach 1 – Flow Designer (recommended)
------------------------------------------------------------
1. Create or modify the existing RITM Approval Flow:
- Trigger: Table = sc_req_item (RITM), Condition = Approval state changes.
- Add a “Wait for condition” action → Wait until “Approval state changes” from “requested” to “approved” or “rejected”.

2. Add “Lookup Records” Action:
- Table: sys_approval_approver
- Conditions:
* parent = current RITM
* state = requested (to capture remaining approvers)
- Store results in a variable (e.g., remainingApprovers).

3. Add “If / Else” logic based on the Approval State:
IF Approval State == "approved" → send “Approved Notification”.
IF Approval State == "rejected" → send “Rejected Notification”.

4. Add a “Send Notification” action:
- Recipients: remainingApprovers.sys_user
- Subject/Body examples:

**Approved Notification Example:**
Subject: Request ${current.number} Approved
Body: Hello ${recipient.name},

The request ${current.number} has been approved by another approver. No further action is required.

Thank you.

**Rejected Notification Example:**
Subject: Request ${current.number} Rejected
Body: Hello ${recipient.name},

The request ${current.number} has been rejected by another approver. No further action is required.

Please contact the requestor for additional information.

Approach 2 – Business Rule on sys_approval_approver
------------------------------------------------------------
1. Table: sys_approval_approver
2. When: after update
3. Condition: current.state changes to “approved” OR “rejected”.
4. Script:

(function executeRule(current, previous) {
if (previous.state == current.state)
return;

// Only run if approval is for RITM
var ritm = new GlideRecord('sc_req_item');
if (!ritm.get(current.sysapproval))
return;

// Get remaining approvers
var approvers = new GlideRecord('sys_approval_approver');
approvers.addQuery('sysapproval', ritm.sys_id);
approvers.addQuery('state', 'requested');
approvers.query();
while (approvers.next()) {
var mail = new GlideEmailOutbound();
mail.setFrom(gs.getProperty('glide.email.username'));
mail.setTo(approvers.approver.email);
if (current.state == 'approved') {
mail.setSubject('Request ' + ritm.number + ' Approved');
mail.setBody('The 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');
mail.setBody('The request ' + ritm.number + ' has been rejected by another approver. No further action is needed.');
}
mail.send();
}
})(current, previous);

Approach 3 – Email Notification Record
------------------------------------------------------------
If you prefer to use standard notifications:
1. Create two notifications:
- “Notify Remaining Approvers – Approved” (condition: Approval.state changes to Approved)
- “Notify Remaining Approvers – Rejected” (condition: Approval.state changes to Rejected)
2. Table: sys_approval_approver
3. Condition: current.state == 'approved' or 'rejected'
4. Scripted Recipient (in the notification):
```js
var recipients = [];
var others = new GlideRecord('sys_approval_approver');
others.addQuery('sysapproval', current.sysapproval);
others.addQuery('state', 'requested');
others.query();
while (others.next()) {
recipients.push(others.approver);
}
recipients;
```
5. Notification Body: customize per state.

Best Practice Recommendations
------------------------------------------------------------
- Prefer Flow Designer for maintainability.
- Avoid hardcoding approvers or emails.
- Include logic to handle group approvals if needed.
- Ensure notifications do not trigger if all approvals are completed.

Summary
------------------------------------------------------------
- Trigger on approval state change (sys_approval_approver).
- Identify remaining approvers where state = "requested".
- Send state-specific notifications (“Approved” vs. “Rejected”).
- Best to implement using Flow Designer for clarity and upgrade safety.

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