Buttons not working & form read-only for ITIL users in Service Operations Workspace(Remediation task

[kushagrasingh]

Hi all,

I’m working on the Vulnerability Response (VR) module and facing an issue in Service Operations Workspace (SOW).

Setup:

• We have both Security Operations Workspace (SecOps) and Service Operations Workspace (SOW).
• Users with ITIL role have access to SOW.
• I added Remediation Tasks to the list view in SOW.
• The Remediation Task record page is configured as “Configurable across experiences”.
• Users with Vulnerability-related roles (e.g., VR roles) can access and interact with Remediation Tasks in SOW without issues.

Problem:

• ITIL-only users can:
  • See the Remediation Task records in SOW
  • Open the record form
• However:
  • The form is read-only
  • Buttons are visible, but clicking them does nothing (no modal or action triggered)

Expected Behavior:
ITIL users should be able to interact with the form and use the action buttons (same as users with VR roles, based on access design).

What I’ve Checked:

• Record page is configurable across experiences
• UI visibility of buttons is fine (they appear for ITIL users)

Questions:

1. What could cause buttons (UI actions/modals) to not respond in SOW for certain roles?
2. Is this related to ACLs, UI Action conditions, or Workspace-specific client scripts?
3. How can I enable full interaction (edit + button actions) for ITIL users on Remediation Tasks in SOW?

Any guidance or pointers would be appreciated!

[Naveen20]

This is almost certainly a layered permissions issue, not a UI configuration problem. Here's the breakdown:

Root Cause (most likely): Remediation Tasks (sn_vul_remediation_task) are protected by scoped application ACLs from the Vulnerability Response plugin. ITIL role alone doesn't grant write access to VR tables — the buttons render because UI Action visibility conditions pass, but the server-side execution fails silently because the user lacks write ACLs.

What to check, in order:

1. ACLs on sn_vul_remediation_task — Navigate to System Security > ACLs, filter by table. You'll likely find write and execute ACLs requiring roles like sn_vul.vulnerability_manager or sn_vul.vulnerability_analyst. ITIL users pass the read ACL but fail write/execute, which explains the read-only form and dead buttons.
2. UI Action conditions vs. ACL conditions — The buttons use a condition field (often just checking table/state) that controls visibility, but the actual script execution hits current.canWrite() or similar server checks. Buttons show but do nothing when the UI Action condition passes but the underlying GlideRecord operation is blocked by ACLs.
3. Workspace-specific declarative actions — In UI Builder, check if the record page variant for SOW uses declarative actions with server-side eligibility scripts that check for VR roles. These can silently suppress action execution even when the button renders.

How to fix -  Create a custom role that includes itil + the minimum required VR ACL roles (e.g., sn_vul.basic), then assign it to those users. This respects the scoped app's security model.

[Ankur Bawiskar]

@kushagrasingh 

any reason those users are not using dedicated workspace for VR and why are they using SOW?

this looks to be some kind of platform segregation when it comes to modules

Example: SOW is used for INC/PRB/CHG, HR Workspace for HR cases, CSM Workspace for CSM cases etc

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

[kushagrasingh]

Hi @Ankur Bawiskar ,
I have the requirement for ITIL to use the Remediation task page functionality (create change button, add to existing change etc.,) from the SOW workspace itself, and don't want to give any VR related roles to ITIL user.
The form is visible and editable by ITIL user in SOW now, however my biggest pain point now is I am unable to make the declarative actions work for ITIL user, (modal does'nt open on clicking the declarative form actions).
Any help here?