Over time, our team has realized that when we are speaking to a client about publishing in Sitecore, we may not all be talking about the same thing. There really are three “publish” contexts that a client may be referring to: workflow approval, web database publishing, and content delivery cache clearing. Trying to make this clear to a client isn’t always easy.

But it can be!

Setting the stage

The first step that can be taken is to make sure the user understands what the different steps of publishing are so that they understand what is going on with the system. This makes it easier to set expectations around timing of content appearing on the website.

Step #1: Workflow approval

This is the first time a client actually thinks they are publishing. An item is going through workflow and the approver at the end of the flow approves the content to transition it to the final stage. On the final step, whether a publishing agent is being used for scheduled publishing, or a publish action, the user that just approved the content thinks that they have published the content. This means they expect to see their content show up on the website soon.

Step #2: Web database publishing

When Sitecore begins pushing approved content to the Web database, this is the first time that content may begin to show for the end users. This may be triggered with a site publish, scheduled publish agent, workflow publish action, or a manual single item publish. If content is not in the Web database, it will never show to an end user.

This is where there is often a delay from when the approver expects content to display and when it actually does. Even though the content is approved, it may not be in the web database yet.

Step #3: Content Delivery cache clearing

Having approved content in the Web database is not enough, especially with scaled environments that have the Content Delivery servers separated from the Content Authoring server. Even though the authoring server has done all of its work, if the cache doesn’t clear on the delivery server the content won’t display to end users.

This piece completely depends on the event queue being processed correctly.  The event queue monitor should be checking every 2 seconds for events to process, and this should allow for the various caches to get updated when a publish occurs. Any time spent waiting and processing the events for the cache clear will cause another delay between when the approver expects content to display and when it actually does.

Helping set expectations

One of the ways that you can help an author understand this is to make sure the approval workflow has solid naming conventions in place for the actions and steps in the workflow.

Let us take the example of the standard workflow shipped with Sitecore. The stages are as follows:

1. Draft
2. Awaiting Approval
3. Approved

During the Awaiting Approval stage, the default name for the approval action is Approve. There is no mention of publishing, but there is also no mention that it won’t publish. In fact, the default workflow has an Auto Publish action on it, so the intention of the flow is that the state Approved should be synonymous with Published.

We know this is not the case, so how do we help?

One way is to change the name of the final state. Ready to Publish or Publishable both immediately indicate to the user that if an item is in that state, it may not necessarily be published yet.

Another way is to change the name of the action that pushes items to the final state. Queue for publish or Add to publish queue are both clear in the intent, if a little long-winded.

This also needs to be a discussion with the client. Once you’ve explained how publishing actually works, what vocabulary would work for them? What will remind their authors that hitting that button does not mean “on the content delivery site immediately”?

Once you both agree to a vocabulary set, make sure to get these into your acceptance criteria for your workflow implementation!