Contract (ast_contract) is this suppose to be readable for snc_internal / csm agent roles?

[gsuprumanian]

We've observed that the Contract (ast_contract) table is accessible to users with the snc_internal role and certain CSM agent roles.

Is anyone else experiencing this issue in their instance?

From what we understand, our setup is close to out-of-the-box, and since this table is shared across several ServiceNow modules, the snc_internal role restricts view access for contract model = subscription, but not for CSM related roles. There are a few Business Rules and Script Includes that control this, but they don't seem to effectively restrict the content.

[Maik Skoddow]

Sorry, did not get your point. What exactly is the issue and what are your concerns? And what are your expectations instead?

[gsuprumanian]

Updated, is it about Contract (ast_contract) is this suppose to be readable for snc_internal / csm agent roles? Seems like a role in csm provide user to read all the contracts. If they click on the link if someone shared to them or they know how to use the navigator filter to <table>.list

[ArvindS]

 great observation — this is indeed a nuanced behavior worth unpacking.

The ast_contract table is leveraged across multiple applications (notably Asset Management and CSM), and out-of-the-box, it inherits permissions from the base system role model.

The key issue here likely stems from role inheritance and ACL configuration:

What’s Likely Happening:

• snc_internal is broadly scoped for internal platform users (like agents or system users), and may be indirectly granted read access to several shared tables.

• CSM roles (e.g., sn_customerservice_agent) often inherit broader access to business-related records to enable case and contract context for customer service workflows.

• ACLs (Access Control Rules) on ast_contract may not be strict enough, especially if no read ACLs exist to explicitly restrict access based on contract type or user relationship.

 What You Can Do:

1. Audit ACLs on the ast_contract table:

   • Navigate to System Security > Access Control (ACL) and filter for ast_contract.

   • Check whether read access is limited by role, condition, or script.

   • If missing, create a Read ACL scoped to your needs (e.g., contract model, user role, or related account).

2. Review inherited roles:

   • Use the Role Explorer (sys_user_has_role.LIST) or the User Role Viewer to track which roles are granting access.

   • You may find a role like sn_customerservice.agent or snc_internal pulling in unintended privileges.

[SumanthDosapati]

@gsuprumanian 

Read Access to any table will be usually controlled via ACLs.

Did you check your READ Acls on ast_contract table?

Regards,

Sumanth