field dotwalked not being shown on list

[janetakiyam]

Hi all,

I have an issue where I am unable to view fields that are being dot-walked.

To share the details exactly, I am opening asmt_metric_result, dot-walking from the asmt_assessment_instance table.

On asmt_assessment_instance, the user can view the information.

What could possibly be an issue...?

This is only happening in one of the instances.

The red part on the image is where information is visible.

[Pavan Srivastav]

The fact that it works in one instance but not another is the most important clue here — it immediately rules out a code/schema problem and points to a configuration or data difference between the instances. Here is a systematic diagnosis:

---

Most Likely Causes

1. ACL on the Dot-Walked Table (Most Common)

The user can see fields directly on asmt_assessment_instance but when those same fields are accessed via dot-walk from asmt_metric_result, a separate ACL evaluation is triggered on the source table.

Check this first:

System Security → Access Control (ACL)
Table: asmt_assessment_instance
Operation: read

Compare the ACLs between both instances. The broken instance likely has a more restrictive ACL — either an additional deny rule, a stricter role requirement, or a condition script that evaluates differently.

javascript

// Common culprit in condition scripts on asmt ACLs
// This kind of check can block dot-walk reads even when direct access works
answer = (gs.hasRole('assessment_admin') || 
          gs.hasRole('assessment_reader') || 
          current.user == gs.getUserID());

---

2. Field-Level ACL Difference Between Instances

Beyond the table-level ACL, check if there are field-level ACLs on the specific fields you are trying to dot-walk to:

ACL name format: asmt_assessment_instance.[field_name]

These are easy to miss because they don't show up when you look at the table-level ACL list unless you filter specifically for that table + field combination.

---

3. glide.security.dot_walk_acl System Property

This is a critical property that directly controls dot-walk ACL behaviour and is a very common source of cross-instance discrepancies:

Navigate to:

System Properties → Security
Name: glide.security.dot_walk_acl

Value	Behaviour
true	ACLs ARE enforced on dot-walked fields — can block visibility
false	ACLs are NOT enforced on dot-walked fields — permissive

Check this property value in both instances and compare. The broken instance almost certainly has this set to true while the working instance has it false, or vice versa depending on your ACL setup.

---

4. User Roles Differ Between Instances

The user account being tested may have different roles assigned in each instance. Even if it looks like the same user, role assignments are instance-specific.

javascript

// Run in Scripts - Background on both instances to compare
var user = new GlideRecord('sys_user');
user.get('YOUR_TEST_USER_SYS_ID');
gs.info(user.getValue('user_name'));

var gr = new GlideRecord('sys_user_has_role');
gr.addQuery('user', 'YOUR_TEST_USER_SYS_ID');
gr.query();
while (gr.next()) {
    gs.info('Role: ' + gr.getDisplayValue('role'));
}

---

5. Assessment Module Version / Plugin Difference

Since this is the asmt_ scope, check if both instances are on the same version of the Assessments & Surveys plugin:

System Diagnostics → Stats
or
System Applications → All Available Applications → Assessments

A newer plugin version on one instance may have introduced additional ACL records that restrict dot-walk access.

---

Quickest Way to Pinpoint It

Run this in Scripts - Background on the broken instance while impersonating the affected user:

javascript

// Test dot-walk field visibility programmatically
var gr = new GlideRecord('asmt_metric_result');
gr.setLimit(1);
gr.query();
if (gr.next()) {
    // Replace 'field_name' with the specific field you can't see
    var dotWalkedValue = gr.asmt_assessment_instance.getDisplayValue('field_name');
    gs.info('Dot-walked value: ' + dotWalkedValue);
    
    // Also check if the assessment instance record itself is readable
    var instanceGr = new GlideRecord('asmt_assessment_instance');
    instanceGr.get(gr.getValue('asmt_assessment_instance'));
    gs.info('Can read instance directly: ' + !instanceGr.isNewRecord());
    gs.info('Direct field value: ' + instanceGr.getDisplayValue('field_name'));
}

If the direct read works but the dot-walk returns empty, the problem is definitively ACL or the glide.security.dot_walk_acl property.

---

Recommended Investigation Order

1. Compare glide.security.dot_walk_acl between both instances  ← check first
2. Compare table-level ACLs on asmt_assessment_instance
3. Compare field-level ACLs on the specific fields
4. Compare user roles between instances
5. Compare plugin/application versions

Checking the glide.security.dot_walk_acl property first will resolve this in the majority of cases where behaviour differs between instances on dot-walk visibility.