Hi @suryaogeti1 ,
Try this and let me know
I would split this into two parts:
1. Flow Designer should handle the approval and notification.
2. A Business Rule should enforce that the Change cannot move out of New until peer review is approved.
Do not rely only on a Client Script popup, because users/integrations can still update the record from list edit, import, API, background script, etc. The validation should be server-side.
Recommended design:
Create these custom fields on change_request:
- u_custom
Type: True/False
Label: Custom / Peer Review Required
- u_peer_review_approved
Type: True/False
Default: false
- u_peer_review_state
Type: Choice
Choices:
not_requested
requested
approved
rejected
Flow Designer:
Trigger:
Table: Change Request [change_request]
When: Created or Updated
Conditions:
u_custom is true
State is New
u_peer_review_state is not approved
u_peer_review_state is not requested
Flow steps:
1. Update Change Request
u_peer_review_state = requested
u_peer_review_approved = false
2. Get the peer review approvers
If the approvers should come from Assignment group, use the Change assignment_group.
If it is a fixed peer review group, use that group sys_id.
Exclude the requester from the approver list. In Change this is usually requested_by or opened_by depending on your process.
Example logic for a custom Flow Action / Script step:
var approvers = [];
var grMember = new GlideRecord('sys_user_grmember');
grMember.addQuery('group', inputs.group_sys_id);
grMember.addQuery('user.active', true);
grMember.addQuery('user', '!=', inputs.requester_sys_id);
grMember.query();
while (grMember.next()) {
approvers.push(grMember.user.toString());
}
outputs.approvers = approvers.join(',');
3. If approvers are empty
Add a work note and stop the flow, or notify the Change admin group.
Example work note:
Peer review approval was required, but no valid approvers were found after excluding the requester.
4. Send notification to the group/users
You can use Send Email / Send Notification in Flow Designer, or rely on the standard approval notification if your instance already sends approval emails.
5. Ask for Approval
Record: Trigger record
Approval rule: Anyone approves
Approvers: approver users returned from step 2
Rejection rule: Anyone rejects
This satisfies the requirement that anyone from the team can approve, except the requester.
6. If approval is approved
Update Change Request:
u_peer_review_state = approved
u_peer_review_approved = true
Add work note:
Peer review approved. Change can now move from New to Assess.
7. If approval is rejected
Update Change Request:
u_peer_review_state = rejected
u_peer_review_approved = false
Add work note:
Peer review rejected. Change must remain in New until peer review is completed.
Business Rule to block state movement:
Create a before Business Rule on change_request.
When:
Before Insert and Update
Condition:
u_custom is true
Script:
(function executeRule(current, previous) {
// Confirm the New state value in your instance.
// In many Change implementations, New = -5.
var NEW_STATE = '-5';
var peerReviewRequired = current.u_custom == true || current.u_custom == 'true';
var peerReviewApproved = current.u_peer_review_approved == true || current.u_peer_review_approved == 'true';
if (peerReviewRequired && !peerReviewApproved && current.state.toString() !== NEW_STATE) {
gs.addErrorMessage('Peer review approval is required. Keep the Change in New state until it is approved, then move it to Assess.');
current.setAbortAction(true);
}
})(current, previous);
Optional Client Script for user experience:
You can also add an onChange Client Script on State to show the message immediately, but keep the Business Rule as the real enforcement.
function onChange(control, oldValue, newValue, isLoading) {
if (isLoading) {
return;
}
var NEW_STATE = '-5';
if (g_form.getValue('u_custom') == 'true' &&
g_form.getValue('u_peer_review_approved') != 'true' &&
newValue != NEW_STATE) {
g_form.setValue('state', NEW_STATE);
g_form.addErrorMessage('Peer review approval is required. Move the Change from New to Assess only after approval.');
}
}
Important points:
- Do not move the Change automatically to Assess unless that is really your process requirement. Usually it is better to allow the user to move it after approval.
- Do not use only a popup/client script for this. Use a before Business Rule to prevent invalid state changes.
- Be careful if your Change process already uses OOB approvals in Assess/Authorize. This peer review should be treated as a separate pre-approval in New state, so it does not conflict with the normal Change approval process.
- If using the standard approval field on change_request causes conflict with existing Change approvals, use a separate custom peer review state field and only use approval records/flow for the peer review step.
References:
- Ask for Approval action in Flow Designer:
https://www.servicenow.com/docs/bundle/zurich-build-workflows/page/administer/flow-designer/referenc...
- Change state model:
https://www.servicenow.com/docs/en-US/bundle/zurich-it-service-management/page/product/change-manage...
- Business Rules and abort action:
https://www.servicenow.com/docs/bundle/xanadu-application-development/page/script/business-rules/con...
Thank you,
Vikram Karety,
ServiceNow Architect,
Octigo Solutions INC
