Default workflow

Workflow is tightly integrated into the Sitefinity publishing process. Although you cannot see it in the user interface, even if you don’t define a workflow, Sitefinity uses a default definition. This definition moves an item between several default states: draft, published, scheduled and unpublished. These default states are applied for items in all built-in content modules, unless you have defined another type of workflow. Although very similar, the default workflow should not be confused with content lifecycle.

Comparing content lifecycle and default workflow

Unlike the lifecycle, with workflow an item can be in only one state. When switching the workflow state, this actually changes the item, rather than creating a new row in the database. There are no new rows in the database, only new values in the existing rows for each item. Here is the meaning of default workflow states:

The diagram above shows how an item can move between the different states of the default workflow. Circles represent states, arrows represent actions that can be performed with content items. Those actions can be performed both from the Sitefinity user interface, as well as the API.

A rule you can follow when dealing with lifecycle and workflow is that the workflow state of an item is always applied to the Master version in the lifecycle. This means that workflow does not have any meaning for Temp and Live versions.

• Temp versions are temporary, so their workflow state is always the one of the version they were copied from.
• Live versions always have a workflow state of Published.
• All workflow states are applied to the master version of an item.

To see how each action affects an item, we can observe the state of the database and the user interface of Sitefinity, similar to how we did with the content lifecycle.

1. Create a news item
   As with the lifecycle, just clicking the Create button doesn’t persist anything into the database. The item is still only in memory and the table is empty.
    
   
   To do the same using the API, you don't need to call the workflow at all. Just create an item the way you normally would.
   
   var manager = NewsManager.GetManager();

   var newsItem1 = manager.CreateNewsItem();
2. Save the item as draft
   Once we save the item as draft, a Master version is persisted in the database. Its workflow state is Draft, as can be seen in the last column
    
   Saving a draft of an item through the API is also done without specific workflow calls. Since this is the default workflow state of an item, it is automatically set.
   
   newsItem1.Title = "News Item 1";

   newsItem1.UrlName = "newsitem1";

   newsItem1.Content = "Some content";

   manager.SaveChanges();
3. Publish the news item
   

   Publishing the item creates a Live version in the lifecycle, and sets the workflow state of both Live and Master versions to Published.
    
   When publishing the item through code, it's not enough to call the Publish method for the lifecycle - that would only create a live lifecycle version. To instruct the workflow that it should also change the state of the item to "Published", we need to call WorkflowManager.MessageWorkflow(). 

   manager.Lifecycle.Publish(item);

   manager.SaveChanges();

    

   WorkflowManager.MessageWorkflow(item.Id, typeof(NewsItem), null, "Publish", false, new Dictionary<string, string>());
4. Edit the item again
   If we edit the item for a second time, while it is being edited, there is also a Temp version in the database. The workflow state of all lifecycle versions is Published. Only the Live version (before the changes we’ve made) is visible on the frontend.
    
   Checkit out the item and making the changes is a matter of calling the lifecycle methods. The difference comes when we actually want to persist the changes. Except the call to CheckIn(), we also need to go through the workflow once more. If we don't, the item's state will be "newer than published", but our changes won't be live yet. So we message the workflow telling it to publish the item.
   
   var manager = NewsManager.GetManager();

   var item = manager.GetNewsItems().Where(n => n.Title == "News item 1" && n.Status == Telerik.Sitefinity.GenericContent.Model.ContentLifecycleStatus.Master).SingleOrDefault();

   var temp = manager.Lifecycle.CheckOut(item) as NewsItem;

   temp.Content = "edited item";

   manager.CheckIn(temp);

   manager.SaveChanges();

    

   WorkflowManager.MessageWorkflow(item.Id, typeof(NewsItem), null, "Publish", false, new Dictionary<string, string>());
5. Schedule the news item
   Once we are happy with our changes, we decide to schedule the item to be published on a date in the future. This removes the Temp version from the database and sets the workflow state of the Master version to Scheduled. Note that the Live version still has a workflow state of Published and is visible in the frontend.
    
   Scheduling an item through the API is done the same way as publishing - calling the workflow. The difference here is that we use "Schedule" for the paremeter specifying the operation name.
   
   item = manager.Lifecycle.CheckOut(item) as NewsItem;

   manager.SaveChanges();

    

   var bag = new Dictionary<string, string>();

   bag["ContentType"] = typeof(NewsItem).FullName;

   WorkflowManager.MessageWorkflow(item.Id, typeof(NewsItem), "", "Schedule", true, bag);
6. Publish the news item again
   Publishing the scheduled item changes the workflow state of the Master version to Published and makes the item immediately visible in the frontend
    
   The code for publising the item is the same as in Step 3
   
   manager.Lifecycle.Publish(item);

   manager.SaveChanges();

     

   WorkflowManager.MessageWorkflow(item.Id, typeof(NewsItem), null, "Publish", false, new Dictionary<string, string>());

This completes the sequence of steps through which we've moved a news item. Remember that while content lifecycle keeps several versions of an item, the default workflow operates on the master version by changing its status property. Knowing the difference between the two is important, and will become more evident when working with non-default workflow. We will discuss advanced workflow scenarios in the next topics of this section.