Understanding ServiceNow ACL Types and Operations

[TejasSN_LogicX]

I’m currently learning ServiceNow ACLs in detail. I prepared some notes to understand different ACL types, operations,Sharing here so it can also help others, and please correct me or add if I missed anything.

Type – values of type field

• client_callable_flow_object
• client_callable_script_include
• GraphQL
• processor
• record
• REST_Endpoint
• ui_page
• Gen_ai_agent
• Flow
• Flow action

client_callable_flow_object -> means a Flow Designer flow that can be triggered from the client side (like a button on a form or a client script).

Operation   ->  execute

Name field  ->  * if you want to apply this to all the flows we can use * in name field.

                          If we have to apply ACL for the any particular flow then enter flow name ex. ‘request approval’.

But we don’t use this method instead of this we use conditional visibility for UI action gs.getUser().hasRole(‘admin’)

Or in client script we can use gs or g_form objects.

client_callable_script_include -> his ACL is for Script Includes that are allowed to be called from the client side.

Operation  -> Execute

Name ->  name of client script

When we create any client script .while submitting it show popup window to add the role. Only that role users can execute that client script and automatically ACL record generate for that script include.

Flows ->  This ACL controls access to Flow Designer flows in general (not just client-callable ones).

Type -> flow

Operation -> invoke_from_ai

Name -> table name  and *  -- Means flow can access the all the fields on that table

               Table or field_name -- Means Field-level selection adds extra restriction: flow can only access that field if ACL allows.

Flow Action - Controls who can run or access individual actions inside a Flow Designer flow for any table or field. Which flow action can access which table or table’s field.

Type – > flow action

Operation -> invoke_from_ai

Name -> table and * - ACL applies to all fields

                Table and field_name - ACL applies when this action accesses that field

Gen_ai_agent = Controls access to Generative AI agents in ServiceNow. Define

These agents are AI-powered bots or assistants that can perform tasks, answer questions, or interact with users. ACL ensures only allowed users can run or interact with a specific AI agent.

Operation-execute

Name –select table name */field  (restrict the table data for agents)

GraphQL – GraphQL is a query language for APIs (like a smart way to ask for data).  It is a way to get or change data in ServiceNow using API queries. Means it control the queries via API’s.

Operations -> execute

Name –> name of GraphQL

Processor = Controls access to server-side processors or integration endpoints in ServiceNow. A Processor is a server-side script or API that handles tasks like:

• Processing incoming requests
• Running background logic
• Integrating with other systems

Operation -execute

Name – processor name

Rest_endpoint= Controls access to REST APIs in ServiceNow.

Name- Name of the REST API or resource

Operation -> execute → Permission to call/run the REST API

UI page-Controls access to custom UI Pages in ServiceNow. UI Pages are special pages created in ServiceNow using HTML, Jelly, or other scripting.

Name- ui page name.

Operation  = read   Permission to open or view the UI Page. If a user does not have read access, they cannot see or load that page.

Record = Controls access to table records in ServiceNow. Most common ACL type. Determines who can read, write, create, or delete records in a table.

Operations –

Execute - User can’t execute scripts on a record or UI page.

Create - User can’t see the New UI action from forms. The user also cannot insert records into a table using API protocols such as web services. 

 defined users or roles can create the records in table.

àWhen you are creating a record, ServiceNow checks ACL.

                  If the ACL condition says:

Example: state = "Open"

At the time of creation, the record’s fields are still blank (because record not yet saved).

So the condition (state = "Open") fails → ACL returns false.

So, conditions that check field values usually won’t work for create.

Best practice → Use role check or script check instead of relying on field conditions for create

Read - User can’t see the object in forms or lists. The user also can’t retrieve records using API protocols such as web services.

If allow – defined users or roles can delete the records from table.

Write- Controls if a user can update/edit an existing record or field.

Example: If denied →

Priority field becomes read-only for that user.

API update calls will also fail.

If allow – only defined users or roles can edit/update that records or field

Delete - User cannot see the Delete UI action from forms. The user also can’t remove records from a table using API protocols such as web services.

If allow – only defined users or roles can delete the records from table.

edit_task_relations - Controls if user can create/manage relationships between task tables (Incident, Change, Problem, etc.)

edit_ci_relations   - User cannot define relationships between Configuration Item [cmdb_ci] tables.

save_as_template - Used to control the fields that should be saved when a template is created. Controls if fields can be saved into a Template for reuse.

