Sitecore MVP 2019

Sitecore MVP 2019

Humbled and pleased to announce that I’ve been again named a “Most Valuable Professional (MVP)” by Sitecore® for a second year running (2018, 2019), winning in the area of the Strategy. A lot of hard work and focus on solving clients’ problems via the Sitecore platform has paid off once again. Looking forward to another active year in the community!

Some info about the program below:

Now in its 13th year, Sitecore’s MVP program recognizes exceptional professionals from the Sitecore community who actively share their expertise of Sitecore products to advance the future of customer experience and drive organizational change. A distinguished group of 315 Sitecore experts from the more than 12,000 certified developers and more than 20,000 active community participants, Sitecore MVPs’ are awarded for the quality, quantity, and level of impact of the contributions they make by sharing their product expertise and mastery of the Sitecore platform with other Sitecore partners and customers.

“The Sitecore community is renown as a place where members can easily collaborate and benefit from the vision and technical knowledge of one another,”

Pieter Brinkman, Senior Director of Technical Marketing at Sitecore.

“Within this community, MVPs set the standard of excellence for product expertise, enthusiasm, and willingness to donate time and energy to help customers and partners realize the full power of the Sitecore platform. Their passion is instrumental to the ongoing success of the Sitecore ecosystem.”

The Sitecore Experience Platform™ combines web content management, omnichannel digital delivery, insights into customer activity and engagement, and strategic digital marketing tools into a single, unified platform. Sitecore Experience Commerce™ natively integrates content and commerce so brands can fully personalize and individualize the end-to-end shopping experience before, during, and after the transaction. Both platforms capture in real time every minute interaction—and intention—that customers and prospects have with a brand across digital and offline channels. The result is that Sitecore customers are able to use the platform to engage with prospects and customers in a highly personalized manner, earning long-term customer loyalty.

More information can be found about the MVP Program on the Sitecore MVP site:

Impressions from Sitecore Symposium 2018

Impressions from Sitecore Symposium 2018

This was my second time at Sitecore Symposium as a speaker and it was interesting to compare the experience year-over-year. I’d been to a SUGCON in New Orleans and Berlin which were more developer solutioning focused, but Symposium in comparison is a much more curated production with a lot more insights and tips on offer for analysts, strategists, and business users. As one of my colleagues puts it, “SUGCON is a music festival and Symposium is a rock concert”. Rock You Like a Hurricane should have been the theme song this year consider the storm that blew through Florida. Despite the storm plenty of folks showed up to hear Mark Stiles and I deliver a talk on supercharging your author experience with Machine Learning. Lots of great questions, comments, and even a few solid leads we are pursuing at Velir!

This was my first Sitecore Symposium as an MVP, and it was great opportunity to learn more about the latest release of Sitecore and what’s on the future road map. Some themes emerged that I am really excited about.

A focus on operational efficiency for content authors and marketers

The Sitecore team recognizes that there is an ever-growing list of new tools and marketing features that we are expected to master. Authors and developers need to be more efficient in what they do and the platform itself can drive a lot of this efficiency. I was very encouraged by what I saw coming in down the pike from Horizon, Sitecore’s author experience overhaul initiative. While I can’t talk about some the specific beta enhancements we saw at the MVP summit I can say that the new interface will be miles more intuitive, reduce context switching between Experience Editor and Content Editor, and integrate page level analytics to provide better context for making decisions. They also showed some images of a revamped launchpad and analytics dashboard that will really bring some parity with other enterprise XP solutions like Adobe. Can’t wait! The acquisition of StyleLabs promises platform maturity, owning more of the creative process and end-to-end tasks so content authors need not work in as many solutions. And finally, machine learning is beginning to be applied for practical use in the authoring and personalization space (via Cortex and other services). It’s not magic, it’s SCIENCE!

Maturing technologies and frameworks

