Category: Sitecore Hacks

How to include components in your Sitecore workflow without blowing up your Workbox

The situation

My team and I have been prescribing Sitecore workflows for well over a decade. These workflows generally focus on moving content pages through a workflow. However, as more structured page models have begun to give way to flexible design systems made up interchangeable components in a series of layout options, more and more content (data sources) have become abstracted from page content. This includes instance of rich text that make up the body content of a page. While this has allowed for maximum flexibility in layout, it has had unintended consequences for enforcing workflows.

When only the pages are assigned a workflow, it is not possible to properly version all the content, nor can we guarantee that no content gets accidently published and bypasses workflow. Most of our workflow implementations just publish the approved page and we have pipelines in place to smart-publish subitems and related items with it, effectively pushing it all through to web DB. With small teams and good governance, this may work just fine but for many clients this is not an acceptable solution. A content author with publishing rights could intentionally or accidentally publish page subitems and related items directly, forcing content live that was not approved. We have known for a long while how to add components in the Data folder of a page to workflow but the drawback is that every object in workflow, hundreds of generically-named component objects, are listed beside pages in the Workbox with no nesting or clear relationships. This negatively impacts the author experience by making the Workbox almost unusable.

The solution

I’ve done some research, consulted Sitecore MVPs, and couldn’t find an established answer on best practices for including local, component-level objects in workflow (not just pages) while preserving the author experience within the workbox.

The way I see it is that there are 2 options:

( 1 ) Keep all body content data source(s) at the page-level as it had been in the past, invalidating the need to put anything but pages into workflow. This means a much more rigid definition of page content model and layout. For very structured pages such as blog posts, articles, events, press releases, etc, this just makes sense anyhow for more reasons than just workflow. But the design team and stakeholders must be on board and the solution must be built this way across the board. For many clients, the sacrifice in flexibility on landing pages, campaign pages, and the like is a non-starter.

Or better yet…

( 2 ) Create a second, identical workflow for all non-page objects that have a data source. Along with former Sitecore MVP, Matt Richardson, we tested a proof-of-concept on this idea, assigning a copy of the workflow to components in the Data folder of a page and created a procedure to transition the workflow states of the subitems and related items along with the page’s workflow. It worked! In the Workbox, all the content author needs to do is deselect the workflow for non-pages and their view will be once again limited to pages. And the best part about it is that it does not require any customization to the UI so it should work just as well in XM Cloud as on XP.

*Example with both the page-level and component-level workflows displayed*

*Example with just the page-level workflow is displayed*

Option 2 is superior because it prevents us from having to choose between security and authorability. Feel free to try out this solution and let me know in the comments if you have found additional solutions that solve this problem.

Happy content authoring!

Expose Dictionary items in Sitecore Experience Editor

I frequently make heavy use of Dictionary items in my content architecture for chrome content that does not often need to be updated and that may need translated versions so we can cut down the number of managed data fields a content author needs to see on a daily basis. Currently, it is not easy to know where Dictionary items may have been used on a page. New content authors are often unaware that certain values are editable and even experienced content authors have to search for an item in the Dictionary tree, hoping that items were clearly named and organized. Sometimes, certain roles don’t even have access to this folder at all.

Making the items more explicit in Experience Editor solves this problem!

In collaboration with fellow Sitecore MVP Mark Stiles, we have created a method for allowing Dictionary items to be identified and edited without leaving Experience Editor.

1. Add new option to the View tab for “Show Dictionary items”

2. When “Show Dictionary items” in selected, display a Dictionary icon linked to the corresponding Dictionary item

3. When clicking on a Dictionary item value, reveal a custom experience button that allows access to a modal where the Dictionary item can be edited without having to leave Experience Editor.

This has had an immediate impact on content authoring for the sites we have used this method on so far, reducing the number steps takes to complete the task.

If you are interested in adding this feature to your solution see the GitHub and Marketplace module.

10 tips for optimizing the author experience and operational efficiency in Sitecore CMS

This year, along with Dominic Hurst of Valtech, I was very fortunate to have presented at the Sitecore Symposium in Las Vegas, Nevada. Both Dominic and I have worked on a variety of Sitecore installations and over the years have noted some mutual industry observations:

The role of the Content Author in modern CMS solutions has evolved into a multi-dimensional job. Too often these every-day heroes have to fight inflexible and uninspiring solutions to overcome the even smallest tasks
Many organizations spend the lion’s share of their budgets on CMS implementation, yet pay little attention to the efficiency of the operational processes that enable it
Poor authoring experiences can lead to UX erosion over time. Bad AX → Bad UX → Bad CX
Content authors are rarely empowered to aid in design, personalization, and performance analysis

Together at the Symposium we decided to address these observations and present our top 10 tips for organizations to empower their content authors to deliver real value on a daily basis. Many they can enact right away. Below are links to 10 blogs posts that cover each of these points in greater detail. We hope you enjoy these posts and, of course, please reach out to either of us to continue the conversation. Dan – @sitecorelations; Dominic – @dh_analytics)

Special thanks to Nicolai Winch Kristensen of Sitecore for coordinating and moderating our Sitecore Symposium presentation. May the force be with you!

Dynamically nesting local components with pages in Sitecore

The challenge

Information architecture and system design decisions can have a major impact on the ease with which content can be created and managed in Sitecore. Authoring experience is not always front-of-mind as architects and developers are shaping a system, but this can prove short-sighted as content teams begin to build content in the system.

During recent authoring experience audits of clients’ Sitecore platforms, I have noticed one key thing negatively impacting author efficiency. Many times, local components are not grouped with their parent page. While this is common and expected for globally shared components, it’s not recommended for unique instances of components referenced only by a single page. In one such case, there was a total separation of pages and components. There was an entirely separate directory for components that mirrored the page hierarchy manually. The rationale was that it kept page objects in the tree simple and uncluttered (which was true) but the end result was that authors were pre-creating all necessary components for a page ahead of time rather that authoring a page inline in Experience Editor. Rather than simply choosing from a list of allowable components and dropping an instance on a page, the first thing the content authors were required to do was establish a link to an existing data source. This really threw a wrench in the inline editing experience and was affecting content authors impressions of Sitecore – thinking “that’s just how it works.”

The solution

To allow for greater automation and improve author efficiency, dynamically nest components locally under each page object so that pages can be more quickly constructed and fully edited inline.

Through use of branch templates and standard values, a local Components folder can house all unique instances of components applied to a page. The content author doesn’t have to spend a lot of time thinking about where they should go. It reduces the number of decisions they have to make and speeds the authoring process. If you want to get fancy, you can even include sub-folders to keep multiple instances of different kinds of components organized (e.g. multiple rich text blocks, images, or videos).

This approach also simplifies the publishing process when you want to publish all components along with a page. Since these are sub-items, this relationship is easier to deal with rather than referencing components as related items.

This is something I have had a lot of success with and as the trend towards greater componentization in WCM systems continues it’s becoming a standard approach in the platforms Velir builds.