*This is an editorial piece about my thoughts and disappointments on Guide Template Language in Salesforce Marketing Cloud. This post may contain opinions or other speculative information in it, so do not use it as a definitive reference about GTL or as a full factual history of the language.

Inside of Salesforce Marketing Cloud, there is a single language that seemingly came out of nowhere and had everyone super excited…then it just as suddenly faded away into near nothingness – Guide Template Language

GTL reminds me of Samuel L. Jackson from Deep Blue Sea (be warned, video is NSFW) or the twist of fate that awaited Eddard Stark (spoilers if you did not watch GoT) inside the beginning of Game Of Thrones. It started out so cool and so strongly for developers in SFMC, but then abruptly and promptly just…stopped.

When it first was unleashed, GTL was shown to be so powerful and performant, that it actually replaced AMPscript in the ‘back end’ templating of Content Builder. It was clearly stated that it is a templating language and not a scripting language, so it would not be an ‘AMPscript killer’ – but there was worry and predictions it would likely become a replacement for most use-cases of SSJS.

From this powerful position in its release in 2016, it pretty much just stopped and faded into obscurity by mid 2017. Wait…what? In less then a year it went from an unstoppable juggernaut to…basically forgotten? YEP.

How Did This Happen?

Well, that is the question of the ages and there are a ton of theories around it. My personal favorite is that the person who came up with, developed and was leading the charge of it left the company and no one else there had any knowledge, documentation or investment in it – so it just sat there incomplete and stagnated. I just really like the poetry of this theory and the level of power it shows that developers can have despite most people viewing them as nothing more than ‘code monkeys’.

Now, there is nothing beyond circumstantial evidence to back that up, nor really ANY word into what happened to GTL officially. Despite my desire for that lone developer theory to be true, it likely is not. It probably had something more boring as a reason – like lack of adoption combined with internal restructuring lead to a loss of interest in development and maintenance, leaving a half made and half implemented language.

What Do We Know?

Although we do not know the official ‘how’ GTL fell from grace, we can see the ‘what’ (as in what happened) through public opinion and news/blogs over the past few years.

Basically, GTL was released prior to being completed, fully integrated or fully documented. This led to many issues, including:

  • It not working as documented or intended (and in some cases, not working at all) in Landing pages/ CloudPages
  • The language was unlike anything else that is used in SFMC, so for those specialized in the platform, it was like starting from square one.
  • A very steep learning curve due to the non-existent ‘beginner level’ documentation or language background
  • Documentation included capabilities and functions that were not yet implemented into GTL

With these issues, it created a ton of confusion and frustration in the SFMC developer community, causing a good majority to just said ‘fuggedaboutit’ and went back to just using AMPscript and SSJS. Most were figuring that once SFMC got their ‘stuff’ together they could come back and try again…..but then SFMC never got their ‘stuff’ together at all and seemed to ‘fuggedaboutit’ as well.

How Useful is GTL?

GTL still definitely has its uses (mostly around parsing JSON) and can be very complimentary to AMPscript, but in all honesty – you are much better off just learning Sever-side Javascript instead as it has a multitude of other uses that make the language much more valuable than GTL.

I equate learning GTL to learning Smart Capture. Sure, it can make life easier and is an impressive skill, but it is only really good at one thing and outside that one thing, that knowledge is useless. In comparison to learning AMPscript and/or SSJS, which can be used in any types of messaging, landing pages, scripting resources as well as they can translate pretty well to other scripting languages, makes for a much larger return on effort.

GTL really only has the single use – Parsing a JSON for use in AMPscript.

How Do I use GTL?

I would say nearly exclusively, the only time anyone ever uses GTL is in relation to a JSON being passed to an email. Around this scenario, GTL requires you to declare this as a data source, like so:

{{.datasource JsonVar type=variable}}
 {{.data}}
  { "target" : "@Json" }
 {{/data}}
{{/datasource}}

This will take the AMPscript variable @Json that is holding the string version of a JSON file and convert it into a sort of rowset that GTL can then use for iteration and dissemination.

Full example of GTL setup with variable being set from the data source:

/* Declare Json variable */
VAR @Json
SET @Json = [JSON_PAYLOAD]
]%%