The promise of more seamless connection with the rest of the marketing ecosystem is becoming realized with deeper integration with Salesforce and other apps via xConnect. JSS promises to allow Sitecore to provide headless front-end solutions that still allow you to enjoy the power of the Sitecore back end and its experience editor. SXA foundation continues to solidify and the package is growing, taking some pressure of developers to bootstrap common components and accelerate the pace of development.

Overall, I walked away encouraged and excited to be part of what comes next!

Crafting a Sitecore content authoring workflow that works for YOU

Crafting a Sitecore content authoring workflow that works for YOU


If there is one area of Sitecore platform implementation that is commonly misunderstood (and often forgotten altogether) is it the creation and management of a proper content authoring workflow. Sitecore workflow can be a complex and unwieldy thing, depending on the client’s requirements, and it can be poorly implemented despite some Sitecore sponsored cookbooks available on the portal. As content authors struggle with an overbearing or restrictive workflow they may resent what they feel are unnecessary hurdles keeping the from productivity. And turning authoring teams loose with no workflow at all is like free-climbing without a rope. There is, however, a happy medium. Configured well, a basic workflow with sensible guard rails/guides can actually enhance the author experience.

The goal of this post is to provide guidance on setting up a proper workflow and scaling it to the specific needs of the client. I’ll layout my prescription for what we I believe a standard workflow model should be and some ways in which workflow can be customized to handle advanced authoring needs.

What is the purpose of content authoring workflow?

  1. To give content authors appropriate abilities according to their role (i.e. prevent rogue actors)
    • Note that this inherently means avoiding Admin access for normal, everyday use since…
      1. Admins can bypass workflow controls
      2. Admin accounts do not trigger automatic, built in benefits (e.g. versioning, locking content)
      3. Admins have access to fields which can potentially cause harm by content editors who do not fully understand their implications
  2. To control the flow of content to the site and allow oversight of published content (e.g. ensure consistency, prevent premature deployments)
  3. To record the content author, date, and steps taken in the lifetime of a piece of content so a comprehensive paper trail exists
  4. To improve usability of the CMS interface by simplifying the UI to include just the tools applicable to their role

What does a good workflow look like?

First and foremost, keep it simple. Most organizations needs aren’t all that complex. Their authoring teams are relatively small. In my experience most just need a basic, Author/Publisher role-based workflow that provides change history/notes, protects critical items and nodes, enables role-based views of ribbons, and integrates scheduled publishing.

Below is a diagram of a simple but custom configuration of a workflow relies on just 2 user roles – Author and Publisher. The former having all the rights of the Publisher except the right to publish. Unless you really need an interstitial Approver role this tends to suit most clients.


Additionally, it includes the option to schedule publish as well as unpublish an item as explicit workflow commands so the content author with publishing rights need not fumble with Change Restrictions. The workflow states look something like this.

image2015-12-3 10:2:43.png

Schedule publishing command

A pre-publishing workflow state like Awaiting Approval can be configured to additionally include a command for Schedule Publishing which will more clearly fold the existing publishing restrictions function into the workflow proper. Initiating this function launches a modal that allows the user to select the date/time when the item should be published. The auto-publish function in Published workflow state will take this date into account and publish only when the current date/time is now. Scheduled publishing may be deployed in batches every 15 minutes for system performance in which case the item would be added to a publishing queue.

Unpublish command and workflow state

Published items can be configured to have an additional command for an Unpublish action available to publishers only when an item has been published to production (taking into account Scheduled Publishing when applicable). This option better integrates unpublishing into more familiar workflow actions rather than relying on marking items as unpublishable by other means. Selecting Unpublish will remove the item from production and it will remain in a state called Unpublished unless deleted or republished. The Unpublished state should not be visible in the Workbox.

Defining roles

Once you’ve got a firm handle on the client’s unique workflow requirements, it’s time to start thinking about roles. A Sitecore workflow requires a collection of user roles, content access roles, client access roles, workflow roles, and optionally notification roles. Together with the proper role hierarchy we can construct a simple and clean workflow.