add_to_list    - User can’t view or personalize specific columns in the list view. Controls who can see the table fields in list view.

If denied → user can’t add “short_description ” column to the Incident list

If allowed – only defined users/roles can add that field in list view.

list_edit ->    Controls if user can edit records directly in the list view (inline edit).

                        If denied → user can’t change “State” of multiple Incidents directly from the list.

report_on ->            Controls if user can create reports using this table.

                          If denied → user can’t make a report based on the Incident table.

report_view -> Controls if user can view reports based on this table/field.

                           If denied → user can’t open a report showing Incident records.

personalize choices  -> User can’t right-click a list field and select Configure Choices. Controls if user can configure Choice fields by right-clicking.

[kaushal_snow]

@TejasSN_LogicX , just adding few more to your notes:

when configuring ACL for Flow Designer flows or flow actions, it's important to note that the invoke_from_ai operation is used to control access to these components, and the Name field should specify the table and field names to define the scope of access. Additionally, for client callable script includes, while the execute operation is appropriate, it's essential to understand that ServiceNow automatically generates ACL records when a client callable script include is created, and roles can be assigned to control access. Regarding the client_callable_flow_object, it's worth mentioning that this ACL type pertains to Flow Designer flows that can be triggered from the client side, such as through UI actions or client scripts, and the execute operation is used to grant permission to invoke these flows. For Gen_ai_agent ACLs, which control access to Generative AI agents, the execute operation is used, and the Name field should specify the table and field names to restrict the data the agent can access.......

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.

[Rafael Batistot]

Hi @TejasSN_LogicX 

I’ll refine, clarify, and add a few missing details to make your notes even more accurate and exam-ready (since you’re also preparing for CSA).

General ACL Rules (important reminders)

• Order of evaluation: ACLs are evaluated in order: table-level first, then field-level. Deny at either level blocks access.
• How ACLs are evaluated: Each ACL rule has Condition → Script → Role requirement. All must return true for access.
• Default behavior: If no matching ACL exists, access is denied.

ACL Types & Operations

client_callable_flow_object

• Your note is correct → This controls which Flows can be triggered from the client (via client-side APIs).
• Extra point: It’s newer and often used with UI Actions or Buttons. Instead of ACLs, many admins prefer conditional visibility with g_user.hasRole().

client_callable_script_include

• Correct → This protects Script Includes that are marked Client Callable.
• Extra point: When you make a Script Include “Client Callable”, ServiceNow auto-creates this ACL. You rarely create it manually.

flow

• Small correction:
  
• Operation isn’t always invoke_from_ai. That operation is specific to GenAI-powered flows.
• For standard flows, operations are usually execute or table/field-level ones.

flow_action

• Same as above → invoke_from_ai applies to GenAI use cases.
• In standard scenarios, you secure flow actions by roles or explicit ACLs.

gen_ai_agent

• Correct, but add: These are specific to Now Assist / AI Search / GenAI integrations. If your instance doesn’t have GenAI features, you won’t see/use these ACLs.

GraphQL

• Correct, but worth noting:
  
• GraphQL APIs are still relatively new in ServiceNow.
• Operations supported → usually execute (to allow queries/mutations).
• Name → specific GraphQL query or *.

processor

• Correct.
• Common examples:
  
• /xmlhttp.do
• /ecc_queue_processor.do
• Used for GlideAjax, UI actions, integrations.
• Best practice: Avoid writing custom processors unless needed → prefer REST APIs or Scripted APIs.

rest_endpoint

• Spot on 
• Name → API namespace or specific resource.
• Operation → always execute.

ui_page

• Small correction:
  
• Operation is usually execute, not read.
• Without execute permission, user cannot load/open the UI Page.

record

• Perfect coverage. You even noted the create gotcha (conditions won’t work since record fields are empty).
• Extra ACL Operations you can add (these often confuse people):
  
• read → see records.
• write → update/edit records.
• create → insert new records.
• delete → remove records.
• execute → run server-side business logic (common for scripted actions).
• edit_task_relations → manage task relationships.
• edit_ci_relations → manage CI relationships.
• save_as_template → control template saving.
• add_to_list → personalize list columns.
• list_edit → inline edit in list view.
• report_on → create reports.
• report_view → view reports.
• personalize_choices → manage choice field options.

You captured these nicely already.

Best Practices to Remember

• Always prefer role checks for performance (over heavy scripts).
• Use table ACLs unless field-level is strictly required. Field ACLs add overhead.
• Use conditions/scripts sparingly → they run on every query.