- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
We have an issue where we are using a Data Table from Instance out of the box widget, and the table was pointed to Table A, but most of the columns that we show are from a reference field of Table B. Normally users were able to export the records with all the fields from what was shown on the columns, now it only exports all the fields from Table A?????
What could be the issue?
Lisa
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Thanks for the details — this behavior is expected when switching users from snc_internal to snc_external, and it’s not related to the glide.partial_record_optimizer.enabled property.
External users are subject to stricter ACL enforcement, especially in Service Portal widgets. While an internal user may be able to dot-walk fields without issue, an external user must have explicit read access to every table, reference, and field involved in the dot-walk. Even if the user has read access to both Table A and Table B, missing ACLs on referenced fields or dot-walk paths can cause the widget to return no data.
This is why switching the user back to snc_internal works as expected, while snc_external does not. The dot-walk itself is supported, but it requires the appropriate ACLs to be defined explicitly for external users.
The recommended approach is to:
Review read ACLs on all referenced tables and fields used by the widget, or
Avoid dot-walking in the widget and retrieve related records explicitly (for example, via a Script Include using GlideRecordSecure).
Please let me know if you’d like help identifying which ACL is blocking access — I’d be happy to assist.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
We moved all of our users to snc_internal to snc_external on our external instance. I changed a user back to snc_internal and it's fine, but with snc_external, no go. The user has access to Table A and Table B. I guess the dot walk of the widget doesn't work with snc_external?
There isn't a property on our instance anymore (I'm not sure there was though) for glide.partial_record_optimizer.enabled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Thanks for the details — this behavior is expected when switching users from snc_internal to snc_external, and it’s not related to the glide.partial_record_optimizer.enabled property.
External users are subject to stricter ACL enforcement, especially in Service Portal widgets. While an internal user may be able to dot-walk fields without issue, an external user must have explicit read access to every table, reference, and field involved in the dot-walk. Even if the user has read access to both Table A and Table B, missing ACLs on referenced fields or dot-walk paths can cause the widget to return no data.
This is why switching the user back to snc_internal works as expected, while snc_external does not. The dot-walk itself is supported, but it requires the appropriate ACLs to be defined explicitly for external users.
The recommended approach is to:
Review read ACLs on all referenced tables and fields used by the widget, or
Avoid dot-walking in the widget and retrieve related records explicitly (for example, via a Script Include using GlideRecordSecure).
Please let me know if you’d like help identifying which ACL is blocking access — I’d be happy to assist.