User Roles

There are several types of roles but the only type that the average Sitecore business user will need to be concerned with is the User Role. Ultimately, just one of these roles will be assigned to every user of Sitecore and the other supporting roles will be inherited (as I will outline in a bit more detail below). Here are a couple common implementations of User Roles.

Simple workflow model

The majority of client’s really only need a simple, enforceable Author/Publisher relationship where the only real difference between the two is that the Publisher can publish.

  • ClientName Author
    • This role will have write access to nearly all content in Sitecore aside from a few specific areas that will be denied for the protection of critical system nodes. This is a powerful workflow role in terms of access rights but they cannot publish.
  • ClientName Publisher
    • This role will be the least restricted of the roles defined in the simple workflow model. Only those marked as “admin” will have more privileges. This role inherits all the rights of ClientName Author but may additionally publish.

Intermediate workflow model

In some cases, a client may require and intermediary layer to their workflow where some members have approval rights but not publishing rights. Imagine a large organization with thousands of pages and just a few Web Content Managers with real authority to decide what should and shouldn’t make it to production. Ultimately a publisher will have final say and control the levers for deployment.

  • ClientName Author
    • This role will have write access to nearly all content in Sitecore aside from a few specific areas that will be denied for the protection of critical system nodes. This is a powerful workflow role in terms of access rights but they cannot approve or publish.
  • ClientName Approver
    • This role inherits all the rights of ClientName Author but may additionally approve content for publishing.
  • ClientName Publisher
    • This role will be the least restricted of the roles defined in the intermediate workflow model. Only those marked as “admin” will have more privileges. This role inherits all the rights of ClientName Author and ClientName Approver but may additionally publish.

Advanced workflow model

Lastly, here is an example of an advanced model by which the client is further stratifying roles and responsibilities to ensure that strategically important, centrally managed content sections are off limits to some members or that they are limited to just a specific zone (in this example, a blog)

  • Top tier
    • ClientName Author
      • This role will have write access to nearly all content in Sitecore aside from a few specific areas that will be denied for the protection of critical system nodes. This is a powerful workflow role in terms of access rights but they cannot publish.
    • ClientName Publisher
      • This role will be the least restricted of the roles defined in the simple workflow model. Only those marked as “admin” will have more privileges. This role inherits all the rights of ClientName Author but may additionally publish.
  • Middle tier
    • ClientName Author Limited
      • A second tier of author and publisher will exist to allow wide access across many content areas while protecting the home page, landing pages, and other more centrally managed content areas
    • ClientName Publisher Limited
      • This role inherits all the rights of ClientName Author Limited but may additionally publish the content for which it has access.
  • Lower tier
    • ClientName Author Blog
      • A third tier of author and publisher will exist to allow access to only content within Blog section, excluding the landing page. This tier will have a unique set of basic content access rules different from top and middle tiers.
    • ClientName Publisher Blog
      • This role inherits all the rights of ClientName Author Blog but may additionally publish the content for which it has access.

Tiered Access Hierarchy

It is best practice in Sitecore to define user roles by assigning to each a set of core capabilities in the form of inherited parent roles in Sitecore that control content access, client access, and workflow options. Only a single user role will be assigned to each Sitecore user and the appropriate access and workflow roles will be inherited automatically. Below you can see how the roles outlined above will define workflow entitlements and prevent conflicts. We can think of these grouped into one of three tiers in terms if their level of access.

  • ClientName Author
    • ClientName Author Content Access
      • ClientName Content Access
    • Sitecore Client Authoring
    • Sitecore Client Designing
    • ClientName Author Workflow
      • ClientName Workflow
  • ClientName Publisher
    • ClientName Author Content Access
      • ClientName Content Access
    • Sitecore Client Authoring
    • Sitecore Client Designing
    • Sitecore Client Publishing
    • ClientName Publisher Workflow
      • ClientName Author Workflow
        • ClientName Workflow

Which are some custom features are worth considering?

