Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Getting error while creating P1 and P2 incidents alone!!

imranshaik0
Tera Contributor

Hi Community!!

Hope you all good!

Recently I had an interview. Interviewer asked me a strange question.

Question:
User was able to create P1 and P2 incidents before. And in a sudden, User wasn't able to create only P1 and P2 incidents to the particular group. And he can be able to create P3 and P4 incidents with the same group. User was getting an issue or error message with a word "Constraints" in it. ACLs are fine and BRs are also fine. Then what can be the issue. What is the issue here??

When I checked the community with this question. I found some of the answers suggesting using the current.update() in the before BR. But interviewer mentioned that BRs are fine. I suspect Data policies can be the issue. But I need some suggestions here. Can anyone share your thoughts here.

1 ACCEPTED SOLUTION

Anupam1
Kilo Guru

Hi @imranshaik0 ,

The most likely cause of this issue is a Data Policy or Reference Qualifier constraint that restricts P1/P2 incident creation for that group—especially if the error message includes the word “Constraints” and ACLs/Business Rules are confirmed to be fine.

 

Breakdown of the Scenario

  • User could previously create P1/P2 incidents for a specific group.
  • Suddenly blocked, but still able to create P3/P4 for the same group.
  • Error message includes “Constraints”.
  • ACLs and Business Rules are confirmed to be working correctly.

This points to a data-level restriction, not logic-level.

 

Likely Root Causes

  1. Data Policy
  • A Data Policy may be enforcing a condition like:

“If Priority is P1 or P2, Assignment Group must be X or user must have role Y.”

  • These policies run on insert/update and can block record creation silently or with vague errors.
  • Check under System Policy > Data Policies for any rules targeting incident.priority or assignment_group.
  1. Reference Qualifier on Assignment Group
  • The Assignment Group field may have a dynamic reference qualifier that filters groups based on priority.
  • For example:
  • javascript:priority != '1' && priority != '2'
  • This would prevent certain groups from appearing when P1/P2 is selected, causing a constraint error if the group is manually set.
  1. UI Policy or Client Script
  • A UI Policy or Client Script might be hiding or disabling fields based on priority.
  • If the field is required but hidden, it can trigger a constraint error on save.
  1. Table Constraint or Dictionary Attribute
    • Check the dictionary entry for the incident table or priority field.
    • There may be a table-level constraint or attribute like dependent_fields that restricts values based on other fields.

 

 How to Troubleshoot

  1. Try creating the incident manually with P1/P2 and the target group.
    • See if the group is selectable.
    • Check browser console for client-side errors.
  2. Review Data Policies:
    • Look for any condition involving priority == 1 || priority == 2.
  3. Inspect Reference Qualifiers:
    • Go to the dictionary entry for assignment_group.
    • Check if a script or condition filters based on priority.
  4. Temporarily disable UI Policies/Client Scripts:
    • Especially those tied to priority or assignment_group.
  5. Use Script Debugger or Logging:
    • Add logging to before insert Business Rules to confirm execution path.

 

  

If my response helped please mark it correct and close the thread so that it benefits future readers.

 

Thanks,

Anupam.

 

 

View solution in original post

2 REPLIES 2

ReginaldFawcett
Tera Guru

The first thing I would check is the UI Policies and Data Policies for the Incident table.

Anupam1
Kilo Guru

Hi @imranshaik0 ,

The most likely cause of this issue is a Data Policy or Reference Qualifier constraint that restricts P1/P2 incident creation for that group—especially if the error message includes the word “Constraints” and ACLs/Business Rules are confirmed to be fine.

 

Breakdown of the Scenario

  • User could previously create P1/P2 incidents for a specific group.
  • Suddenly blocked, but still able to create P3/P4 for the same group.
  • Error message includes “Constraints”.
  • ACLs and Business Rules are confirmed to be working correctly.

This points to a data-level restriction, not logic-level.

 

Likely Root Causes

  1. Data Policy
  • A Data Policy may be enforcing a condition like:

“If Priority is P1 or P2, Assignment Group must be X or user must have role Y.”

  • These policies run on insert/update and can block record creation silently or with vague errors.
  • Check under System Policy > Data Policies for any rules targeting incident.priority or assignment_group.
  1. Reference Qualifier on Assignment Group
  • The Assignment Group field may have a dynamic reference qualifier that filters groups based on priority.
  • For example:
  • javascript:priority != '1' && priority != '2'
  • This would prevent certain groups from appearing when P1/P2 is selected, causing a constraint error if the group is manually set.
  1. UI Policy or Client Script
  • A UI Policy or Client Script might be hiding or disabling fields based on priority.
  • If the field is required but hidden, it can trigger a constraint error on save.
  1. Table Constraint or Dictionary Attribute
    • Check the dictionary entry for the incident table or priority field.
    • There may be a table-level constraint or attribute like dependent_fields that restricts values based on other fields.

 

 How to Troubleshoot

  1. Try creating the incident manually with P1/P2 and the target group.
    • See if the group is selectable.
    • Check browser console for client-side errors.
  2. Review Data Policies:
    • Look for any condition involving priority == 1 || priority == 2.
  3. Inspect Reference Qualifiers:
    • Go to the dictionary entry for assignment_group.
    • Check if a script or condition filters based on priority.
  4. Temporarily disable UI Policies/Client Scripts:
    • Especially those tied to priority or assignment_group.
  5. Use Script Debugger or Logging:
    • Add logging to before insert Business Rules to confirm execution path.

 

  

If my response helped please mark it correct and close the thread so that it benefits future readers.

 

Thanks,

Anupam.