Hi @MacharlaV ,
Based on the screenshots, you are using the legacy Major Incident Workbench from UI16 rather than the Service Operations Workspace PIR experience.
There are two important points here.
1. The PIR Edit buttons are not normal UI Actions
The Overview / Findings Edit buttons inside the legacy Major Incident Workbench are not separate sys_ui_action records where you can simply add a Condition.
The Workbench itself is implemented through the OOB Major Incident Management workbench framework. ServiceNow even references the "workbench" Object UI Page in its Major Incident Management fixes.
For the legacy Post Incident Report, the documented OOB behavior is:
Incident State = Resolved
+
User is a Major Incident Manager
-> PIR can be edited
Therefore, searching normal UI Actions, Client Scripts or the standard Incident form UI Pages will not expose an individual "Edit Overview" or "Edit Findings" UI Action.
2. There is no documented OOB assignment-group extension point for those legacy buttons
I would not modify:
- workbench UI Page
- protected Major Incident Script Includes
- internal Workbench JavaScript
- DOM/CSS to hide the Edit buttons
Those approaches are upgrade-sensitive.
Recommended solution on Australia:
Use the Post Incident Report functionality in Service Operations Workspace.
Australia SOW supports PIR Co-contributors.
The OOB access model is:
PIR Review
-> Incident read/write access
PIR Update
-> Major Incident Manager
OR
-> Incident write user added as a Co-contributor
OR
-> Admin
Most importantly, the Co-contributors field supports:
Users
or
User Groups
Therefore your requirement maps quite well to the OOB design.
You can use:
Incident Assignment Group
-> PIR Co-contributor group
Then:
Member of Incident Assignment Group
+
appropriate incident write role
-> Can update PIR
Other users
-> Can continue to review PIR
-> Cannot update it
Conceptually:
Major Incident resolved
|
v
Post Incident Report
|
v
Co-contributors
|
v
Incident.assignment_group
|
+---- Group member + write access
| -> Can edit PIR
|
+---- Other user
-> Read/review only
This is much better than trying to hide the legacy Workbench buttons.
If required, you can automate adding the Incident Assignment Group as a PIR Co-contributor as part of your Major Incident process.
3. If you MUST remain on legacy Major Incident Workbench
Then I would separate UI visibility from actual security.
Even if you cannot reliably hide the OOB Edit button, you should protect the underlying PIR fields with field-level WRITE ACLs.
The PIR Overview, Findings and Timeline information is stored against the Incident and the same information is displayed on the Incident form under the Post Incident Report section.
Keep READ access unchanged.
Add WRITE restrictions only to the required PIR fields.
For example, the ACL script pattern would be:
answer = false;
if (!current.assignment_group.nil()) {
answer = gs.getUser().isMemberOf(
current.assignment_group.toString()
);
}
Meaning:
Logged-in user belongs to Incident Assignment Group
-> Write allowed
Not a member
-> Write denied
Do this only on the specific PIR fields, not:
incident.write
because a record-level Incident write ACL would affect much more than the PIR.
Important:
An ACL is the security control.
Hiding an Edit button is only a UI control and should never be treated as the actual authorization mechanism.
If the legacy Workbench still displays the Edit button after the ACL restriction, I would accept that limitation rather than customize protected Workbench code. The update should still be protected server-side.
4. Best option for Australia
Since you are already on Australia, my recommended architecture would be:
Service Operations Workspace
-> Post Incident Report
-> Co-contributors
-> Add Incident Assignment Group
-> Members with Incident write access can edit
-> Everyone else with read access can review
This gives you essentially the requirement OOB without modifying the Major Incident Workbench.
So to answer your questions directly:
Which OOB component controls the legacy buttons?
-> They are rendered as part of the Major Incident Workbench/PIR implementation, not as standalone Incident UI Actions.
Is there an OOB extension point to add Assignment Group conditions?
-> I could not find a documented supported extension point for the legacy Workbench Edit buttons.
Recommended customization?
-> Prefer the Australia SOW PIR Co-contributor model and add the Incident Assignment Group as the contributor group.
If remaining on legacy Workbench:
-> Enforce write access on the underlying PIR fields using ACLs rather than modifying OOB Workbench code.
Hope this helps!
If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.
Kind Regards,
Abhishek Pal
