Adobe Launch Publishing Flow
Adobe Launch is the new (ish) tag manager tool replacing DTM, but it has some differences to DTM in the way that you approve and publish changes, so this post is highlighting how that flow works and the steps that you have to take. This isn’t going to be a technical explanation, so if you are a beginner to tag managers or have a passing interest in analytics, but someone has talked to you about this as a process they have to go through and you want to understand why things are taking longer than you thought, this should help.
So I’m back to writing some blog posts again after a while (I still have one that is sitting in my drafts that is mega, but it will take a bit longer to do) after some time off because of being busy with work and having a child to look after (there is so little time in the day!). But I’m just doing some things that are quite new and I’ve just updated the site so that it looks a bit more modern.
So let’s get to how this worked in DTM first so that we can see why this might be different in Launch.
In DTM the process for making changes was to make your changes to the rules or tools in the system and they then appear in an approval list:
Once in this list, if you have the appropriate rights you can choose to approve, edit or reject (back to the previous version or keeping the current version but not approved).
Whilst it is in this state, if you want to preview the changes on the site in question, you can do so using Switch, the handy add-on for your browser to change your DTM to the staging version, or if you have an actual staging environment with the staging code on it, then you’ll be able to see it there as well (without Switch).
This will show you all the changes that are currently in the approval list as well as all those changes that have been approved but not published, which is the next stage of the process if you have the appropriate rights. This can sometimes mean it is difficult to isolate where you have errors if you have multiple changes waiting to be approved all at once.
In Launch the process is slightly different. In Launch you actually have three Environments to play with and the ability to create many libraries can sit in one of those environments (or not in an environment at all). You can then work in a single library which you can promote to Development if you want to test there or to Staging if you want to test there.
In the example above I have three libraries currently on the go (and I’m just about to create a fourth). Each of the three libraries has a completely different set off rule changes included in them with no overlap (but they could overlap if you wanted them to). Here one of the libraries (‘Hotjar’) is currently in development and a different one (‘Customer Portal New’) is currently in Staging.
In Launch Switch (which is actually the same add on) you can then choose whether you are looking at Production, Staging or Development
Each of those environments also has their own embed code, so you could (if you wanted to) pass these different codes on to different environments for testing without Switch.
Now I’m able to do changes for one team to test whilst another team is also testing some different changes without them interfering with each other (admittedly in this case they wouldn’t have, but that isn’t always going to be the case) and when I need to, I can push whichever one of them live that I want first (more of than in a minute).
But now I need to make a different Library for a new change I am making. There are two choices here – I can make the changes to the rules in question and then create the library, adding in the changes at that point. Or I can create a new Library that mimics live and then add the changes to it as I go along (I’m going for the latter):
Note, as you can see above I don’t have the option of adding this to the development library – this is because there is already a library in development and I’ll have to demote it out of there before I am able to push this new library into development.
Now I’ve created the library I can go and make the changes I need to and add them to the library. The way I’m doing it, the easiest option is to choose the appropriate library from the drop down above save and then choose to save it there:
Having made my changes and added them to the library, you can go back to the publishing Flow and look in your library and make sure your changes are there (note that they aren’t editable from here because this is just a snapshot):
Note that at this point I can choose to add resources that have changed but have not been added to the library or indeed include all changes (if you so wished). I don’t as there are a number of changes that are in the system that aren’t ready to go live. What I want to do is to push this library to a point that I can test the changes I have just made.
However currently the two test environments are occupied by other libraries. To get this library into the development library I need to first go into the library that is currently in development and move it to ‘none’. Then I can go back into this library and choose to add it to development. The next thing I need to do is to build it for development, otherwise it won’t have collected all the saved changes (note that the option to build is scattered around in various ‘save’ points as well and you can choose to build each time or save without building and build later).
Now it is built for test, I can go and test the environment (or live with Launch Switch enabled) and make sure I’m happy with it. In this case this was a simple test and I am happy with it straight away and would like to promote it to live (but you can leave this here for as long as you need to or until something else needs to be tested and then demote as I did with the other change that isn’t ready to go live yet).
(Worth noting as an aside here that there is an option within Launch of having multiple development environments so that multiple people can do things at once. In this case because the team is small we’ve opted for just one standard development environment.)
To get this change to live it needs to have an approval process – firstly it needs to be approved and published to staging. However I currently already have a library in Staging, so it won’t let me do that. Instead what I’m going to need to do is reject my change from the Submitted queue so that it is back without an environment:
After I have rejected this one from staging, I can then submit for approval my new library. Once it has been submitted I then need to build the library for Staging. Only once it has been built for Staging is it possible to approve for publishing. Once it has been approved for publishing it is then just waiting for someone to give it the final go ahead to be released out into the publishing environment.
Normally at this point I like to do a little look left, look right action and double check by looking through the rules and checking that they aren’t doing anything different to what I thought they were doing, before pressing publish.
My last job now, is to push all the other libraries back into the environments they were previously in, just in case someone wants to do some more testing. Note that these existing libraries now also include all the changes that I just pushed live. If I want them to not include this then I’ll have to roll back the changes by choosing previous revisions within the rule and saving into the library.
So there we have a slightly more complicated process of pushing changes in your tag manager than in DTM, but a few more options to it as well.