The snc_internal Role in ServiceNow: What It Does and How to Manage It

In ServiceNow, snc_internal is a special platform role used to identify internal users (typically employees or internal stakeholders). This role is not manually created by administrators; it originates from a built-in feature called the Explicit Roles plugin. The snc_internal role is automatically assigned to users whom the system considers “internal” once the plugin is enabled. Importantly, adding this role to a user does not by itself grant new permissions or change what that user can access. Instead, the role serves as a flag to categorize internal users separately from external users.

Its counterpart is snc_external, which labels external or customer users. ServiceNow uses this internal vs. external distinction to apply appropriate access controls and ensure that external users cannot see internal resources by default.

The Explicit Roles Plugin: Source of the snc_internal Role

The Explicit Roles plugin (plugin ID: com.glide.explicit_roles) is the feature that introduces the snc_internal and snc_external roles into the platform. This plugin is often activated automatically when certain ServiceNow applications are installed (for example, Customer Service Management or Vendor Risk Management include it). The plugin’s security model requires that every user in the system be explicitly classified as either internal or external. In fact, the platform enforces a mutual exclusion rule: no user can have both snc_internal and snc_external at the same time.

If an administrator mistakenly tries to assign both roles to a user, ServiceNow will prevent it and even log an error indicating a conflict. This strict separation is intentional – it ensures that internal users and external users can be handled differently by security rules, UI pages, and business logic across the instance.

Under the hood, the Explicit Roles plugin adds the snc_internal role to all existing users when activated, and sets up the system to tag new users appropriately (we’ll discuss the automatic assignment shortly). The presence of these roles allows system administrators to write ACLs (Access Control Lists) or configure modules that target “internal-only” or “external-only” audiences. For example, you might see these roles appear in out-of-the-box ACL definitions or module roles to restrict certain features to internal users.

This plugin essentially provides an instance hardening mechanism: internal users get a baseline role that can be required for access to sensitive elements, while external users are kept out unless explicitly permitted.

Automatic Role Assignment (snc_internal vs snc_external)

One of the key behaviors of the Explicit Roles plugin is how it auto-assigns roles to users to enforce the internal/external classification:

Existing Users: As soon as the plugin is enabled, ServiceNow systematically assigns the snc_internal role to all existing user accounts. This means every user present in the instance at activation time is marked as internal by default. The platform does this in one sweep to ensure no user is left without an explicit role designation. Notably, assigning snc_internal in bulk does not change any user’s access rights or group memberships – all it does is tag them as internal users for classification purposes.
New Users: After plugin activation, any newly created user will also receive the snc_internal role automatically upon their first login, unless they have been pre-marked as external. In practice, if you create a user (or one is self-registered) with no roles, the moment they log in, the system will add snc_internal to their roles list. This behavior guarantees that every active user has at least one of the explicit roles. If you intend a new account to be an external user (for example, a customer contact in a Customer Service Portal scenario), you should assign the snc_external role to that user before they log in. By doing so, the platform recognizes them as external and will not apply snc_internal to them at first login. In summary: internal is the default role for new users, and external must be explicitly set when needed.
Role Mutability: These explicit roles are not set in stone – administrators can add or remove snc_internal or snc_external from a user at any time to change their classification. For example, if a previously internal user account needs to be converted into an external-facing account, the admin would remove snc_internal and add snc_external. The system will treat the user accordingly going forward. (Under normal operation, though, a user will never have both roles simultaneously due to the mutual exclusion enforcement mentioned earlier.)
Why Automatic Assignment? The purpose of this automation is to ensure the security model is consistently applied without relying on administrators to manually tag every user. It provides a safety net: internal users maintain all their previous access (the new role doesn’t grant or revoke anything immediately), and external users are clearly flagged so they can be restricted appropriately. In fact, ServiceNow expects that “every user must have at least one role” in this scheme so that the instance can distinguish internal vs. external. Prior to this plugin, a user with no roles was implicitly an “external” or end-user. With explicit roles, the system makes that status explicit with one of these roles.

Use Case Example: If your organization enables Customer Service Management (CSM) and activates the Explicit Roles plugin, all your employees get snc_internal right away. Suppose you already had some customer contact records in your user table (perhaps loaded via integration). Those contacts would also get snc_internal by default on activation – which is not what you want for customers. The fix is to go through those customer users and swap their roles: remove snc_internal and add snc_external, so they have the proper designation.

