By default, Sitefinity CMS enables you to define workflows per different sites, languages, types of content, and pages. With pages you can go as granular as specifying a different workflow for all pages under a parent page, or even have separate workflows defined for individual pages. Such level of granularity satisfies the requirements for most business cases.
Additionally, the Sitefinity CMS Workflow API provides great flexibility for customizing the workflow behavior even further. For example, you can implement your own logic to load different workflows, based on custom conditions. This tutorial demonstrates how you can extend Sitefinity CMS Workflow functionality to load different workflows based on the user’s role.
The WorkflowDefinitionResolver class is responsible for loading the different workflows you have defined for your content based on the corresponding conditions. It provides an extensibility point where you can plug your own logic for conditionally loading workflows, and even dynamically load workflows that have not been defined in the system yet. The class exposes two useful virtual methods that you can override – ResolveWorkflowExecutionDefinition and GetWorkflowExecutionDefinition.
ResolveWorkflowExecutionDefinition is responsible for determining which is the most appropriate workflow definition to be used for an item. You can override this method to specify the custom logic that instructs Sitefinity CMS which workflow to load based on the current context of the user. For example, this is where you can tell Sitefinity CMS to load a desired workflow based on the content type and user role.
GetWorkflowExecutionDefinition returns a workflow definition from cache (or database if a cached version does not exist) for a given workflow definition Id. When Sitefinity CMS calls this method, the logic for determining which workflow to load has already executed, and GetWorkflowExecutionDefinition is responsible for delivering the workflow definition. By overriding this method, you can alter the default behavior and return a desired workflow definition. For example, if you have dynamically created a workflow definition, which is not persisted in the database (let’s say your logic is to have different workflow for each role – there really is no need to persist them in the database and complicate editing the rest of the workflows, when you can only load them dynamically), by overriding GetWorkflowExecutionDefinition you can return that definition safely.
Both methods return objects of type WorkflowDefinitionProxy – a wrapper for IWorkflowExecutionDefinition, which hold the parameters necessary for the workflow to execute.
To load different workflow based on the user role you must start by creating a custom definition resolver that inherits from the WorkflowDefinitionResolver class. For more information about creating workflow definitions see: Create workflow definitions.
In the class default constructor, you can create your custom workflow definitions. Any workflow definition you create in the construction will be instantiated when you start your Sitefinity CMS website and will live in the application memory.
Next, we want to have the following behavior in place:
To achieve the above described behavior, you must override the ResolveWorkflowExecutionDefinition method and implement your custom logic that matches the desired behavior. In the overridden ResolveWorkflowExecutionDefinition you can use the Sitefinity CMS Security API to get the current user via ClaimsManager.GetCurrentIdentity and check whether the user belongs to any of the desired roles.
The following sample demonstrates the full implementation of the above scenario:
Finally, to instruct Sitefinity CMS to use your custom WorkflowDefinitionResolver instead fo the default one, you need to register it in the ObjectFactory container in Global.asax:
Back To Top
To submit feedback, please update your cookie settings and allow the usage of Functional cookies.
Your feedback about this content is important
Copyright © 2022 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.
Powered by Progress Sitefinity