ACL Bypass via Inline Script in Flow DesignerDescriptionTitle Flow Designer inline script bypasses ACLs on related records Overview When using Flow Designer inline scripts that dot‑walk from fd_data.trigger.current to related records, users without ACL access to those related records can still read protected field values. This occurs because the inline script executes with elevated access and does not automatically enforce record ACLs on the dot‑walked object. Symptoms Flow Designer flow triggered on Incident.A Log action uses a Data Pill to display Problem → Description and correctly returns blank for a user lacking access to the Problem record.A second Log action uses an inline script:return fd_data.trigger.current.problem_id.description;For the same user, the inline script log shows the Problem description, even though the user cannot view the Problem record directly. Expected: Both logs are empty.Actual: Data Pill log is empty, inline script log shows protected data. Cause Inline scripts in Flow Designer run as server‑side scripts that can dot‑walk to related records without enforcing that the current user has read access to those records. This allows protected values to be read, logged, or stored in variables, which can then be surfaced elsewhere in the flow.https://www.servicenow.com/docs/r/build-workflows/workflow-studio/inline-scripts.html Recommendations Prefer GlideRecordSecure over GlideRecord in Flow Designer inline scripts whenever you are re‑reading or exposing record data that might be ACL‑protected.Avoid direct dot‑walks such as fd_data.trigger.current.problem_id.description in inline scripts when the related table has stricter ACLs than the primary record.For reusable logic, move the secure access pattern into a Scripted REST API, Script Include, or custom Action/Subflow and call it from Flow Designer.Steps to Reproduce 1- Create Test Flow with:- Trigger: Record Updated on Incident table- Add Log Steps: - Log Step 1 - in the message section use Data Pill to get the description of the problem associated with the incident record ( Trigger - Record Updated➛Incident Record➛Problem➛Description)- Log Step 2 - in the message section this time use Inline Script to get the problem description (return fd_data.trigger.current.problem_id.description)2- Impersonate a user who does not have access to view problem table (ex. aileen.mottern)- Navigate to Incidents and create a new incident 3- End Impersonation (admin now)- Open the incident created by aileen.mottern)- Set Problem field to any existing problem record and save 4 - Impersonate aileen.mottern again:- Open the same incident - Update Short Description or any field to trigger the flow created in step 15- Verify the Issue:- Find the latest flow execution by aileen.mottern- Expected Result: Both logs should return empty (user lacks ACL to the problem record)- Actual Result: Log 1 (Data Pill): Empt ✓ (Correctly enforces ACL) Log 2 (Inline Script): Shows problem description ✗ (ACL bypassed)WorkaroundUse GlideRecordSecure in the inline script to re‑read the related record under ACL enforcement, and only return the field value if canRead() passes. Example workaround script Inline Script (Log Step 2): (function() { // Get the Problem sys_id from the trigger record var problemId = fd_data.trigger.current.problem_id + ''; if (!problemId) { return ''; } // Re-read the Problem record using GlideRecordSecure to enforce ACLs var grsProblem = new GlideRecordSecure('problem'); if (!grsProblem.get(problemId)) { return ''; } // Extra safety: confirm read access if (!grsProblem.canRead()) { return ''; } // Only return the description when ACLs allow it return grsProblem.description.toString(); })(); Behavior with this workaround: If the user does not have read access to the Problem record, get() or canRead() fails and the script returns an empty string.If the user has access, the description is returned as expected, but now under GlideRecordSecure enforcementRelated Problem: PRB1990039