This step ensures external users (customers) added before the plugin was enabled don’t accidentally retain internal access rights they shouldn’t have. Always review user roles after enabling Explicit Roles in an established instance.

Impact on Access Control and ACL Behavior

Enabling the snc_internal/snc_external model has significant effects on how your instance handles security and access control:

ACL Updates for Internal Access: When the plugin is activated, the system updates existing Access Control rules. All ACLs that previously had no role requirement (i.e., they were open to any authenticated user) are automatically assigned the snc_internal role as a required role. In other words, any resource that was unrestricted (accessible by all logged-in users) now implicitly requires “internal user” status. Because all your pre-existing users just got snc_internal, nothing breaks for internal users – they still satisfy those ACLs since they have the role. However, an external user (who only has snc_external) will fail those ACL checks and be denied access. This change effectively cordons off all previously open functionality to internal users only.
New ACL Defaults: Going forward, whenever an administrator creates a new ACL and leaves the role condition empty, ServiceNow will automatically insert snc_internal as a required role on that ACL. This default behavior is a safety measure to prevent accidentally exposing new functionality to external users. If you truly intend an ACL to be open to all users (internal and external alike), you must explicitly include both snc_internal and snc_external in the ACL’s role list (or simply add snc_external, if snc_internal is already there by default). According to ServiceNow, having both roles on an ACL is effectively the same as allowing “any logged-in user” because every logged-in user will have one role or the other. For example, you might see an out-of-box ACL or UI action with both roles listed, indicating it’s meant for all users regardless of internal/external classification.
Impact on Service Catalog and Portal Items: This internal-by-default rule doesn’t just apply to record ACLs; it can also affect things like Service Catalog items or knowledge base articles availability. For instance, when you create a new catalog item in an instance with Explicit Roles enabled (such as in a CSM context), that item is automatically tagged for snc_internal users by default. This means external users won’t even see the item in the Service Portal. Administrators must take additional steps (like adding snc_external to the item’s availability or using user criteria) to expose such items to external users if needed. This behavior has surprised some admins who found that all new catalog items were invisible to customers until the settings were adjusted. The key point is to be aware that the system assumes “internal only” unless you specify otherwise.
No Effect on Existing Role Permissions: It’s worth emphasizing that snc_internal by itself does not grant permission to do anything a user couldn’t do before. All it does is satisfy the new internal ACL conditions. ServiceNow explicitly notes that internal users maintain the same level of access as before the plugin – they just now carry a role that identifies them as internal. Conversely, snc_external by itself grants very limited access. External users are treated as having no privileges unless some ACL or role explicitly gives them access to a resource. In fact, out of the box, an snc_external user cannot even access many non-record resources like processors and certain UI pages because those also implicitly require snc_internal (or check that the user has some role). This means if you create a brand new external user with no other roles, they will typically only be able to log in to a Service Portal or interface specifically designed for external access, and see very little else.
Platform Scripting and hasRole Considerations: A subtle but important system behavior change involves how ServiceNow’s scripting API treats these roles. Normally, one could check if a user has any role by using gs.hasRoles() (deprecated in Geneva) or similar methods. With Explicit Roles, the platform automatically excludes snc_internal and snc_external from such checks. This means if a user’s only role is snc_internal, a script call to hasRoles() will return false – effectively treating the user as if they have no roles. The same goes for a user with only snc_external. ServiceNow implemented this to ensure that existing logic (which might assume a user with “no roles” is a self-service user) continues to work. For example, many Service Portal widgets or UI policies differentiate between users with roles (like ITIL, etc.) and those without any role; thanks to this adjustment, internal users who have no roles other than snc_internal still count as “role-less” in that context. Administrators should be mindful of this: if you write scripts or business rules that specifically check for snc_internal or snc_external, that’s fine – but if you use general checks for any role, remember these two don’t count as roles in that sense. The platform’s mutual exclusion and special handling ensure the snc_internal/snc_external roles act as a security boundary without disrupting the notion of a “privileged” vs “unprivileged” user in existing logic.

Common Issues and Troubleshooting Tips

While the snc_internal role and Explicit Roles plugin generally operate in the background, there are a few common issues and scenarios ServiceNow administrators should watch out for:

