ACLs to allow external users to see change_requests in CSM portal widget

[Mark123]

I want to show customers/external users to see change_requests in CSM portal, but only those associated with their customer_account. Is this possible?

As a regulatory requirement, we need to show change_requests to (external) customer users, when they affect them. These changes will be to present Standard changes on Products. and used to notify and link users to release notes for the product.

We have configured a "Data Table from Instance Definition" widget to show on the CSM home page. 
That widget is then visible. but (despite having implemented temporarily, a very open ACL for change_Requests - all external users can read all change_request records for that account) we can't see ANY Changes in the CSM portal.  The Widget is blank.  


I know I need to update both:
- the filter to limit changes only to those related to the users customer(s)
- the ACLs to ensure external users can access ONLY changes related their own customer(s)

But no matter what I have tried, I cannot get any changes to show, to an external user.  (I can see changes when I log into CSM with an internal user.)  

Is the above an appropriate approach, or is there a better approach?   Does CSM portal, or Change_Requests, get blanket blocked from viewing in CSM portal. ie don't respect ACLs? 

We prefer to use change_requests and request tasks as we see value in and intend to implement change management for Products using those records anyhow.  

We need to show notifications to customers only at the time their product is updated, which is why we've preferred not to use Announcements in CSM.  

[vaishali231 · Accepted solution]

hey @Mark123 
This behavior is expected. Even with open ACLs, change_request records are not reliably visible to external users in CSM Portal because Change Management is not designed for customer-facing access.

So the issue is not just ACLs, but also:

• Missing customer relationship
• Portal security layers (User Criteria, roles)
• Table not being portal-ready

  Approach 

Instead of exposing change_request directly, create a customer-facing proxy table and sync relevant data.

 Why this works

• Full control over what customers see
• Clean separation of internal vs external data
• Avoids portal/security limitations
• Scalable and upgrade-safe

 Example Implementation

1. Create Custom Table

Example: u_customer_change

Fields:

• u_change (Reference - change_request)
• u_customer_account
• u_short_description
• u_state
• u_planned_start_date

2. Business Rule (Sync Data)

When: After Insert / Update on change_request

(function executeRule(current, previous) {
   var cust = current.u_customer_account; // or derive via CI/Product

   if (!cust)

       return;

   var gr = new GlideRecord('u_customer_change');

   gr.initialize();

   gr.u_change = current.sys_id;

   gr.u_customer_account = cust;

   gr.u_short_description = current.short_description;

   gr.u_state = current.state;

   gr.u_planned_start_date = current.start_date;

   gr.insert();

})(current, previous);

3. ACL (on u_customer_change)

answer = current.u_customer_account == gs.getUser().account;

4. Portal Widget

Use Data Table widget on u_customer_change
Filter example:

u_customer_account = javascript:gs.getUser().account

*************************************************************************************************************************************

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