Allow different groups to manage their own response templates on incident forms.

soahmed · yesterday

We would like to allow different groups to manage their own response templates.

I have attempted to use the Group visibility, but this only seems to work for the sn_templated_snip.template_snippet_reader role.

When assigning the sn_templated_snip.template_snippet_writer role, this shows all the response templates and also allows the user assigned this role with the ability to create templates for any group. We assigned the role directly to the group but it is the same behaviour.

How can we have users from certain groups only view and create templates for their own groups? Does anyone know of hopefully an OOB feature that would allow this?

Ankur Bawiskar · yesterday

@soahmed

this is OOTB behavior

you will have to handle the restriction via manipulating the ACLs on table "sn_templated_snip_note_template"

OR

Check this link and see how the restriction is applied on email client templates, see if you can enhance that for your requirement

Email Client Template should visible to specific role.

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

Regards,
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader

Me Being Mustaq · yesterday

Hi @soahmed ,

The issue you're facing is a known limitation with the out-of-the-box (OOB) ServiceNow response templates and the roles involved. The sn_templated_snip.template_snippet_writer role, by design, provides users the ability to create and view response templates across all groups, which overrides group visibility settings. This means users with this role can create templates for any group and see all templates regardless of group assignment.

The Group visibility field on response templates limits visibility for users with the sn_templated_snip.template_snippet_reader role, but this control is not enforced for users with the sn_templated_snip.template_snippet_writer role. Writers see all templates across groups.
The default ACLs grant sn_templated_snip.template_snippet_writer role users full access, ignoring group visibility settings as a known behavior.
No direct OOB feature exists that restricts the create/edit ability of writers strictly to their own groups.
Some solutions recommend implementing custom ACLs and business rules to enforce group-level restrictions on writing templates.
Group visibility works as a view filter for readers but does not restrict creation or editing privileges for writers.

Recommendations:

Custom ACLs/Business Rules: Create custom Access Control Rules (ACLs) on the response template table and use scripting to restrict create, read, and update operations based on the user's group membership matching the template's group visibility field value. This enforces group-level restrictions beyond OOB roles.
Role Segmentation: Consider defining finer-grained roles (e.g., group-specific writer roles) and assigning these to specific groups, combined with custom ACL logic.
Use User Criteria or Conditions: Some ServiceNow users implement User Criteria or conditional checks to enforce group-based visibility and writing access, but this is not available out-of-the-box for this role—thus requiring customization.

There is no out-of-the-box feature that limits users with the template writer role to only create or edit response templates for their own groups. Achieving this requires customization of ACLs and possibly creating custom roles scoped by group membership. The group visibility field works only to filter templates for readers, but writers have broad access.

Please refer to the below link:-

If it is helpful, please hit the thumbs button and accept the correct solution by referring to this solution in the future it will be helpful to them.

Thanks & Regards,

Mohammed Mustaq Shaik

Allow different groups to manage their own response templates on incident forms.

Hi @soahmed ,

The Group visibility field on response templates limits visibility for users with the sn_templated_snip.template_snippet_reader role, but this control is not enforced for users with the sn_templated_snip.template_snippet_writer role. Writers see all templates across groups.​

The default ACLs grant sn_templated_snip.template_snippet_writer role users full access, ignoring group visibility settings as a known behavior.​

No direct OOB feature exists that restricts the create/edit ability of writers strictly to their own groups.

Some solutions recommend implementing custom ACLs and business rules to enforce group-level restrictions on writing templates.​

Group visibility works as a view filter for readers but does not restrict creation or editing privileges for writers.​

Recommendations:

Role Segmentation: Consider defining finer-grained roles (e.g., group-specific writer roles) and assigning these to specific groups, combined with custom ACL logic.

Use User Criteria or Conditions: Some ServiceNow users implement User Criteria or conditional checks to enforce group-based visibility and writing access, but this is not available out-of-the-box for this role—thus requiring customization.​

The Group visibility field on response templates limits visibility for users with the sn_templated_snip.template_snippet_reader role, but this control is not enforced for users with the sn_templated_snip.template_snippet_writer role. Writers see all templates across groups.

The default ACLs grant sn_templated_snip.template_snippet_writer role users full access, ignoring group visibility settings as a known behavior.

Some solutions recommend implementing custom ACLs and business rules to enforce group-level restrictions on writing templates.

Group visibility works as a view filter for readers but does not restrict creation or editing privileges for writers.

Use User Criteria or Conditions: Some ServiceNow users implement User Criteria or conditional checks to enforce group-based visibility and writing access, but this is not available out-of-the-box for this role—thus requiring customization.