External Users Missing Access to Catalog Items or Knowledge: A frequent point of confusion arises when external users (with snc_external) cannot see certain Service Catalog items, knowledge bases, or other content. By default, those items may be restricted to snc_internal users only, as mentioned earlier. For example, one admin found that all new catalog items were automatically requiring snc_internal, making them invisible to customer users. Solution: Review the Available For / Not Available For settings on catalog items and knowledge articles. To expose them to external users, add the snc_external role to the “Available For” conditions (or remove the snc_internal requirement if appropriate). In Service Portal, you might also need to adjust page or widget permissions to include snc_external if those are set to internal by default. Using User Criteria is another best practice for catalog and knowledge management – you can create criteria for external users and attach it to the items, instead of relying purely on roles.
User Accidentally Has Both snc_internal and snc_external: In theory, the platform prevents this, but there are edge cases (e.g., data imports or improper scripts) that could lead to a user having both roles. This is definitely a misconfiguration – as noted, the system expects mutual exclusivity and will log errors if it finds a conflict. A user with both roles might experience unpredictable access issues (perhaps being treated as external in some places but internal in others). Solution: Decide whether that account should be internal or external, and then remove the incorrect role. Typically, if it’s an employee or internal staff, remove snc_external; if it’s a customer/partner account, remove snc_internal. After fixing the roles, monitor the logs and user access to ensure the conflict is resolved. It’s also wise to investigate how both roles got assigned in the first place (for example, via a faulty integration) and correct that process.
External Users Created Before Plugin Activation: If you enabled the Explicit Roles plugin on an instance that already had some external (customer) user records, those users would have been given snc_internal along with everyone else. As a result, those external users suddenly have access to internal resources that they shouldn’t (because the system thinks they are internal now). Solution: Immediately audit and update those accounts. ServiceNow’s guidance is to remove the snc_internal role and add the snc_external role for any external users that existed prior to plugin activation. This will correctly restrict their access. This scenario often occurs in Customer Service Management deployments – for example, if “Customer Contact” users were in the system and then the Explicit Roles plugin was turned on later. Proactively handling this ensures you maintain proper data segregation between internal and external users.
Internal User Lacks snc_internal (or Plugin Disabled): The opposite scenario can also cause issues: if a legitimate internal user does not have the snc_internal role in a system where the plugin is active, that user will be treated as external inadvertently. This could happen if someone manually removed snc_internal, or if the system property controlling explicit roles was turned off (see next section). Such a user might suddenly find they cannot see apps or records they used to, because all the internal ACLs are blocking them. Solution: Check the system property and the user’s roles. If the instance should be using explicit roles, make sure glide.security.use_explicit_roles is set to true (the default) and simply re-add snc_internal to the user if it was removed. They will immediately regain their normal access once the role is restored. Generally, you shouldn’t remove snc_internal from an internal user unless you intend to convert them to an external role.
snc_internal Marked as Elevated (Security Constraint): Never mark the snc_internal role as an elevated privilege role. In ServiceNow, elevated roles (like security_admin) require the user to manually elevate their session to use those roles. If an admin mistakenly set snc_internal to be elevated, it would mean every internal user’s basic role is now gated—effectively locking all internal users out of the instance’s normal functions until elevation is performed. This is a critical misconfiguration. Solution: If this happens, a system admin (perhaps the person who made the change) should immediately reverse that setting. The snc_internal role should remain a normal role. It is intended to be always-on for users, so they continuously meet internal ACL requirements. Marking it elevated defeats that purpose and will cause widespread access issues.
Understanding Logged-Out Users vs External: Note that neither snc_internal nor snc_external applies to non-authenticated users. If someone is not logged in at all (guest access), they have neither role. Typically, ServiceNow instances do not allow guest access to sensitive data, and this plugin does not change anything about guest/anonymous access. The explicit roles concept only kicks in once a user account is involved.

By keeping these common issues in mind, administrators can quickly diagnose and resolve access problems related to the explicit roles. Often the fix is as simple as adjusting a role on a user or tweaking an ACL to include the appropriate role.

Best Practices and Considerations for Administrators

Managing the snc_internal/snc_external roles is mostly straightforward, but here are some best practices and important considerations to ensure smooth operation:

Do Not Disable the Explicit Roles Plugin (Unless Absolutely Necessary): Once activated, the explicit roles mechanism becomes woven into your instance’s security. While it is technically possible to disable it (via the system property glide.security.use_explicit_roles=false), this is strongly discouraged by ServiceNow. Turning it off will stop the auto-assignment of snc_internal/snc_external, but it doesn’t automatically remove those roles from ACLs or user records. This mismatch can lead to confusing behavior in ACL evaluations and potentially leave some data unintentionally accessible or inaccessible. In short, disabling the plugin without a thorough plan can inadvertently weaken security or break access for users. If you believe you truly don’t need explicit roles (e.g., your instance has no external users at all), proceed with caution: you would need to remove snc_internal from all ACLs where it was added and ensure that internal users without roles still function as expected. In most cases, it’s easier (and safer) to leave the plugin enabled, even if the snc_external role isn’t actively used. There is minimal overhead to having snc_internal present on all users, and it gives you the flexibility to introduce external users in the future with proper controls.
Use Roles and User Criteria to Fine-Tune Access: The snc_internal role effectively groups all internal users together. Within that broad group, you’ll likely still have more specific roles (like itil for ITSM agents, hr_basic for HR users, etc.) to grant various permissions. Continue to use those specific roles for granting access to particular modules or records – do not rely on snc_internal alone to gate functionality except for the broadest distinction of internal vs external. For external users, you can similarly assign additional roles if you want to grant them specific capabilities. For example, you might create a role for an external user who is a partner that should see a special portal or data subset. They would then have snc_external + a custom role, and your ACLs could require that custom role. In service portals and knowledge management, prefer User Criteria to target content to users rather than hard-coding the snc_internal/snc_external roles in every case – this makes it easier to adjust audience logic without fiddling with global roles.
Never Assign Both Roles to a User: This was mentioned before but is worth reiterating as a best practice: a user should either be internal or external. If you find a process or script attempting to grant snc_external to an internal user (or vice versa), correct that logic. The platform will usually block it anyway, but even if it didn’t, having both undermines the security model. The presence of one of these roles should be treated as a trust boundary – internal means “trusted internal user” and external means “untrusted, limit their access.” Blurring that will only cause headaches and potential security gaps.
Plan Role Assignments During User Onboarding: When onboarding new users, decide upfront if they are external (customer/third-party) or internal. If you have automated user provisioning (say from an HR system or SSO), incorporate logic to set external accounts with snc_external. For example, if you integrate with an identity provider for a customer portal, ensure that new customer identities get tagged with snc_external via an integration script or Flow. This way, those accounts will not receive snc_internal on first login. On the other hand, internal employee provisioning should ensure snc_internal is present if the plugin is active (though the system will add it at login regardless, it can be useful to have it from the start for completeness).
Audit and Clean Up After Plugin Activation: If you activate Explicit Roles on an existing instance, take time to audit your roles and ACLs. Identify any users who perhaps should be external but are now marked internal and correct them (as discussed). Also, review any custom ACLs or scripts: if you had any that assumed “no role means external”, consider updating them to explicitly check for snc_external if appropriate. Ensure that any UI pages or modules that should be visible to external users have been updated to allow snc_external access – this might involve adding snc_external to module roles or page permissions. Essentially, treat the activation as a change that needs testing, especially in instances with a mix of user types.
Understand Licensing Implications: One common question is whether giving everyone snc_internal counts as giving everyone a role (which could affect licensing, since typically unlicensed end-users have no roles in ServiceNow’s licensing model). The answer lies in the fact that ServiceNow does not count snc_internal/snc_external as a role for licensing or for differentiating fulfiller vs requester users. As mentioned, the system treats users with only those roles as if they have no roles from a functionality standpoint. Thus, you can safely have snc_internal on all employees without suddenly requiring full licenses for all. Just be cautious that you don’t accidentally assign other actual roles to large groups of users via the internal role (for instance, adding snc_internal into a role group that also contains higher privileges would be a mistake – but that’s not a normal configuration).
Keep snc_internal Non-Elevated and Default: As noted, do not modify the snc_internal or snc_external roles’ basic properties. They should remain as ordinary roles. You should also avoid adding these roles into other roles (no role inheritance where snc_internal is a child of some other role, etc.). They are meant to be standalone markers. Similarly, it’s best not to rename them or repurpose them for something else – many internal platform scripts and configurations expect these exact roles to exist. Altering them could lead to unsupported scenarios.
Plugin Dependencies: The Explicit Roles plugin may depend on the Contextual Security plugin (which is usually active by default). In almost all cases this isn’t an issue, but just be aware that it’s part of the security architecture. Contextual Security provides the advanced ACL framework that explicit roles leverage.

By adhering to these best practices, ServiceNow administrators can ensure that the snc_internal and snc_external roles serve their purpose effectively – strengthening security – without causing user confusion or access problems.

Conclusion and Next Steps for ServiceNow Administrators

