What is workflow on SDL Tridion Component and Page Templates used for?

Question

I have noticed in both SDL Tridion 2009 and 2011 that on the workflow tab of the Publication Dialog there is a field for Associated Page Template Process and Associated Component Template Process.

Does this imply that template/code changes can be made in production and released through a workflow process? Is this a good practice? If that is the case, why is their no workflow process association for Template Building Blocks?

Answer 1

The intent of this is not use in Production, but you could use it during your development phase. I see this feature beneficial for Code/Template design review process where developer develops the templates and workflow kicks off then Team Lead reviews it and approve/reject the changes.

For Production/UAT/QA, NO.NO.NO. (just want to stress this hard enough:)) it is not a good practice IMHO. You should go through change management process using content porter package export/import, typical DTAP.

Why there is no workflow on TBBs? TBBs will be part of CT/PT anyway so when you review CT/PT they are explicitly included in the review. However, I see your point that there could be cases where you just update the TBB and no workflow kicks off.

Hope this helps.

Answer 2

This is legacy functionality that could have been used with non-compound VB templates before compound templates came along in Tridion version 5.3. However, today this will not be of much use since TBBs won't be included in the workflow, so all you can control via workflow is the page/component template piece, but not the TBBs inside.

Answer 3

As far as I know, the workflow processes for templates work as you suggest. However last time I checked (in the 2009 version), the Minimal Level of Approval status was not respected when publishing items. Unfortunately this means that your template changes will always be immediately available to all targets when someone publishes. Because of this I would always recommend making template changes in a Development environment rather than a Production environment, and manage the release of templates using the Content Porter.

Your point on TBBs is a good one - since R5.3, modular templates have made extensive use of TBBs, and as such I think this feature may have been overlooked. If the TBB issue and the Minimal Level of Approval issue were fixed, you could create some very interesting release scenarios for launching newly designed sites.

Answer 4

As others have suggested, your approach to releasing templates should make use of Development-Test-Acceptance-Production (DTAP) environments. The complexity of this set-up will depend on your specific requirements.

Using workflow for development work is more than likely unhelpful. A lot depends on where the different developers integrate their work. If you have multiple DEV environments, then each individual developer is unlikely to want workflow on their own system. Assuming you integrate on one of the DEV machines, or perhaps on TEST, you won't want workflow there either, as when a developer commits a change, it will mostly consist of multiple assets, each of which would have to go through workflow separately, with some parts of the change visible to others while this happened, and others not. If all your developers work on the same server, then these aspects of workflow will hurt even more.

Workflow is mostly useful for managing releases of single unrelated assets one at a time. Typical development work isn't like this, and frankly the amount of extra steps would be just overhead, and wouldn't remove the need for the normal development disciplines. As Quirijn notes, people don't do this. I too have never seen it, and I'm very happy to say that.