Email client templates visibility for specific group

[Ciobanski]

Hello,

I am working on some Email Client Templates for Service Operations Workspace, and I got them figured out, now I am trying to create a condition so that the templates are visible for selection in the compose section only if the user who is on the record at the moment, is part of a certain group. 

The script itself is created, however I cannot find anywhere how to call it in a template.
Tried with the filters, but not sure which field (on incident or catalog task) should I use.

Is this feasible in ServiceNow? I have searched everywhere and I do not see any condition for this. Of course, without the implementation of custom fields. 
In case it is feasible, if it can be done without scripting, I am more than thankful for such a solution.


Thank you in advance!

Kind regards,
Daniel C.

[Ciobanski]

@Ankur Bawiskar 
Yes, in SOW I need it
So I add the script include in the template's conditions,

And in SOW I want it to work here

Basically, when I impersonate a user who is not in that certain group, "my template" should not be visible.

[Ankur Bawiskar]

@Ciobanski 

did you try to use Query business rule on "sys_email_client_template" table and see?

Try getting the URL and then restrict

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Ciobanski]

Hello @Ankur Bawiskar 

I have found this rather complex, I have tried denying the sysID's of the templates with glidequery in a query business rule, I have tried with a client script and glideajax based on a custom field i added on the template (reference to sys_user_group). Nothing seems to work on SOW.

[Ciobanski · Accepted solution]

Found solution.
Indeed it was a query business rule, but with a reverse logic.
If user not part of group (Condition)
Make only other templates visible via Query function.

[JessicaLanR]

Thanks for sharing your scenario in such detail. From what you described, the Performance Indicators (PIs) are still functioning properly, but the connection between Targets and Goals seems to have broken — possibly due to a platform upgrade or system change. The first thing to check is whether the scheduled jobs responsible for goal updates are still active. The key jobs are “Goal - Evaluate Goals” and “Goal - Update Actual Values.” Make sure these are still scheduled, running daily (or at the frequency you expect), and not failing silently in the job log. If they were disabled or misconfigured during the upgrade, that would explain why goal values stopped updating automatically. Another clue is your note about the “Next Review Date.” The fact that changing it manually to yesterday triggers the goal update suggests the system is relying on that date to execute the automation. It’s worth checking whether any business rule, scheduled job, or script used to update that date automatically — and if it was lost during the upgrade. Also confirm that the “Review Frequency” field in your Target records is correctly configured, since it controls how often the system reevaluates the goal. Beyond that, it would help to review system logs, especially filtering for terms like “Goal,” “Target,” and “PA,” to identify any errors or irregularities. If you want a deeper dive, you can enable debug logging for goal evaluation using the system property “pa.goal.log.level” set to “debug,” then manually run the job and watch the logs for insight. If none of this resolves the issue, consider checking ServiceNow’s Known Error Database or opening a support ticket — it's possible this behavior is due to a regression or change in the core Goal Management functionality. If this answer helps, please mark it as solved to assist others in the community.