There are some advanced, “next-level” workflow features that have been requested and implemented by Velir in the past that definitely fall into the custom development category. Certain actions within Sitecore Content Editor are not strictly defined by workflow but help make the process a lot more efficient and the author experience more pleasant. Here are some examples.

Sitecore ribbon customization

Customize the Sitecore ribbon to be more intuitive. Certain functions are only appropriate for certain roles. Below is a list of tabs and buttons that are conditional based on role.

  • Publisher roles only
    • Tabs
      • Publish
        • Only Publishers should see this tab since authors will not have publish rights. Though the Publish button is available to Publishers no item that is in workflow may be published so as to not bypass workflow. A warning will be displayed encouraging the publisher to take the item through workflow.
          • Note that this will require replicating options for Preview and Page Editor in the Review tab instead so that authors may still have these functions without exposing Publish.
          • Items that are not in workflow will require the Publish button such as those found in Media Library.


        • Presumably, only senior staff will be working with these options
      • Customize
        • The tab should remain visible bu no publish or analyze commands should be select-able for a custom tab so their is no back channel to direct publishing.

“Move To” restrictions

Sitecore’s Move Validator may be leveraged to ensure that an item can only be moved (dragged or via Move To feature) or copied to a location where that content type is an applied insert option

Allow unlocking of items

Enable those with Publisher roles to unlock content locked by users of the same role or lower role. For instance, ClientName Publisher could unlock a piece of content from another publisher or an ClientName Author. This will reduce the number of requests to admins to unlock content since publishers will be able to do so themselves.

Auto-publish child & related objects

Ensure appropriate child and related objects are published for each content type, including assets in Media Library. Many sub-items may not be in workflow and may be freely published along with its parent. You will need to evaluate with your client which supporting items must be published along with specific content items and determine what is safe to auto-publish. This requires a careful mapping of eligible objects.

Publishing items to an external preview publishing target

Non-Sitecore stakeholders sometimes need to be able to see content or changes that are ready for approval so that they can help confirm acceptance. This might be necessary if they have approvers who are executives, subject matter experts, nontechnical personnel – people whose approval is vital but for a variety of reasons, we cannot or should not require that they interface with Sitecore via a login. A separate publishing target may be required to satisfy this requirement.

See Sitecore’s tips regarding publishing items to a preview publishing target.

Explicitly display publishing status

It’s possible to make it clearer what the publishing status of an item is so content authors don’t have to switch to the ‘web’ database and browse to the item to see if an item is published to that database in Sitecore. A custom panel in the ribbon or gutter space may show the ‘Status’ of an item in terms of what database it’s published to and in what languages. See these resources for more detail.

Versioning on local component data sources

A custom code fix for lack of versioning on local component data sources may be considered for implementations with heavy use of Experience Editor and local components since without this…

  1. Sitecore versioning of inline-editable pages is only half-enforced
    1. Publishing can push out saved changes to components
  2. Data sources cannot be rolled back to previous data
    1. V1 of the component data source just gets written over again and again.


In the end, it really just depends on what’s right for your team. Be honest in your assessment of requirements so that you configure only the roles and functions that are necessary. Create a solid foundation and add features only as a clear need arises. If you need assistance defining and implementing a Sitecore content author workflow, please reach out to me or Velir.

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

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)

  1. Provide access to non-explicit fields in Experience Editor
  2. Simplify rich text embeds
  3. Make it easy to do the “right” thing
  4. Optimize data template architecture for greater usability
  5. Dynamically nest local components with pages
  6. Use branch templates to create structured content models
  7. Get your content authors involved in the design process
  8. Be a custodian for chang(ing content)
  9. Embrace governance, add guard rails not gates
  10. Combine the authoring experience with analytics

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

Using Sitecore branch templates to create structured content models

Using Sitecore branch templates to create structured content models

Three of the guiding principles I always keep in mind when trying to build usable systems in Sitecore are:

  1. Reduce the number of decisions a content author has to make
  2. Reduce the number of things that require editing in the first place
  3. Make it easy to do the “right” thing

