A Missing Field Type - Part 1

If you haven’t read my post from last year about Sitecore’s Items, Fields, Versions, and Languages I would recommend that you do it first. In this post i will make an argument that Shared, Unversioned, and Versioned is not enough and we need another field type - Workflowed. Even if only for one particular field.


Shared fields are very basic. Value of a shared field has no language variance and no history. It cannot be workflow controlled and it cannot be restored to a previous value. You probably rarely use them on content items managed by the authoring teams exactly for the reasons outlined. You will find them, however, on the Standard Template and throughout the Sitecore internals in general.

Things that are inherently global and stable, things that an item either has or doesn’t have, things that never vary across translations, things that don’t change how an item is rendered - these are the qualities of a shared field. Good examples - __Is Bucket and __Enforce version presence. Bad example - __Renderings.


Unversioned fields are rare these days. Value of an unversioned field will differ across translations but it still has no history and no workflow support. Same qualities as Shared basically plus a per-language variance. An attribute of an item has to be textual or otherwise different per language and yet be global and stable to warrant an unversioned field. Good example - __Short description from the Help section.


The bread and butter of content items. Supports language translation, has history, and is subject to a workflow. What’s not to like? The majority of the fields you create should be versioned. Well, at least they should have history and workflow support and what other choice you have then, right?

Having both language and version angles can sometimes produce friction. You can have former without the latter (the Unversioned fields) but not the other way around. If you need history and workflow - and you do almost always need it - you have to also deal with the fact that each language translation has its own value.


I feel that we need one more field type. Unversioned fields add the language (translation) dimension to the Shared fields. Versioned fields add the version (history and workflow) dimension to the Unversioned fields. What if I wanted history and workflow support without language variance? What if there was a Workflowed field type that was subject to a workflow and supported history rollbacks but didn’t have the language angle? Basically, a version dimension added to the Shared fields.

A field without a language angle represents something that is the same across all translations. If you use Shared field type you subject yourself to accidental publishing of new values while everything versioned is still in the draft state. If you use Versioned field type you have to maintain the same value for all translations contract.

Why is it a problem? Next time on this blog. Stay tuned for Part 2.


Do you have a dedicated devops person on your team? Maybe you have a shared team of devops engineers? Do you hire for devops role and build centers of excellence (CoE) around it? These engineers are responsible for environment provisioning and builds, they create and maintain your CI/CD pipelines, they chose a specialization in Chef or PowerShell DSC or Gradle? If you are Rackspace or a Rackspace-wannabe, then you’re probably on the right track. And if you are not then I don’t think you are doing it right.

A dedicated DevOps role is basically ops co-located with devs. It’s a lot better than old school functional structure with ops and devs isolated but it’s not yet the DevOps nirvana.

Let’s make a step back for a second. What are we trying to achieve? Use the modern infrastructure-as-code toolset? Be more agile in the operational aspects? Deliver continuously? Or maybe we also want shared responsibility? Devs thinking about Ops concerns (migration, monitoring, scalability, automation, instrumentation, upgrades, business continuity) when writing code and designing systems, not after? Not just deliver continuously but do so with confidence? Maybe we also want to better our dev teams? Make them not only full stack but also cross stack?

Expose your dev teams to ops concerns. Make them orchestrate provisioning and automate builds. Make them monitor and instrument their deployments. Have them learn some Chef, Shell, Powershell, Gradle, Buildr, Capistrano, Whathaveyou. It will only make better technologists out of them. Dedicate ops to run the underlying stacks (the vSpheres, and Swarms, and Kuberneteses of the world), to expose custom infrastructure concerns as code, to maintain an ever-growing repository of scripts and images and containers, to establish best practices. Using it should be part of the dev role.

What doesn’t kill you makes you stronger. Or so it should.


Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now