How a custom template works
A template is a definition rather than a tag. You describe the fields somebody should fill in — an ID, a switch, a destination — and write the logic in Tag Manager’s own sandboxed language instead of ordinary JavaScript. Once saved, the template appears in the tag list beside the vendor tags, and colleagues create real tags from it by filling in those fields.
The sandbox is the part that matters. Template code cannot reach the page freely. It asks for specific permissions — to read a named data layer variable, to set a particular cookie, to send a request to a stated domain — and that permission list is shown to whoever installs it. Anything not granted simply fails rather than quietly succeeding.
Templates can stay private to your container, or come from the Community Template Gallery, where vendors and independent developers publish their own.
Why custom templates matter
They turn a risky one-off snippet into something you can hand to a non-technical colleague. The person creating the tag sees labelled fields, not code, so the usual failure of a pasted snippet — a wrong ID sitting in a line nobody read — becomes very hard to reproduce.
They also make permissions legible. With raw code you have to read it to know what it touches. With a template the permission list states it plainly, which is the difference between guessing and answering when a client asks what a third-party script on their site is allowed to do.
Where custom templates go wrong
The commonest mistake is installing a gallery template without reading its permissions. A gallery template is still somebody else’s code. The sandbox constrains it, but a template granted permission to send data to an unfamiliar domain is doing exactly that, with your approval on record.
The second is over-engineering. Writing and maintaining a template for a tag that will exist on one site, once, costs more than it saves. Templates repay effort through reuse or through delegation, and a one-off case offers neither.
How to act on it
Prefer the vendor’s official template, then a gallery template you have actually read, then your own, and treat a Custom HTML tag as the last resort. When you build one, expose only the fields a user genuinely needs and set sensible defaults for everything else, because every extra field is another chance to get it wrong.
Check the permissions on templates already sitting in your container, particularly any inherited from a previous agency. If that list is long or unfamiliar, folding it into a wider analytics and tracking review is more productive than opening each template one at a time.