What is the best way to block users from promoting an incident to P1/P0

[CarolMa6]

Hi,

I’m trying to stop normal users from escalating incidents to P1/P0. Only the Service Desk should be able to do this.
Right now, I’m using a client script to remove the High Impact and High Urgency options, but this only works when the form loads, and users can still bypass it through list edits or other update methods.

What is the best and most secure solution to properly block users from escalating an incident to P1/P0?
Should this be handled with field‑level ACLs, a Business Rule, or both?

Regards 

CarolMa

[vaishali231 · Accepted solution]

hey @CarolMa6 

Hello,

This is expected behavior. A client script is not a secure control and should never be used to enforce priority restrictions.

Client scripts only work on the form UI. Users can still escalate incidents using list edit, REST API, imports, background scripts, mobile, or integrations. That’s why you’re seeing this gap.

approach

The only reliable solution is a server-side Business Rule.
Client scripts can stay, but only for UX, not enforcement.

Solution

1. Before Update Business Rule

Create a Before Update Business Rule on the Incident table to block P1/P0 escalation for non–Service Desk users.

This will protect all update paths, not just the form.

Condition: Priority changes

Script

(function executeRule(current, previous) {

// Check if priority is being escalated to P1 or P0
var isEscalating =
current.priority.changesTo('1') ||
current.priority.changesTo('0');

// Allow only Service Desk users
var isServiceDesk = gs.hasRole('service_desk'); // update role if needed

if (isEscalating && !isServiceDesk) {
gs.addErrorMessage(
'Only the Service Desk is allowed to escalate incidents to P1 or P0.'
);
current.setAbortAction(true);
}

})(current, previous);

2. Client Script (Optional – UX only)

You can keep your client script to hide High Impact / High Urgency options.
This improves user experience but should never be treated as security.

3. ACLs (Optional – Advanced)

ACLs can be added as an extra layer, but they increase complexity.

If used:

Apply ACLs on Impact and Urgency fields

Restrict write access to High values for non-Service Desk roles

Note: ACLs can break integrations if not carefully designed.

*************************************************************************************************************
If this response helps, please mark it as Accept as Solution and Helpful.
Doing so helps others in the community and encourages me to keep contributing.

Regards
Vaishali Singh

[Dr Atul G- LNG]

Out of the box, any ITIL user can propose  an incident to P1 or P0. If you want to restrict this, it would be better to create a Business Rule for that.

[Ankur Bawiskar]

@CarolMa6 

Do this as recommended approach

-> Create list_edit ACL for Impact and Urgency fields and only allow some users to edit by checking if logged in user belongs to Service Desk group

OR

You can use before update BR on incident and restrict the update

Condition: Impact Changes OR Urgency Changes

Script:

(function executeRule(current, previous /*null when async*/ ) {

    // Add your code here
    if (!gs.getUser().isMemberOf('Service Desk Group')) {
        gs.addErrorMessage('You cannot escalate INC');
        current.setAbortAction(true);
    }

})(current, previous);

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankur Bawiskar]

@CarolMa6 

I will recommend using list_edit ACL so that it's low-code, no-code and no Before Update BR is required.

Thank you for marking my response as helpful.

As per new community feature you can mark multiple responses as correct.

💡 If my response helped, please mark it as correct ✅ as well so that this helps future readers find the solution faster! 🙏