A question that popped up in the SNDevs Slack had me curious and wanting to re-visit the topic of how easily it could be to implement reportability on template usage without a boat load of technical debt.

Within the community, SN Gurus' article on the matter is still referenced, even after 12 years! It requires multiple modifications to both server and UI elements which increases the risk exposure that some customers (rightly) get worried about.

As an alternative, this solution requires a new field, and a single modification to a Script Include...much more appetising.

Create a New Field

Create a new field using your favourite method, it should be a reference field to the Template [sys_template] table. This field will need to appear on the form view and be modifiable by the end-user. You can hide it with a UI policy to prevent any unnecessary clutter.

Modify an Existing Script Include

The Script Include that needs modifying is the OOB, and aptly named, Template Script Include. This script is used by the AjaxClientHelper script, which in turn is used by the template bar logic. This slight modification appends the template information to populate our custom field. The slightly less appealing option would require every template to specify populating the new field with a value...which somewhat negates the benefits of what we're trying to achieve.

The below few lines are all we need and are to be added to the getValues function, just before the var document = xml.getDocument(); line.

//Pass in template info to apply to u_template customisation
        var templateGR = new GlideRecord('sys_template');
        if(templateGR.get(this.sys_id) && target.isValidField('u_template')){
            var e = xml.createElement("item", null);
            e.setAttribute("displayVal", templateGR.getDisplayValue()); //Template Display Value
            e.setAttribute("value", templateGR.getUniqueValue()); //sys_id
            e.setAttribute("name", "u_template"); //field name
            e.setAttribute('label', target.getElement("u_template").getLabel()); //Field Label
        }

That's it! When a template is applied via the template bar, the template field will be updated and then reportable on.

Some Notes

This solution only tracks a single template and will be overridden for each template that is applied. There are a few options to enhance this solution and each one is dependent on your needs and visibility requirements:

• Change the field type to a list. A template will override the list rather than append, but this can be overridden via a before Business Rule that takes the previous and current value and unionises them.
• If you wanted to track at a more granular level, including whether a template is actually applied or backed out of, you could modify the Template script include to insert a record into a custom table that records the record and template being used. Once the record is updated with the applied template, a boolean field on the custom table could track this via an async business rule. This option would provide the ability for trend analysis and quantitive usage.
• Customisation isn't to be feared! Customisation vs. configuration isn't a black and white area, but rather a negotiation around ROI vs the technical debt introduced by doing so. Read more Configuration vs. Customization? - Wrong Question!