{{.datasource JsonVar type=variable}}
 {{.data}}
  { "target" : "@Json" }
 {{/data}}
{{/datasource}}

This works great as you can then use Tags inside the declared data source to fill in as a substitution marker. For example: {{FirstName}} would fill in as Jill from this JSON datasource:

{"FirstName":"Jill", "LastName":"Jillington"}

Super cool and it integrates fairly well with AMPScript, as you can set AMPScript variables from it, like so:

/* Declare Json variable */
VAR @Json
SET @Json = '{"FirstName":"Jill", "LastName":"Jillington"}'
]%%

{{.datasource JsonVar type=variable}}
 {{.data}}
  { "target" : "@Json" }
 {{/data}}

%%[
  SET @FirstName = TreatAsContent("{{FirstName}}")
  SET @LastName = TreatAsContent("{{LastName}}")
]%%

<p>Hello %%=v(@FirstName)=%% %%=v(@LastName)=%%, its so nice to meet you!</p>

{{/datasource}}

Would output:

 Hello Jill Jillington, its so nice to meet you!

I don’t want to take away from the fact that this is super cool and helpful….but there is also a much less cool and helpful side. Despite the fact that the documentation tells you there is a way to parse a straight JSON array, it actually really can’t.

Due to the similarity in the documentation for Handlebars, I am guessing a good portion of the GTL docs was just ripped from there – regardless if it was actually implemented or not. This is one of those cases that I think very distinctly shows the ‘incompleteness’ of GTL in the most profound way.

This, on top of the fact that the documentation really does not get into the day to day usage and is still very much reliant on pre-existing knowledge in order to understand on it, makes GTL a much less viable option. Oh and there is also the fact that everything GTL can do, SSJS can do better.

If SSJS Can Do It Better…Why GTL?

Now that is a really good question. In all honesty, the only reason to use GTL instead is if you want a very quick simple JSON parser to go with your AMPscript without needing to learn any SSJS. The speed factor of it is really non-existant as from all tests I have run, GTL JSON parsing is right around at the same processing speed as it is using SSJS. So really, its just about how comfortable you are in SSJS as to if you should use that or GTL for the simple JSON parsing needs.

Now that being said, if you need to do a ton of nested objects/arrays, you are using straight arrays or need to use some complex logic/conditions…then I would say you are going to NEED SSJS or you are going to have a hell of a hard time forcing GTL to do crazy things to make it do something it is supposed to be able to do natively.

For instance, when working with straight arrays, you would need to take that array, turn it into an array of objects with a name (e.g. ["this","that"] turns into [{"value":"this"},{"value":"that}]) which adds logic, processing and code.

Please feel free to read about my SSJS intro if you are interested in picking it up (I know I am a bit biased here) or feel free to explore the official ‘documentation’ of Guide Template Language and see if you can make any sense of it. I would highly recommend using Salesforce Stack Exchange for examples, answers and ‘walkthroughs’ on using GTL instead of the official docs though.

Tags: , , , , , , , , , , , , , , , , , , , , , , ,
Subscribe
Notify of
guest
3 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Milan Simic
Milan Simic
3 years ago

If you need to display an array of objects in an email, GTL seems to use fewer lines of code than JSON. I like it for that – it looks clever, doing something cool with very few lines of code. Unfortunately some of the content block types remove GTL automatically, so that’s not so helpful. It will work the first time you configure it, but if you ever go back to the same content block and try to edit you’ll notice chunks of code missing. That’s more of an issue with Content Builder in general, but it’s an issue. You have to save the code elsewhere and replace the whole content block every time you need to edit. Not a great solution if you have different developers working on it.

Christian
Christian
2 years ago

I had to try my way through GTL back in 2017/2018. At that time SF still said that SSJS should not be used within emails due to processing time concerns.
Once you got the hang of it, its alright.. but I wouldnt recommend it anymore. Without proper documentation and no big benefit using it, just go with SSJS. And honestly.. I wouldnt be surprised if in any upcoming release notes the EOL is announced.

Vishal Kumar C V
Vishal Kumar C V
2 years ago

This is so helpful every time I use have to work on GTL. Thanks Greg 🙂