---
sourceDocument: Australia Governance, Risk, and Compliance
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/governance-risk-compliance

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Governance, Risk, and Compliance

ft:clusterId :

    - grc

bundleId :

    - grc

workflow :

    - Technology


---

# TPRM and the Explicit Roles plugin

# TPRM and the Explicit Roles plugin {#ariaid-title1}

Release version: Australia  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of TPRM and the Explicit Roles plugin

Activating the Third-party Risk Management (TPRM) plugin in ServiceNow automatically installs the Explicit Roles plugin.
This integration manages user access by assigning specific roles---sncinternalfor internal users andsncexternalfor third-party external users---to control permissions within the instance, particularly for resources related to the Third-party portal.
Show full answer Show less  
When third-party contacts are created, they receive the **sncexternal** role, granting them access only to designated external resources. Access to records is controlled through the Roles field on various tables; if this field is empty, all users have access by default.

## Key Features

* **Role Assignment upon Plugin Activation:** Installing the Explicit Roles plugin updates records with empty Roles fields by assigning the **sncinternal** role, effectively restricting access to internal users only.
* **User Role Management:** All existing users receive the **sncinternal** role after plugin installation. New users must be explicitly assigned this role to access items previously available to all users.
* **Role Enforcement on Key Tables:** Multiple core tables are affected to enforce role-based access control, including Access Control \[syssecurityacl\], Catalog Item \[sccatitem\], Page \[contentpage\], Navigation Menu \[sysappapplication\], Overview Help Panel \[sysuioverviewhelppanel\], Portal Page \[sysportalpage\], Processor \[sysprocessor\], and Report \[sysreport\].
* **Catalog Item Behavior:** The `glide.sc.useusercriteria` property influences catalog item visibility. When set to false, new catalog items default to **sncinternal** role assignment; when true, an external user criteria restricts third-party users from viewing those items.
* **Automatic Role Application:** For records with empty Roles fields on the affected tables, the plugin automatically assigns the **sncinternal** role to enforce internal access control going forward.

## Practical Implications for ServiceNow Customers

After enabling the TPRM and Explicit Roles plugins, customers should expect:

* Enhanced security through explicit role-based access rather than open access where Roles fields were previously empty.
* A need to manage user role assignments carefully, especially for new users, to maintain appropriate access to catalog items and other resources.
* Adjusted visibility of service catalog items and portal pages, aligning with internal vs external user distinctions.
* Streamlined third-party contact access through automated assignment of the **sncexternal** role.

Understanding these changes helps administrators maintain compliance and control over third-party and internal user access within their ServiceNow environment.  
Activating the Third-party Risk Management plugin also installs the Explicit Roles plugin. Administrators assign the snc_internal and snc_external roles to provide internal and external users access to the instance.

When third-party contacts are created, they are automatically assigned the snc_external role, giving them access to resources related to the Third-party portal.

Various tables provide role-based access to record by setting the Roles
field. If the Roles field is empty, all users have access to that record.
For example, if the Roles field for a Service Catalog item
has an empty Roles field, all users have access to that Service Catalog item.  
However, when the Explicit Roles plugin is installed, the Roles field is updated to snc_internal. Also, all users are given the snc_internal role. Continuing with the previous example:

* Before installing the Explicit Roles plugin, if a Service Catalog item had an empty Roles field, it was accessible to every user.
* After installing the Explicit roles plugin, the Roles field of the Service Catalog item is updated to snc_internal and all existing users are given the snc_internal role, making the catalog item accessible to those users.
* After that, all new users must be assigned the snc_internal role, or they will not have access to that Service Catalog item.
{#vrm-and-explicit-roles-plugin__ul_frx_gvx_4cb}

The following table describes the changes to tables affected by the Explicit Roles plugin.
{#vrm-and-explicit-roles-plugin__table_efk_k55_dcb__entry__2}

| Table | Changes |
|-|-|
| Access Control \[sys_security_acl\] | For all existing and newly created ACLs without a role requirement, the snc_internal role is assigned. |
| Catalog item \[sc_cat_item\] | For all records where the Roles field is empty, the snc_internal role is added. If the glide.sc.use_user_criteria property is set to false, newly created catalog items are automatically assigned the snc_internal role. If the property is set to true, the SNC External user criteria is added to all newly created catalog items, excluding external users from viewing the record. |
| Page \[content_page\] | For sites that have a login page, where the Read roles field is empty, the snc_internal role is added. For sites that have no login page or that have automatically created content pages, the public role is added. |
| Navigation Menu \[sys_app_application\] | For all records where the Roles field is empty, the snc_internal role is added. Newly created navigation menus with an empty Roles field are also automatically assigned the snc_internal role. |
| Overview Help Panel \[sys_ui_overview_help_panel\] | For all records where the Roles field is empty, the snc_internal role is added. Newly created overview panels with an empty Roles field are also assigned the snc_internal role. |
| Portal Page \[sys_portal_page\] | For all records where the Read roles field is empty, the snc_internal role is added. Newly created portal pages with an empty Read roles field are also automatically assigned the snc_internal role. |
| Processor \[sys_processor\] | For all records where the Roles field is empty, the snc_internal role is added. Newly created processors with an empty Roles field are also automatically assigned the snc_internal role. |
| Report \[sys_report\] | For all records where the Roles field is empty, snc_internal is added. Newly created reports that have an empty Roles field when sharing are also automatically assigned the snc_internal role. |
[Table 1. Tables affected by the Explicit Roles plugin]

{#vrm-and-explicit-roles-plugin__table_efk_k55_dcb}
**Related concepts**   

* [Managing the Third-party portal](https://www.servicenow.com/docs/0~pzVvr~IuJOCqkyFNmYfA "Third-party contacts respond to questionnaires, requests for documentation, tasks, and issues on the Third-party portal. The portal is the point of interaction between third parties and risk assessors.")