The snc_internal role and the Explicit Roles plugin are powerful features in ServiceNow that help maintain a clear separation between internal users and external users. For organizations that have both employee users and customer/partner users on the same ServiceNow instance, understanding this mechanism is crucial for proper instance security. The snc_internal role essentially wraps all trusted internal users under a common umbrella for access control, while snc_external does the same for outsiders. This doesn’t grant internal users extra abilities by itself, but it does prevent external accounts from accidentally slipping into areas they shouldn’t access. As we’ve seen, the plugin enforces some behind-the-scenes rules (like auto-assignments and ACL updates) to make this work seamlessly.

Key takeaways:

snc_internal is automatically added to all existing and new users (by default) when Explicit Roles is active, whereas snc_external must be explicitly assigned to flag an account as external. The two roles are mutually exclusive by design.
These roles serve as markers and do not inherently change what a user can do – internal users keep their prior access, and external users remain limited unless granted additional roles/permissions.
The system updates ACLs and other security rules to require snc_internal for previously unrestricted resources, thereby shielding them from external users. Administrators must explicitly allow snc_external where external access is needed.
Common issues (like external users not seeing content, or users having the wrong role) can be resolved by adjusting role assignments or ACL configurations – usually a straightforward fix once identified.
Disabling the explicit roles feature is possible via a system property but not recommended due to security side effects. It’s better to leave it in place and configure within its framework unless you have a compelling reason not to.
Following best practices – such as keeping snc_internal as a default role, not giving users both roles, and reviewing access after enabling the plugin – will help avoid problems and maximize the security benefits.

Next steps for administrators reading this article:

Verify Plugin Status: Check if the Explicit Roles plugin (com.glide.explicit_roles) is active on your instance. You can do this by navigating to System Definition > Plugins and searching for “Explicit Roles,” or by searching for the roles snc_internal and snc_external in your User Administration > Roles list. If you find the roles present, the plugin is active (or was active at some point). This awareness will inform how you manage user roles moving forward.
Audit User Roles: Review a sample of user records (internal employees vs. external contacts) to ensure they have the correct role. If you find external-facing users who somehow have snc_internal, plan to correct that. Likewise, ensure no users have both roles. This audit is especially important if the plugin was enabled after some users were created, or if you suspect manual role tinkering has happened.
Review Access Controls: Go through important application areas (Service Catalog, Knowledge Base, major modules in the Application Navigator) and verify that the intended audience can access them. If you want certain catalogs or knowledge bases available to external users, set up the appropriate user criteria or add snc_external where needed. For any custom tables or applications you’ve built, decide if they are internal-only or should allow external access, and configure ACLs accordingly (e.g., add snc_external to read ACLs for tables that externals should see). The goal is to avoid situations where an external user hits a permission wall unexpectedly, or conversely, to ensure internal data isn’t exposed.
Educate Team & Update Processes: Make sure your ServiceNow administration team is aware of the snc_internal/snc_external roles and how they work. Update your onboarding runbooks or integration scripts to properly assign snc_external to accounts that need it. If you have service portal developers, ensure they know to account for these roles when designing pages and widgets (for example, a portal page may need to allow snc_external role if it’s meant for customers). Having everyone on the same page will prevent role-related oversights.
Test Changes in Sub-Production: If you plan to enable the Explicit Roles plugin on a production instance that doesn’t yet have it, do so in a sub-prod environment first. Observe how it assigns roles and how your existing ACLs behave. Test with both internal and external user accounts to see if they can still do what they need to do (and conversely are blocked where they should be). If you must disable the plugin for some reason, also test that thoroughly in sub-prod since it can significantly alter access conditions.
Leverage ServiceNow Documentation and Community: ServiceNow’s docs and community forums have a wealth of information on this topic (some of which we’ve cited here). If you encounter a peculiar issue, such as a specific module not respecting the roles as expected, it’s worth searching the community or knowledge base. For example, if an out-of-box feature seems to ignore the snc_external role, it could be a known quirk with a documented solution. Staying informed will help you troubleshoot faster.

By refining your understanding of the snc_internal role and the Explicit Roles plugin, you can strengthen your ServiceNow instance’s security posture. This mechanism provides clarity and control: you can confidently grant broad access to internal users while keeping outsiders in a tightly governed sandbox. As an administrator, always keep an eye on who has what roles, and you’ll be well-positioned to manage both robust security and user functionality in your ServiceNow environment.

Experiencing challenges with ServiceNow support?