One of the greatest tools for ensuring that these three things are achieved are Sitecore branch templates. Branch templates allow creation of item hierarchies in a singled click using dynamic placeholders. You can instantly create complex but predictable multi-tiered structures so that an author need not recreate these manually.

A content author creating yet another news article need not see a blank slate each time when it’s likely that this content type is highly structured and will have instances of the same components in the same layout, at least as a starting point. Below are some examples of branch templates for pages that specifies a core collection of default components to be included with each new instance of the page.


This is even more useful for creating multi-tiered structures such as office microsites or any other repeated content grouping that all have the same basic hierarchy. Why have content authors doing data entry for content objects that are predictable and repeatable? This is time-consuming, prone to error, and discourages consistency. Companies tend to treat content authors time as expendable, but it’s really not when you consider the cumulative total of all of these tasks and micro-interactions with the CMS.

Leveraging branch templates requires a holistic approach to content modeling that is best done when a platform is being constructed as it requires some forethought and consensus on standardization. That said, it’s not impossible to inspect existing structures and create supporting branch templates for use moving forward. Finding ways to accelerate repetitive tasks may just improve content author morale as much as their efficiency and free them up to do higher value work!


Dynamically nesting local components with pages in Sitecore

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.

Simplify your rich text embeds in Sitecore

Simplify your rich text embeds in Sitecore

The challenge

One of the most common challenges of crafting quality solutions in Sitecore centers around the handling of media elements and other complex structures embedded in rich text. Many of my clients write a lot of highly curated, long form articles and reports with embedded pull quotes, images, galleries, videos, audio clips, data visualizations, and more. In most cases, they rely too heavily on rich text snippets to achieve the desired layouts and presentation which has some inherent drawbacks.

  1. A rich text snippet is a really just structured blob of HTML jammed into the rich text editor as opposed to being a discreet component that exists as part of the platform. They are really brittle. If a content author is trying modify one and accidentally chops out a class it’s difficult to fix it without starting over. It can be time-consuming.
  2. It’s not possible to edit them inline in Experience Editor.
  3. If content authors want to change all instances of this snippet in some way they would have to update it in X number of places
  4. The snippet contains styling markup so if and when content needs to be migrated the styles may not play nicely with the CSS of the destination site and may need to be manually retooled page-by-page.

The solution

There is better way. Working with media in rich text can be less clunky and time-consuming through use of dynamic placeholder-driven embeds. It is possible to use discreet, page-editable rich text embeds for all common components that can be included independently anywhere in the text block.

If your solution has commonly used media components such as Image or Video, there is no need to create a rich text snippet that mimics this functionality. Alternatively, allow these components to be embedded within the rich text block. Instead of placing a token with the GUID of the component, Velir has been working on a method that allows the content author to drop a dynamic placeholder into which you can add components as you would any other placeholder. Below is an example of the a customized RTE ribbon that includes 3 new options – Embed Container Float Left, Embed Container Full Width, and Embed Container Float Right.


The content author places the cursor between two paragraphs of text and then chooses an option in the ribbon. They can choose to float the asset left or right or allow it to span the width of the content well. A dynamic placeholder for embeds is dropped into the text block and components can be added as defined by the container. This means media embeds are discreet entities and can be added and fully managed from Experience Editor.


Once saved, the embedded components will be visible in Experience Editor and Preview. Below is an example of an embedded image component floated left and a video component floated right. Front end styling will determine the allowable width of floated embeds and whether they “bust” out of margins as they do in this example.

Embedded assets

Below is an example of an embedded pull quote component floated right and an image component at full width. Text like captions can be fully edited inline.


Disclaimer: We are still tooling with this method and need to work out some kinks around reordering embedded assets once set… but so far so good. If, like us, you’d like to find a cleaner, more structured way to manage rich text embeds then I recommend giving this a try.