Send Sitecore workflows notifications to users based on Sitecore roles

By
In many Sitecore solutions, there are different areas, where different editors and publishers maintains content in their respective areas. Sometimes these areas overlap.

In this blog post I will give an example of how to send workflow notifications to the different publishers and editors without being restricted to where in the structure the item is created/edited.

Creating a connection to roles and the Sitecore item

I created a droplink field on the Sitecore items which use workflows so we can connect this item to the corresponding roles.
The droplink is populated based on a data folder with items that has the Roles specified.

In this example, I have a Publisher Role and an Editor Role, where access rights to workflow commands and other Sitecore roles has been added.
The owner roles (owner publisher and owner editor) will inherit from these roles. the owner roles are primarily used to control which users should get notifications in this example, I also use, the owner set on the item to control access rights programmatically but I won't cover this in this blog post.

Since the publishers and editors will be given different roles we can on item creation set this droplink field programmatically based on their role:

Creating worflow notification on Submit

On the submit command I created an action NotifyOnSubmit, here I send an email to all the publishers who has the corresponding role as the owner of the item. I could have used the current role of the logged in user, but this was not always the correct action when I created this logic. for another solution that would probably be a better approach

Creating worflow notification on approve

On the awaiting approval command I created an action NotifyOnApprove action. Here we send an email to all the publishers and super administrators in the solution

Creating workflow notification on Reject

On the awaiting approval command I created an action NotifyReject action, Here we collect the last workflow history to get the correct email we should send the reject notification to

Setting the owner field as required

For all templates which have the workflow added, it is required to have the owner set on the Sitecore item for workflow notifications to be sent to the correct users. this is partially covered by setting the owner on item creation, however super admins and developers could be creating content items without these roles. I have set the owner droplink to be required so we do not end up with items with missing owners.

Recommended links to send to the publishers

 /sitecore/shell/Applications/Content Editor.aspx?fo= + contentItem.ID
 /?sc_mode=edit&sc_itemid=" + contentItem.ID

Comments

Post a Comment

Popular posts from this blog

Step by step guide to add Glass Mapper to Helix solution

By
Image
How to add Glass Mapper to Sitecore Helix solution There are probably different ways to set this up in a Helix solution. I have done this setup in 4 of our projects, and it has become the "template" for our new Helix solutions. We create one foundation project, which has all the glass nuget packages installed, we also choose to add a glass base in the foundation layer. All new features will have access to this glass base interface through a project reference.  I have had a lot of discussions with my co workers on where to add common fields that would be used in several feature projects. If it should be in the Glass Mapper foundation project or in a new foundation project. On "small" projects we choose to add it in the Glass Mapper foundation project, on larger projects we created a separate foundation project to add these fields and their interfaces with Glass Mapper mapping. 1. Create the Visual studio project From the Package Manager Console run
Read more

Using interfaces with Glass Mapper

By
Image
In one of my previous blog post I wrote an example on how to add Glass Mapper to Helix . I will in this blog post provide some code examples on how to map different fields with Glass Mapper. I will also provide some examples on how you could benefit more from Glass Mapper by using interfaces instead of models. Why use interfaces instead of models Interfaces can be inherited multiple times, this works well with inherited templates in Sitecore. We create the common fields in the Helix Foundation layer, and use the mappings in multiple feature projects. The mapping is created in separate interfaces. The model(interface) that should use the fields only needs to inherit from these interfaces. For example a simple component with Title and Rich Text would only need to inherit from the GlassBase, Title and Rich Text interface IMyComponent   :   IGlassBase ,   ITitle ,   IRichText Inside Sitecore the MyComponent would need the Title and RichText field The view then has access
Read more

Adding dynamic image source for multi-site solutions with $site$ token and setting dynamic datasource location for components

By
Image
Months after finishing a project I have had clients saying: We need to make a copy of the site you created and put some other content on it Most clients need to put this new site into the same solution because of restrictions in their Sitecore license. To convert old projects there was usually a lot of content restructuring and code changes needed. I have done this exercise multiple times. I try to have this in mind when creating new solutions so we don`t end up with too much effort when adding support for multi sites at a later stage. Even with great structure and code we still face some problems. In a multi-site solution you want to reuse components, but the sites should not always share the data locations and image folders. Most sites have different editors, they should not see the components and images from the other sites, we then need to place content in different folders and set the appropriate security on those. I recently got a request to duplicate an existing site,
Read more