Restrict Access to Change Request records in SOW

[grosss]

Hello,

Our change request process is very customized and if someone were to submit a request via SOW, it bypasses all of our business rules, mandatory fields, etc.. The product owner is wanting to lock down access to change management in SOW until we revamp our process and bring it back to OOB.  

I have attempted to put conditions and audiences on the Record>SRP Record and Record> Record SNC page variants and it worked, but it blocked access to all records on all tables, even though I had the condition set to table is change_request. I have also created copies of those variants and tried to set the condition and audience and my user was still able to access it. 

I have tried ux_route and ux_page ACLs and those have not worked either. 

Appreciate any help!

[Matthew_13]

Hi grosss - This is expected behavior in SOW. The Record (SRP) route and page variants control how records render, not whether a user can access them, and that route is shared across many tables. That’s why conditioning it on change_request ended up affecting other records as well.

If the goal is to temporarily lock down Change in SOW, the most reliable approach is:

• Remove Change entry points from the SOW workspace (lists, navigation, data resources) in UI Builder so users can’t access Change from the workspace UI.

• Enforce access via ACLs on change_request (read/create/write) for non-Change roles to prevent deep-link access.

Page variants, audiences, and ux_route / ux_page ACLs generally aren’t effective for restricting table-level access in this case.

Longer term, once you revisit the process, it’s worth ensuring mandatory fields and business rules are enforced server-side so they apply consistently across Classic UI, SOW, and APIs.

Hope this helps, and happy to clarify further if needed.

@grosss - Please give a heads up as well as Accepted solution if you find helpful my friend!