Reporting on Template Usage

[Kieran Anson]

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!

[Jason S1]

I think there may be a slight mistake in your chunk of code. The 'u_template' field is created on whatever table/form you will be applying the templates to, correct? In your conditional:

if(templateGR.get(this.sys_id) && templateGR.isValidField('u_template')

You are checking the templateGR for the custom field rather than your form. As is, the code block will never run as u_template doesn't exist on sys_template. Changing it to the following fixed it for me:

if(templateGR.get(this.sys_id) && target.isValidField('u_template')

As an aside, I'm the one who originally asked the question in Slack (thanks again) and this appeared to originally work for me because I had already created a custom field in my scoped app named 'template' and just changed your snippet to work with that. 'template' DOES exist on the sys_template table, thus the code would ALWAYS run. Which made it work great for the form it was working on, but ended up completely breaking the template bars functionality for every other form haha

[Kieran Anson]

Updated the type, thanks for spotting! 🙂 

[spike]

Right at the very end of this you mention the template bar.. would this always work for Response templates? Or could it be modified?

Thanks!

[Kieran Anson]

@spike not sure I understand your question sorry?

[spike]

Thanks for responding. In the article you make the comment, "When a template is applied via the template bar, the template field will be updated and then reportable on. "

I was wondering if you could apply a similar process or logic to Response Templates. I'd like to track their usage in a similar way. I was thinking I could track when the Copy to clipboard button was pressed but I've not found a way to hook into it.

[Su522]

For any form, you can mirror the below steps:

On the Project form > add a new String Field

On all your Project Templates > add the same String Field > populate it with the Template Name

On the project form, make the new String field 'Read Only' and you can even hide it.

You can now report on Projects created by which Template