Write ACL on Dot Walked Field but not on Reference Field

[nwilliams62]

Lets say I have Tables A and B.

Table B has two fields:

• field_x: a reference field to table A
• field_y: a dot walked field to another field on table A (through the reference)

While viewing table B I would like a user to be able to edit field_y...but not be able to change the field_x.  How do I do this?  I'm thinking it needs to be ACL because User 1 should be able to edit this but not user 2...I'm just not sure how to handle the dot walked part.

[Brian Lancaster]

You need an ACL that give write access to the entire table B to user 1 and then a specific ACL that give write access to the field_y only to user 1.

[Sandeep Rajput]

@nwilliams62 You need two write ACLs on Table A.

1. Table Level write ACL on Table A

2. A Field level write ACL on Field Y.

Hope this helps.

[Vaishnavi Lathk]

To control access to a dot-walked field (field_y) on Table B without affecting the reference field (field_x), you can indeed use an Access Control List (ACL) in ServiceNow. Here's how you can configure it:

1. Navigate to Access Control Lists:

   • Go to System Security > Access Control > Roles.

2. Create a New ACL Entry:

   • Click on New to create a new ACL entry.

3. Configure the ACL:

   • Name: Provide a descriptive name for the ACL entry.
   • Application: Choose the application scope where this ACL will be applied.
   • Operation: Select the operation you want to control. In this case, you may choose write to control editing permissions.
   • Object: Choose Table B.

4. Define the Conditions:

   • In the Advanced tab, define the conditions under which the ACL should be enforced. Since you want to allow editing only for certain users, you'll need to create a script condition.

5. Script Condition:

   • Write a script condition that checks if the user is authorized to edit field_y but not field_x. You can achieve this by verifying the user's roles or other criteria.

Here's an example script condition:

// ACL script for controlling access to field_y on Table B
(function() {
    // Get the current record being accessed
    var record = new GlideRecord(current.table);

    // Check if the operation is allowed based on the user's roles
    function isOperationAllowed(operation) {
        // Get the user's roles
        var userRoles = gs.getUser().getRoles();

        // Check if the user has a role that allows editing field_y
        var canEditFieldY = userRoles.contains('allowed_role_1') || userRoles.contains('allowed_role_2');

        // Check if the user has a role that allows editing field_x
        var canEditFieldX = userRoles.contains('allowed_role_for_field_x');

        // Allow editing field_y but not field_x
        if (operation == 'update') {
            if (canEditFieldY && !canEditFieldX) {
                return true;
            } else {
                return false;
            }
        }

        // For other operations, allow by default
        return true;
    }

    // Check if the operation is allowed for the current user
    if (isOperationAllowed(operation)) {
        // Allow the operation
        answer = true;
    } else {
        // Deny the operation
        answer = false;
    }
})();

Replace 'allowed_role_1', 'allowed_role_2', and 'allowed_role_for_field_x' with the actual roles that have permissions to edit field_y and field_x respectively.

6. Save the ACL Entry:
   • Once you've configured the ACL and defined the script condition, save the ACL entry.

With this configuration, users with roles specified in the script condition will be able to edit field_y on Table B, while not being able to edit field_x. Users who don't meet the conditions will not be able to edit field_y. Adjust the script condition and roles as per your specific requirements and access control policies.

Regards,

Vaishnavi Lathkar