Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Documentation on how to work with Umbraco Workflow in just a few steps
Umbraco Workflow allows the creation of multi-stage approval workflows when writing and publishing content. Umbraco Workflow extends Umbraco's out-of-the-box publishing model with multi-stage and configurable approval workflows. A workflow process comprises multiple steps and multiple users assigned to the group responsible for providing approval at each step.
Learn more or purchase Umbraco Workflow to get all the features and support.
In this article, we will cover the steps required to install Umbraco Workflow on your website.
There are different ways to install Umbraco Workflow:
To install the Umbraco Workflow package (Umbraco.Workflow), follow these steps:
Run the following command to add a package reference to your Umbraco project:
Restart the web application using the following command:
To install via Visual Studio, follow these steps:
Open your project in Visual Studio.
Go to Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution....
Browse for Umbraco.Workflow.
Once the package is installed, open the .csproj file to make sure the package reference is added:
Once the installation is completed, you will see the following in the Umbraco Backoffice:
The Active Workflows view in the Workflow section provides an administrator view of the active Workflows. It displays a table containing the following details:
Page name/Node with the Language variant.
Type of Publish.
Date the workflow was requested on.
Comment describing the changes.
You can also Filter the records based on the Node, Requested by, Created date, Completed date, Page Language, Workflow Type, and Workflow Status.
Additionally, you can adjust the total number of records displayed on a page.
The Detail button at the end of the record displays an overlay with content similar to the sub-section.
Umbraco Workflow is backwards compatible with Plumber data. However, with a new default namespace constituting a major breaking change any existing customization or extension needs to be updated.
To migrate from an Umbraco installation with an existing Plumber installation to Umbraco Workflow, follow these steps:
Uninstall Plumber and remove the /App_Plugins/Plumber folder.
Upgrade your project to Umbraco 11.
The Workflow section provides an administrator view Workflow Dashboard. It displays a chart of recent workflow activity, chart of content review activity, licensing details, and any relevant upgrade-related messages. You can also view the workflow and content review activity chart for the specified range of days.
Umbraco Workflow has its default Dashboards. By default, when you install Umbraco Workflow, you receive two Dashboards: the User Dashboard and the Admin Dashboard. Additionally, Umbraco Workflow replaces the default Umbraco button set in the editor drawer.
Umbraco Workflow adds two Dashboards to your Umbraco project:
Admin Dashboard - This Workflow Dashboard is the default view in the Workflow section. It displays a chart of recent workflow activity, chart of content review activity, licensing details, and any relevant upgrade-related messages. You can also view the workflow and content review activity chart for the specified range of days.
When a workflow is active on the current node, the Publish button is replaced, linking to the workflow content app.
When no workflow is active, the button state is determined by the current user's permissions.
Umbraco Workflow overrides Umbraco's User/Group publishing permissions. If the user has permission to update the node, they will be able to initiate a workflow process on that node. Umbraco Workflow shifts Umbraco from a centrally administered publishing model (controlled by a site administrator) to a distributed model. In this model, editors publish content based on their responsibilities assigned during the workflows.
In cases, where the content is already in a workflow, a notification is displayed at the top of the editor. Depending on the Workflow Settings, you can enable/disable editing access on a content node in a workflow.
For nodes where the workflow has been disabled, the default Umbraco options are displayed.
Umbraco 10 and above Documentation
Version 13 of Umbraco Workflow has a minimum dependency on Umbraco CMS core of 13.0.0. It runs on .NET 8.
Version 13 is primarily a dependency update, but does remove some properties previously marked obsolete. These are not typical extension or integration points, and are listed below for reference.
Removed the Type property from ConfigModel
Removed the Type property from UserGroupPermissionsPoco
Removed the ScheduledDate property from HtmlEmailModel. ReleaseDate or ExpireDate properties should be used instead.
Removed the ScheduledDate property from InstanceDetailViewModel. ReleaseDate or ExpireDate properties should be used instead.
Removed the ScheduledDate property from WorkflowInstanceViewModel. ReleaseDate or ExpireDate properties should be used instead.
Removed the ScheduledDate property from WorkflowTaskViewModel. ReleaseDate or ExpireDate properties should be used instead.
Removed the SetDueDate() method from ContentReviewConfigPoco. The implementation accepting the ContentSettingsReviewModel parameter should be used instead.
You can find the version specific upgrade notes for versions out of support in the Legacy documentation on GitHub.
Umbraco Workflow is available in free and licensed versions. While the licensed version includes all features and no restrictions, the free version has some limitations.
In the free version, the following features are disabled:
Document Type workflow configuration
Document Type content review configuration
History cleanup and related configuration
Approval thresholds and related configuration
Content comparison
Exclude nodes
Offline workflow approvals
In the free version, a maximum of five approval groups can be created.
Once you've purchased your license, you are ready to configure the license key on your Umbraco installation.
The license key should be added to your configuration using product ID: Umbraco.Workflow.
For detailed instructions on how to install and configure your license, including version-specific examples and additional configuration options, see the Configure Licenses article.
The trial license introduces some restrictions around advanced features but is otherwise a full-featured workflow platform. The paid license is valid for one top-level domain and all its subdomains.
To impersonate the full license on a local site, set EnableTestLicense to true in the appSettings.json file:
{
"Umbraco": {
"Workflow": {
"EnableTestLicense": true
}
}
}Click Install.
Install Umbraco Workflow 11. See the Installing Umbraco Workflow article.
Build the application.
Uninstall Plumber and remove the /App_Plugins/Plumber folder.
Upgrade your project to Umbraco 11.
Make a copy of the Value column from the WorkflowSettings table.
Delete the WorkflowSettings table.
Update WorkflowTaskInstance table to allow null values in the GroupId column.
Install Umbraco Workflow 11. See the article.
Build the application.
Update the WorkflowSettings table to restore the previous data to the Value column.
To get the latest version of Umbraco Workflow, you can upgrade using either of the two options:
NuGet installs the latest version of the package when you use the dotnet add package Umbraco.Workflow command unless you specify a package version:
dotnet add package Umbraco.Workflow --version <VERSION>
Run dotnet restore to install the package.
Go to Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution... in Visual Studio, to upgrade Umbraco Workflow:
Select Umbraco.Workflow.
Select the latest version from the Version drop-down and click Install.
Open the .csproj file to make sure the package reference is updated:
Installing Umbraco Workflow
Install Umbraco Workflow in a few steps
Content Approval Workflows for Umbraco
Allows you to design the approval process to fit your organization
Workflow Section Overview
Approving, rejecting, content reviews, and scheduling workflows are natural additions to the existing toolbox.
The Umbraco Workflow History provides a chronological audit trail of workflow activity for all the nodes.
It displays a table containing the following details:
Page name/Node with the Language variant.
Type of Publish.
Editor/Original author requesting the workflow.
Date the workflow was requested on.
Comment describing the changes.
Status of the workflow.
You can also Filter the records based on the Node, Requested by, Created date, Completed date, Page Language, Workflow Type, and Workflow Status.
Additionally, you can adjust the total number of records displayed on a page.
The Detail button at the end of the record displays an overlay with content similar to the sub-section.
Advanced Search further expands Workflow's functionality outside its original content-approval focus, adding a new dashboard for performing deep searches of your website content.
The Advanced Search dashboard is added in the content section for all users.
Advanced Search allows searching any number of content types, optionally filtered to a subset of variants. The search can be performed across all indexed fields, a subset of fields, or all fields using a particular Data Type or Property Editor.
Searches can optionally be made fuzzy, using Lucene's default similarity measurement algorithm.
The search types are described below.
All properties: search for a single value across all indexed fields for the selected content types.
Some properties: search the selected properties. A different search term can be provided for each selected property.
Single property: search for a single value in the selected property.
Searches can be further refined by restricting results to particular editors, or created and updated date ranges.
The additional fields are all optional.
Results are displayed in a familiar format, linking to nodes in an infinite editors, which allows users to retain their search results.
Search results include published, unpublished and trashed content, and are filtered according to the current user's content start node(s).
Learn how to submit content changes for Workflow approval
When requesting workflow approval for content changes, editors must provide additional information detailing the change.
To submit the content changes, click the Request publish button in the editor footer.
The button opens the request approval overlay:
Depending on the Document Type and Workflow settings, the overlay will provide inputs for:
dotnet add package Umbraco.Workflowdotnet run<ItemGroup>
<PackageReference Include="Umbraco.Workflow" Version="13.0.0" />
</ItemGroup>Property Editor: search for a single value in all fields where the indexed property uses the selected Property Editor (for example, all types using the Umbraco.TextBox editor).
<ItemGroup>
<PackageReference Include="Umbraco.Workflow" Version="13.x.x" />
</ItemGroup>A field for adding comments to describe the changes made to the content.
Always visible.
Action
Allows to choose the workflow type - either Publish or Unpublish.
Visible only when Use Workflow for unpublish is set to true. To enable this setting, go to Workflow > Settings > Use Workflow for unpublish.
Attachment
Upload media or files attachment.
Visible only when Allow attachments is set to true.
Publish on
A date picker for scheduling the content's publishing date.
Editable only when Allow scheduling is set to true and the workflow type is Publish. It is not possible to schedule a Publish on date in an Unpublish workflow.
Unpublish on
A date picker for scheduling the content's unpublishing date.
Visible only when Allow scheduling is set to true.
Variants
Allows selection of language variants to publish.
Visible only for variant content.
It is possible to schedule both Publish on and Unpublish on dates in a Publish workflow. Once content has been unpublished, a new workflow process is required to republish the content.
If the document varies by culture, the editor must select one or more variants to submit for approval.
When a document is invariant, the variants selector is not displayed, and the approval flow follows the default permissions inheritance pattern.
The editor will not be able to select variants where:
They do not have permission to edit the language, or
The variant is already in a workflow.
When submitting multiple variants, a workflow process is started for each variant, using the default permissions inheritance pattern. Newly created variants are automatically assigned the configuration from the default language.
Alternatively, all variants can be submitted in an invariant workflow, where they will be approved in a single workflow process. Invariant workflows use the permissions set on the default language. Editors must have permission to edit all the current node's variants to be able to initiate an invariant workflow.
The invariant workflow will publish all variants, regardless of their node state, that are not already in workflows. This means that previously unpublished variants will be republished when using invariant workflows. In most cases, it is preferable to select the individual variants.
When submitting for approval, Workflow will automatically save variants with pending changes.
Validation errors are reported in the UI using Umbraco's validation messages.
Describe the changes
To install the Umbraco Workflow DataGenerator package (Umbraco.Workflow.DataGenerator), follow these steps:
Update appSettings.development.json to enable the Workflow test license. This removes limits on group creation, and enables all features:
Run the following command to add the required package references to your Umbraco project:
Restart the web application using the following command:
When the application restarts, it will automatically install The Starter Kit.
The package adds an additional view in the Workflow settings, which provides controls for the data generation task.
The available settings are explained below.
Number of approval groups - determines how many Workflow approval groups will be created. Defaults to two.
Number of users - determines how many Umbraco users will be created. Defaults to two.
Number of groups per workflow - determines how the created groups are allocated into the generated workflows. Defaults to 0, which allocates a random number of groups to each workflow.
Number of users per group - determines how the created users are allocated into the generated workflow approval groups. Defaults to 0, which allocates a random number of users to each approval group.
When the generator task completes, you will be prompted to take a Workflow tour. The tours can be resumed at any time from the Data generation view.
Groups and users are created with arbitrary names, feel free to rename these to suit.
Once Workflow configuration has been updated, the environment must be reset before regenerating. Resetting cancels all active workflows and deletes all workflow configuration. Umbraco users are not deleted, but will be reused in future data generation actions.
Use thresholds to configure how many approvals a workflow in Umbraco Workflow requires to be considered complete.
Umbraco Workflow's default behavior requires one member of an approval group to approve a pending task to advance it through the workflow.
The approval thresholds feature introduces configuration options to set the required number of approvals for a given workflow stage.
The threshold options are:
The workflow detail UI displays the following:
The status of the current task.
Approval status for members of the current group.
Progress towards meeting the threshold for the current approval stage.
Future tasks and the assigned group and its users.
Approving a task as an administrator immediately satisfies the approval threshold for the task, and will advance to the next workflow stage.
When a task is rejected in a workflow stage where the approval threshold is Most or All, existing approvals can be managed via configuration:
Existing approvals can be reset, resetting progress toward the approval threshold. In this case, all users in the approval group will be able to approve the resubmitted content.
Existing approvals can be kept. In this case, users in the approval group who have already approved the task will not be able to approve the resubmitted content.
Approval thresholds are managed via settings in the Workflow section or in the appsettings.json file. Node-specific thresholds are set directly on the workflow configuration in the Workflow content app.
The settings below can be set from the Backoffice or via settings customization in the appsettings.json file (refer to for implementation instructions).
The approval threshold for an individual workflow stage can be set using the control below the stage name. Setting the stage threshold requires the Configuring approval threshold setting to be true.
{
...
"Umbraco": {
"Workflow": {
"EnableTestLicense": true
}
}
}dotnet add package Umbraco.Workflow // if not already installed
dotnet add package Umbraco.Workflow.DataGeneratordotnet run
One (default)
Pending tasks require approval from any member of the assigned approval group.
Most
Pending tasks require approval from an absolute majority of group members. Example: A group with 3 members requires 2 approvals and a group with 4 members requires 3 approvals.
All
Pending tasks require approval from all group members.
Approval threshold
0 (One)
Sets the global approval threshold.
Rejection resets approvals
false
When true, and the approval threshold is Most or All, rejecting a task resets the previous approvals for the workflow stage.
Configure approval threshold
false
When true, enables setting the approval threshold for any stage of a workflow (on a content node or Document Type).
Umbraco Workflow adds a Content App to all content nodes in the Content section where a workflow is enabled. The Workflow content app includes three sub-sections:
The Active workflow sub-section provides an interface for managing workflows for the current content node.
When the current node is pending workflow approval, the Active workflow sub-section displays detailed information such as:
Option to .
View change description and track differences across pending and completed workflows.
View the group responsible for approving the pending workflow.
View pending language variant(s) workflow.
You can access Active Workflows from two places - the Content section and the Workflow section (depending on your user permission). Workflow Administrators (those users with access to the Workflow section) can access workflows assigned to a different group. In the Workflow History, these are noted as being performed by the admin.
To approve a Workflow task, click on the Approve button in the Action section.
To reject a Workflow task, click on the Reject button in the Action section. Depending on the approval stage, the reviewer can decide where to send the rejected task.
For first-stage approvals, the rejected task is sent back to the original editor/author. For second-stage approvals and above, the reviewer can send the rejected task either to the original editor or any other previous workflow group.
To cancel a pending Workflow task, click on the Cancel button in the Action section.
The Configuration sub-section provides an interface for configuring the content approval flow for the current node. It also displays any Inherited or Document type approval flows applied to the current content node.
In multi-lingual sites, each variant can have its own approval flow. By default, new variants inherit the configuration set on the default language.
For example, German variants can be approved by the German speakers group, while English variants are approved by the English speakers group.
You can add different groups for different stages of content approval flow. Content Approval flow groups can be reordered via drag and drop. You can also apply the approval flow either for publish and unpublish workflows or only publish workflow.
Approval Flows are available in three types: Content approval flow, Inherited approval flow, and Document type approval flow.
A given content node may have all three approval flow types applied but only one will be applied as per the following order of priority:
Review the current responsibilities for Approval Groups in the Roles tab of the Approval Groups section for Node-based approvals and Document type approvals only. For more information see the section in the article.
Document type approval flows may contain conditional stages, such as including Translators in the workflow only when the Description property has changed. For more information on settings conditions in Document type approval flows, see the section in the article.
Configuration cannot be modified when a content node is in a workflow process.
Content reviews is a tool that allows content editors to keep their content up-to-date. For more information, see the section.
The History sub-section provides a chronological audit trail of workflow activity for the current node. It displays a table containing the following information:
Type of Publish
Who the workflow is requested by
The date the workflow was requested
Comments
You can also Filter the records based on the information listed above. Additionally, you can adjust the total number of records displayed on a page.
The Detail button at the end of the record displays an overlay with content similar to the Active workflow sub-section.
The Approval groups view in the Workflow section lists the active groups name, group members, their permissions, and a quick link to email the group.
To add an approval group, follow these steps:
Go to the Workflow section.
Click on Approval groups.
View the workflow activity (eg. pending approval/task approvals/rejects) for the current workflow process.
Status of the workflow
Content approval flow
Set directly on a content node via the Configuration section in the Workflow tab.
Highest
Document type approval flow
Set in the Settings section. Applies to all content nodes of the selected Document Type unless overridden by a Content approval flow set directly on the node. Requires a license.
Secondary
Inherited approval flow
Used when a content node has no Content approval flow set, nor a flow applied to its Document Type. Umbraco Workflow will traverse the content tree upwards to find a Content approval flow.
Lowest
Click Create Group.
Enter a Name for the Approval Group. For example: Danish Editors.
Enter a Description to remind you why the group exists.
Enter the group's Email address in the Settings section to which the notifications will be sent.
Select the Language from the drop-down list.
Enable offline approval to allow users in this group to approve changes without logging in to the backoffice.
Click Save Group.
You can search for a specific group using the Search bar. Select a group from the list to edit its Settings, Roles, Members, and view the group's History.
The Settings tab consists of the following fields:
Group Email: Workflow notifications are sent to a generic inbox (a group's email address) rather than the individual group members.
Language: Select a language variant for the email.
Enable Offline approval: Allow the users of this group to approve changes without logging in to the Backoffice. For more information, see the Enable Offline approval section. This feature requires a paid license.
You can optionally provide Groups permission to action workflow tasks without logging in to Umbraco. This feature requires a paid license. By enabling Offline Approval, all email notifications sent to the group members will include a personalized link to a preview page.
The preview page exposes the current saved page with the options to approve or reject the change. It is not possible to edit the content from the offline approval view.
This feature is useful where the approval group membership is a single user who does not use Umbraco. For example, a manager may want to approve media releases before publishing but does not otherwise need access to Umbraco.
Offline approval requires a user to exist in the Backoffice and be assigned to a workflow group. They do not need to know how to use Umbraco or even know their login credentials.
The Roles tab provides an overview of the current workflow roles for the Group:
Node-based approvals: This workflow applies only to the specified node.
Document-type approvals: This workflow applies to all the nodes of a given Document Type.
You can set these Roles in the Workflow Settings section. For more information, see the Workflow Settings article.
The Members tab manages the membership for the given user group. Add members to approval groups to determine which member will be responsible for approving content changes. Group Members can be explicitly added to the group or can inherit group membership from an existing Umbraco group. Ideally, group members are set explicitly to ensure changes made to Umbraco groups do not cause unexpected changes to workflow permissions.
To add a Group member, follow these steps:
Go to the Workflow section.
Click on Approval groups.
Select a group from the list to edit its Members.
Go to the Members tab.
Click Add in the Group members section.
Select the Users you want to add to the approval group.
Click Save Group.
To remove a Group member, click Remove.
To inherit an existing Umbraco group membership, follow these steps:
Go to the Workflow section.
Click on Approval groups.
Select a group from the list to edit its Members.
Go to the Members tab.
Click Add in the Inherited group membership section.
Select the User groups you want to add to the approval group.
Click Save Group.
To remove a Group membership, click Remove.
The History tab provides an overview of the workflow activity for the current group. It displays a table containing the following details:
Page name with the Language variant
Type of workflow roles (Node-based approvals or Document type approvals)
Workflow requested by
Date the workflow was requested on
Comment describing the changes
Status of the workflow
You can also Filter the records based on the Node, Requested by, Created date, Completed date, Page Language, Workflow Type, and Workflow Status. Additionally, you can adjust the total number of records displayed on a page.
The Detail button at the end of the record displays an overlay with content similar to the Active workflow sub-section.
Every new workflow stores multiple records in the database - one for the workflow instance and one for each task in the workflow. In a multi-lingual site, depending on how you use Workflow, there may also be records generated for each culture variation. These records are used to build the workflow history views in the Umbraco backoffice.
Depending on your requirements, this information may not be required or may only be useful for a short period of time.
Umbraco Workflow 11.1.0 introduces a history cleanup feature similar to those already available in Umbraco CMS and Umbraco Forms.
The History Cleanup feature is disabled by default. Applying the default history cleanup policy will:
Delete history older than 28 days. See the KeepHistoryForDays setting.
Only delete history where the workflow status is Approved, Cancelled, CancelledByThirdParty, or Errored. See the StatusesToDelete setting.
The feature can be enabled in the appSettings.json:
For sites with stricter or more complex requirements, it is possible to override the global settings for individual content nodes and Document Types. This is also managed through appSettings.json configuration. Configuration rules defined in application settings are prioritized over any rules set via the backoffice. It allows the developers to restrict clean up of critical history, while allowing site administrators flexibility to manage non-critical history.
The below example will apply the following policies:
History cleanup is enabled globally.
History items with Approved or Cancelled status are deleted after 90 days.
Workflow history for node dcf18a51-6919-4cf8-89d1-36b94ce4d963 will never be deleted.
When calculating node and Document Type policies, the Document Type rules will not be processed if the current workflow instance matches a node rule. Using the above configuration as an example, consider both nodes in the CleanupRules dictionary are using the Document Type ContentPage. In this case, the Document Type rules will not be applied as the node rules are prioritized.
If a value is omitted from the node or Document Type policy, the global value will be used instead. In the above example, the node policy for 31523089-f648-4883-9087-ef9a0b83129f uses the StatusesToDelete value from the global policy that is deleting Approved or Cancelled workflow history.
StatusesToDelete uses a dictionary built from the WorkflowStatus enum type. The default configuration is:
It is possible for a cleanup rule (or the global configuration) to declare a StatusesToDelete property without the full set of status keys. This will not modify the default values.
For example, adding "Approved": false will remove Approved from the deletable statuses, but all other default values will remain. Therefore, to delete approved workflows only, the configuration would look like below, where the default values have been negated:
Backoffice users with access to the Workflow section will have permission to modify history cleanup rules, while all backoffice users have read-only access.
Rules for content items and their Document Type are set from the History tab of the Workflow content app. The History view in the Workflow section provides a read-only overview of all the history cleanup rules and global configuration.
Content items with no custom cleanup rules defined will display the global defaults.
Workflow history for node 31523089-f648-4883-9087-ef9a0b83129f will be deleted after 10 days for the statuses defined in the global StatusesToDelete property.
Workflow history for all nodes using the ContentPage Document Type will never be deleted.
Workflow history with Cancelled status for all nodes using the NewsItem Document Type will be deleted after 100 days (see also StatusesToDelete configuration).
{
"Umbraco": {
"Workflow": {
"HistoryCleanupPolicy": {
"EnableCleanup": true,
// Below settings are optional
"FirstRunTime": string; the time to first run the scheduled cleanup task, in crontab format
"Period": string; how often to run the task, in timespan format
"KeepHistoryForDays": int; delete history after this many days
"StatusesToDelete": refer to StatusesToDelete configuration below
"CleanupRules": refer to Configuration examples below
}
}
}
}{
"Umbraco": {
"Workflow": {
"HistoryCleanupPolicy": {
"EnableCleanup": true,
"KeepHistoryForDays": 90,
"StatusesToDelete": {
"Approved": true,
"Cancelled": true,
"CancelledByThirdParty": false,
"Errored": false
}
"CleanupRules": {
"dcf18a51-6919-4cf8-89d1-36b94ce4d963": {
"EnableCleanup": false
},
"31523089-f648-4883-9087-ef9a0b83129f": {
"KeepHistoryForDays": 10
},
"ContentPage": {
"EnableCleanup": false
},
"NewsItem": {
"KeepHistoryForDays": 100,
"StatusesToDelete": {
"Approved": false,
"Cancelled": true,
"CancelledByThirdParty": false,
"Errored": false
}
}
}
}
}
}
} "HistoryCleanupPolicy": {
"StatusesToDelete": {
"Approved": true,
"Cancelled": true,
"CancelledByThirdParty": true,
"Errored": true,
"PendingApproval": false,
"Rejected": false,
"NotRequired": false,
"Resubmitted": false
}
} "HistoryCleanupPolicy": {
"EnableCleanup": true,
"StatusesToDelete": {
"Approved": true,
"Cancelled": false,
"CancelledByThirdParty": false,
"Errored": false
}
}Get an overview of the things changed and fixed in each version of Umbraco Workflow.
In this section, we have summarized the changes to Umbraco Workflow released in each version. Each version is presented with a link to the Workflow issue tracker showing a list of issues resolved in the release. We also link to the individual issues themselves from the detail.
If there are any breaking changes or other issues to be aware of when upgrading they are also noted here.
This section contains the release notes for Umbraco Workflow 13 including all changes for this version.
Updates all persistence operations to use scoped transactions.
Fixes a bug where rejected tasks were shown as pending approval for users belonging to the rejecting group.
Fixes a bug where Advanced Search could not find property editor views.
Updates Umbraco.Licenses dependency to 13.3.3.
Ensures inherited group members are always populated
Adds an option to disable the remote version check
Corrects user attribution when completing a workflow. Previously the resulting publish was attributed to the user who actioned the last task in the workflow. The correct attribution is the user who started the workflow.
Ensures DateHelper.getLocalDate
Additional formatting and content improvements in email task summaries
Improves task summary display in notification emails
Improves empty searching in Advanced Search
Fixes an issue in Offline Approval where cultures were not always cased consistently
Fixes an intermittent issue where fetching approval groups in a mapper resulted in a scoping error
Dependency update for Umbraco.Licenses and Microsoft.Extensions.FileProviders.Abstractions (making this release a minor)
Fixes pagination in assigned-to task table
Fixes off-by-one bug when calculating approval thresholds with implicit approval
Allow searching for empty fields in advanced search. For example, search for all Product documents with no SKU
Fixes a bug where inherited group members were not always mapped to the parent user group. This resulted in an incorrect warning message being displayed in the Backoffice
Fixes a bug where group permissions were not reset when removing a group from a Document Type approval flow. This caused an exception when attempting to initiate a workflow using the Document Type flow, as no permissions would be found for the first approval stage
Fixes a bug where the document path was incorrectly set as a number array instead of a comma-delimited string. In certain scenarios this caused a validation error when attempting to save a new document, leaving the document uneditable.
Ensures new and/or dirty documents are saved before submitting for workflow approval. For new documents, also ensures the backoffice state updates correctly
Fixes workflow task summary generation in email body
Updates Umbraco.Licenses dependency
Refactors migration plan naming to align with the broader DXP product suite.
Adds scheduled content locking feature. Documents can be made readonly until the scheduled release date passes, to ensure approved content is not modified without workflow approval.
Adds support for content segments. Segment names are displayed when requesting approval and in workflow history
Adds support for Arabic.
Improves UI in workflow detail overlay. Reduces the number of elements and shifts appropriate data points into tag elements.
Ensure scheduling information is displayed in workflow history
Fixes an issue where dates were not correctly localized for scheduled workflows
Fixes an issue where scheduled workflows did not apply the release/expire date if the content node was already scheduled
Ensure converting integers to strings uses the invariant culture to avoid unexpected formatting
Fixes an issue where an awaited call does not trigger an AngularJS digest, causing the UI to hang.
Fixes an issue where dates were not correctly localised in the Backoffice
Fixes an issue related to sending notification emails in sites with a large number of Workflow groups
BREAKING CHANGE resolving includes removing the DateTimeSettings
Updates Umbraco dependencies to require 13.1.0 minimum (the oldest v13 version without a reported vulnerability)
Fixes pagination in content review table in editor dashboard
Fixes an issue where Content Review notification emails failed to send due to attempting to access UmbracoContext in a hosted service
Fixes an issue where SQL query generation exposed a potential injection vector.
Make dashboard, content app, and section registration classes public
Fixes discrepancy between a JSON property attribute value and property name in WorkflowTaskCollectionViewModel, which resulted in unexpected JSON values.
Incorrectly tagged and released as 13.0.5 🤦
Fixes issue where invariant workflows on variant content would publish previously published, but currently unpublished, variants .
Fixes issue where split-view allowed publishing content without using Workflow .
The above fixes introduce an updated UI for requesting workflow approvals. For more information, see the article.
Fixes bug where workflow submission was not respecting user's language access permissions
Fixes bug where approval groups were not populated for new nodes using the new-node approval workflow
Updates internal license validation to handle licenses registered with 'UmbracoWorkflow' or 'Umbraco.Workflow'
Compatibility with Umbraco 13
For full details of breaking changes refer to the
FEATURE => Advanced Search dashboard. Refer to for more details.
You can find the release notes for versions out of support in the
Content reviews is a tool that allows content editors to keep their content up-to-date. Content reviews adds a new dashboard to the Workflow section. By default, Content reviews are disabled and can be enabled from Content reviews Settings in the Workflow section.
The Content reviews Dashboard provides an overview of the expired content. The dashboard displays a table containing the following details:
Page name/Node with the Language variant
Next review due date
Last reviewed date
Review period in days
Selecting a content node takes you to the content node in the Content section where you can see the Content review banner. The Content review banner is displayed only when the node has passed its review date. Also, the review banner is displayed only to users assigned as reviewers for the node. For more information, see the section
Clicking on Mark as reviewed allows the review group member to mark the content as reviewed. Optionally, the review group member can also set the next review date on the content node. The next review date must fall inside the review period set in the Content Reviews Settings.
You can also Filter the Dashboard records based on the Node, Group Email, Next review due date, Last reviewed date, and Expired review Status.
Additionally, you can adjust the total number of records displayed on a page.
The Content reviews Settings tab provides a range of settings for configuring email notifications, review period days, reminder days, and so on. Using Content reviews, all content has a default review period.
You can configure the General Settings from the Workflow section in the Content reviews menu. The following settings are available:
Enable content reviews - Enable this setting if you wish to remind users to review their content. By default, this option is disabled.
Send notifications - Enable this setting to send email notification to approval groups when content requires review.
Treat saving as a review? - Enable this setting to reset the review date when content is saved. Saving a content node recalculates the review date, using the review period assigned to the content node, its Document Type, or the default Review period value. If disabled, content must be explicitly reviewed via the review banner displayed on the content item.
You can configure specific review groups to review designated content nodes or Document Types. The review group responsible for reviewing content is determined by the workflow configuration. This means a site with workflow already configured can leverage the existing permissions model for assigning content review responsibilities. By default, content reviews are assigned to the approval group defined in the first stage of the workflow.
Content review permissions can be set at the node or Document Type level, both of which take precedence over any existing Workflow permissions. Permissions are assigned to user roles or groups within each workflow stage. For example:
Internal Reviewers: Users assigned to roles like Editors or Content Managers may have permissions to review content during the Internal Review stage. They ensure content quality, compliance with standards, and provide feedback for improvements before the content is published.
External Reviewers: External reviewers are users who are invited to participate in the content review process but do not have Backoffice access. Their main role is to provide feedback or suggest changes based on their expertise or stake in the content being published. This feedback is not managed by Workflow.
The current permissions for a content node are displayed in the Workflow content app on the Configuration tab.
You can configure content reviews for individual content nodes or for all nodes of a given Document Type. For both Content Item and Document Type Reviews, the following settings are available:
Language - Allows you to specify which language version of the content is being reviewed.
Exclude from review - Enable this setting to ignore the specific content node (or all content nodes of this Document Type) when determining nodes to review.
Review period (days) - The review period in days between required reviews.
To add a content item review, follow these steps:
Go to the Workflow section.
Go to the Settings tab in the Content reviews menu.
Click Add in the Content item reviews section.
To Edit a content item review, click Edit and update the settings as per your requirement.
To remove a content item review, click Remove.
To add a Document Type review, follow these steps:
Go to the Workflow section.
Go to the Settings tab in the Content reviews menu.
Click Add in the Document-type reviews section.
To Edit a Document-type review, click Edit and update the settings as per your requirement.
To remove a Document-type review, click Remove.
Content review notifications use the email template available at ~/Views/Partials/WorkflowEmails/ContentReviews.cshtml, which can be customized as required. For example to add a corporate branding or send customized messages.
To add templates for other languages:
Go to the ~/Views/Partials/WorkflowEmails/ folder.
Copy the required template and paste it into the same folder.
Append the culture code to the file name prefixed with an underscore.
For example:
Default approval request template: ~/Views/Partials/WorkflowEmails/ContentReviews.cshtml
Danish approval request template: ~/Views/Partials/WorkflowEmails/ContentReviews_da-DK.cshtml
Fixes attribute-binding bug on settings views, affecting Umbraco 13.7.0 #98
Adds email queue for thread-safe email notifications. Emails are now processed in the hosted service, via a first-in first-out queue. This resolves a reported issue where sending large numbers of emails could result in data reader errors. #85
Fixed issue with scheduled workflows on invariant content #49
Introduces lazy constructor parameters to prevent database access when Workflow is installed as part of a new Umbraco install
Review group
Review period (days) - The default number of days between content reviews.
Reminder threshold (days) - Determines how many days prior to the review date the Workflow should notify editors of required reviews. By default, the number of days is set to 1.
External reviewers - Assign email addresses for reviewers without CMS access. Feedback from external reviewers is not managed by Workflow.
Select Content node to add to the Content item reviews section.
Select the Language from the drop-down.
[Optional] Enable Exclude from Review if you wish to exclude this content node from content review. If you enable this setting, skip to step 12.
Enter the Review period in days.
Click Add to add the Review Group.
Select an approval group.
Click Submit.
[Optional] Enter a user in the External reviewers field. For example: [email protected].
Click Submit.
Click Save Settings.
Select Content type to add to the Document-type reviews section.
Select the Language from the drop-down.
[Optional] Enable Exclude from Review if you wish to exclude this Document-type from content review. If you enable this setting, skip to step 12.
Enter the Review period in days.
Click Add to add the Review Group.
Select an approval group.
Click Submit.
[Optional] Enter a user in the External reviewers field. For example: [email protected].
Click Submit.
Click Save Settings.
Get an overview of various options for customizing the configuration of your Umbraco Workflow installation.
With Umbraco Workflow, it is possible to customize the functionality with different configuration values.
All configuration for Umbraco Workflow is held in the appSettings.json file found at the root of your Umbraco website. If the configuration has been customized to use another source, then the same keys and values discussed in this article can be applied there.
The convention for Umbraco configuration is to have package-based options stored as a child structure. The child structure is added below the Umbraco element and as a sibling of the CMS. Workflow configuration follows this pattern, i.e.:
All Workflow configuration is optional and will fallback to defaults, if not set. The following structure represents the full set of configuration options along with the default values:
A string that represents the period between checking for, and sending, reminder notifications for overdue workflows. This setting is used in conjunction with ReminderDelay to determine if a workflow is overdue. The default value is eight hours. The permitted value is a TimeSpan-parseable string, for example, 0.00.01:00 for one minute.
A string that represents the period between checking for and sending action notifications for active workflows. The default value is five minutes. The permitted value is a TimeSpan-parseable string, for example, 0.00.01:00 for one minute.
A bool value used to enable or disable the test license. When true, and running Umbraco in development mode, all licensed features are available on local domains.
A bool value used to enable or disable the remote version check. When false, Workflow will not attempt to fetch the latest version information. When true, Workflow will send a network request to the Umbraco Marketplace API to retrieve the latest version. If a newer version exists, an update prompt is displayed in the Workflow section.
An instance of ColorSettings allowing customization of colors used in email notifications. Allows setting alternate values for red, orange, and green use to highlight workflow status in emails.
All Workflow settings can be customized in the appSettings.json file. Settings can be read-only or hidden entirely in the BackOffice. Optionally you can set the values here.
The SettingsCustomization object has two child properties:
General
ContentReviews
Both are dictionaries of SettingsCustomizationDetail objects. The value is set to the following structure that contains three settings:
IsHidden - When true, the corresponding property is not displayed in the backoffice UI
IsReadOnly - When true, the corresponding property is displayed in the backoffice UI but is not editable
Value - Sets the value for the corresponding property. This value takes priority over existing values set via the backoffice
All available SettingsCustomization options are illustrated below along with their respective values:
Sets the workflow type to one of Explicit (0), Implicit (1), or Exclude (2):
0 (default)
Explicit
Requires all steps be approved, including steps where the original change author is a group member.
1
Implicit
Auto-approves steps where the author is a member of the approving group.
2
Exclude
Behaves similarly to Explicit, but excludes the original author from any notifications (that is the author can not approve their own work).
Sets the default approval threshold to one of One (0), Most (1), or All (2):
0 (default)
One
Pending tasks require approval from any member of the assigned approval group.
1
Most
Pending tasks require approval from an absolute majority of group members. Example: A group with 3 members requires 2 approvals and a group with 4 members requires 3 approvals.
2
All
Pending tasks require approval from all group members.
When true, allows configuring the approval threshold on individual workflow stages.
When true, and ApprovalThreshold is Most or All, rejecting a task resets progress towards the approval threshold for the current workflow stage.
When true, prevents editing content where the node is in an active workflow. When false, content can be edited at any stage of a workflow.
Sets the scheduled content lock to one of None (0), Workflow (1), or All (2):
0 (default)
None
Scheduled content is not locked
1
Workflow
Content scheduled via Workflow can not be edited
2
All
All scheduled content can not be edited
When true (default), comments are required when approving a workflow task. When false, comments are optional when approving a workflow task. Comments are always required when submitting changes for approval.
When true, displays an optional media picker when initiating a workflow. The selected media item can be used to provide further context or explanation of the content changes.
When true, displays optional controls for scheduling publish/unpublish when initiating a workflow. The scheduling uses Umbraco's existing content scheduling functionality.
When true, content must be approved via a workflow when unpublishing. When false, user with appropriate permission can unpublish content without workflow approval.
When true, Workflow adds additional buttons to the editor footer (Request publish and Request unpublish, if the latter is required). When false, Workflow replaces the existing editor footer buttons.
When true, Workflow will send email notifications in response to workflow changes. When false, no emails are sent.
The from address for email notifications.
The number of days after which to start sending reminder emails for incomplete workflows.
The URL at which editors access the BackOffice eg https://edit.mysite.com. Used for generating links to nodes in email notifications. Must be fully qualified and not include the /umbraco path.
The URL at which users access the live site eg https://mysite.com. Used for generating links in email notifications. Must be fully qualified.
When set, this flow is used for all new nodes on the first approval request. Subsequent workflows use the permissions set on the node (or content type, or inherited from an ancestor node). This is a complex type and ideally would not be set via configuration.
Sets workflow permissions for Document Types (that is: all items of BlogItem type use the same workflow). The Document Type flow is used when a content node has no explicit permissions set. This is a complex type and ideally should not be set via configuration.
Allows excluding segments of the content tree from the workflow model. This is a complex type and ideally would not be set via configuration.
When true, the content review engine will monitor publication dates to determine content review requirements.
Sets the number of days between mandatory reviews. This is a global value that can be overridden at the node or content type level.
Sets the date on which to send notification emails, prior to the review date elapsing. For example, if the ReviewPeriod is 20 and the ReminderThreshold is 3, notifications will be sent in 17 days or 3 days before the review date.
When true, Workflow will send email notifications to approval groups, with a digest of expiring and expired content.
When true, publishing a node is treated as a review, and will generate a new review date. When false, content must be explicitly reviewed via the review banner rendered at the top of the editor.
For example: To set the site URL, hide it in the backoffice, and set the content review period but keep the property read-only. The configuration would look like this:
Your Integrated Development Environment (IDE) will provide intellisense for the available settings but does not provide the valid value types. Settings are validated on startup and Umbraco will throw an exception if a known setting is provided with an invalid value.
{
...
"Umbraco": {
"CMS": {
...
},
"Workflow": {
...
}
}
}{
"Workflow": {
"ReminderNotificationPeriod": Timespan.FromHours(8),
"ActionNotificationPeriod": Timespance.FromMinutes(5),
"EnableTestLicense": false,
"DisableVersionCheck": false,
"SettingsCustomization": {...},
"HistoryCleanupPolicy": {...}
}
}{
…
"MySettingKey": {
"IsHidden": false,
"IsReadOnly": false,
"Value": 42
}
…
}{
"Workflow": {
…
"SettingsCustomization": {
"General": {
"FlowType": 0|1|2 matching the FlowType enum values,
"ApprovalThreshold": 0|1|2 matching the ApprovalThreshold enum values,
"ConfigureApprovalThreshold": bool,
"RejectionResetsApprovals": bool,
"LockIfActive": bool,
"ScheduledContentLock": 0|1|2 matching the ScheduledLockMode enum values,
"MandatoryComments": bool,
"AllowAttachments": bool,
"AllowScheduling": bool,
"RequireUnpublish": bool,
"ExtendPermissions": bool,
"SendNotifications": bool,
"Email": string,
"ReminderDelay": int,
"EditUrl": string,
"SiteUrl": string,
"NewNodeApprovalFlow": *,
"DocumentTypeApprovalFlow": *,
"ExcludeNodes": *,
},
"ContentReviews": {
"EnableContentReviews": bool,
"ReviewPeriod": int,
"ReminderThreshold": int,
"SendNotifications": bool,
"PublishIsReview": bool
}
}
}
}{
"Workflow": {
"SettingsCustomization": {
"General": {
"SiteUrl": {
"IsHidden": true,
"Value": "https://www.myawesomesite.com"
}
},
"ContentReviews": {
"ReviewPeriod": {
"IsReadOnly": true,
"Value": 42
}
}
}
}
}
When working with Umbraco Workflow, you can handle the workflow settings directly in the Backoffice from the Workflow section. You can configure the following from the Workflow Settings section:
You can configure the General Settings from the Workflow section in the Settings menu. The following settings are available:
Flow type - Determines the approval flow progress. These options manage how the Change Author is included in the workflow:
Explicit - All steps of the workflow must be completed and all users will be notified of tasks (including the Change Author).
Implicit - All steps where the original Change Author is not a member of the group must be completed. Steps, where the original Change Author is a member of the approving group, will be completed automatically and noted in the workflow history as not required.
All new nodes use this workflow for initial publishing. You can add, edit, or remove an approval group to/from the workflow.
To add an approval group to the workflow:
Go to the Workflow section.
Go to the General tab in the Settings menu.
Click Add in the New node approval flow section.
When you click on the Edit approval group, you are presented with different configuration options for that group. For more information on the approval group settings, see the section in the article.
To remove an approval group, click Remove.
Configure default workflows that should be applied to all content nodes of the selected Document Type. This feature requires a license.
To add a Document type approval flow:
Go to the Workflow section.
Go to the General tab in the Settings menu.
Click Add in the Document type approval flows section.
To edit a Document type approval flow:
Go to the Workflow section.
Go to the General tab in the Settings menu.
Click Edit next to the content node in the Document type approval flows section.
Nodes and their descendants selected here are excluded from the workflow process and will be published as per the configured Umbraco user permissions. This feature requires a license.
To exclude a node from the workflow process:
Go to the Workflow section.
Go to the General tab in the Settings menu.
Click Add in the Exclude nodes section.
Umbraco Workflow uses Notifications to allow you to configure email notifications for all workflow activities for the backoffice.
From the Settings view in the Workflow section, the Notifications tab provides access to the following:
Send notifications: If you wish to send email notifications to approval groups, you can enable it here. If your users are active in the backoffice, email notifications might not be required.
Workflow email: Provide a sender address for email notifications. This is a mandatory field.
Reminder delay (days): Set a delay in days for sending reminder emails for outstanding workflow processes. Set to 0 to disable reminder emails.
Notification emails use HTML templates which render information from the HtmlEmailModel type which lives in the Umbraco.Workflow.Core.Models.Email namespace. While it is possible to modify the email templates from the backoffice, we recommend making changes via an Integrated Development Environment (IDE) of your choice.
The HtmlEmailModel contains the following fields:
The HtmlEmailBase contains the following fields:
Umbraco Workflow provides Settings for determining who receives emails at which stages of a workflow. While these are set to default values during installation, it is recommended to update your Notifications Settings to better suit your installation needs. Emails can be sent to:
All: All the participants in all workflow stages (previous and current).
Admin: The admin user.
Author: The user who initiated the workflow.
Group
By default, all emails are sent to the Group. This might not always be an ideal situation. For example: canceled workflows would be best sent to the Author only, likewise with rejected.
It might be useful to notify All the participants of completed workflows but even this may be excessive. Depending on your website, you can adjust the best configuration.
Umbraco Workflow uses a reminder email system to prompt editors to complete the pending workflows. Reminders are sent using Umbraco's internal task scheduler, every 24 hours after an initial delay. For example, setting the Reminder delay (days) value to 2 in the Workflow Settings section will allow pending workflows to sit for 2 days. After that reminder emails will be sent every 24 hours to all members of the group assigned to the pending workflow task.
The emails use a similar model to the notification emails, also inheriting from HtmlEmailBase. In addition to the inherited fields, HtmlReminderEmailModel includes:
All email templates are fully localized where translations exist. You can edit the email templates in the Backoffice or in your IDE. By default, Umbraco Workflow's email templates are available in the default language.
If you wish to have one or more email templates for different languages, you will need to place all the email templates into the ~/Views/Partials/WorkflowEmails/ folder.
To add templates for other languages:
Go to the ~/Views/Partials/WorkflowEmails/ folder.
Copy the required template and paste it into the same folder.
Append the culture code to the file name prefixed with an underscore.
For example:
Default approval request template: ~/Views/Partials/WorkflowEmails/ApprovalRequest.cshtml
Danish approval request template: ~/Views/Partials/WorkflowEmails/ApprovalRequest_da-DK.cshtml
Below is an example of the ApprovalRequest.cshtml email template from the ~/Views/Partials/WorkflowEmails/ folder:
Exclude - Similar to Explicit. All steps must be completed but the original Change Author is not included in the notifications or shown in the dashboard tasks.
Approval threshold - Sets the global approval threshold to One, Most or All:
One - Pending task requires approval from any member of the assigned approval group. This is the default behavior for all installations (trial and licensed).
Most - Pending tasks require an absolute majority of group members. For example, a group with three members requires two approvals and a group with four members requires three approvals.
All - Pending task requires approval from all group members.
Rejection resets approvals - When true, and the approval threshold is Most or All, rejecting a task resets the previous approvals for the workflow stage.
Allow configuring approval threshold - Enables setting the approval threshold for any stage of a workflow (on a content node or Document Type).
Lock active content - Determines how the content in a workflow should be managed. Set to true or false depending on whether the approval group responsible for the active workflow step should make modifications to the content. Content is locked after the first approval in the workflow - until then, the content can be edited as normal.
Lock scheduled content - When not None, prevents edits to content with a scheduled release date:
None - Disables scheduled content locking
Workflow - Prevent editing scheduled content when scheduling was approved via Workflow
All - Prevents editing all scheduled content
Administrators can edit - Set to true to allow administrators to edit content at any stage of the workflow, ensuring flexibility and control over the content approval process.
Mandatory comments - Set to true to require comments when approving workflows. Comments are always required when submitting changes for approval and are always optional for admin users.
Allow attachments - Provide an attachment (such as a supporting document or enable referencing a media item) when initiating a workflow. This feature is useful when a workflow requires supporting documentation.
Allow scheduling - Provides an option to select a scheduled date when initiating a workflow.
Use workflow for unpublish - Determines if unpublish actions require workflow approval. Set to true to display the Action option when submitting the content for approval.
Extend permissions - Determines if Umbraco Workflow should extend or replace the users' save and publish permissions. The default behavior is to replace the users' permissions.
Select an approval group to add to the workflow.
Click Submit.
Click Save Settings.
Select a Document type from the drop-down list.
Select a Language from the drop-down list.
Add workflow approval groups in the Current flow process.
Click Add condition to add a condition to the workflow process.
Click Submit.
Click Save Settings.
Select a Language from the drop-down list.
Add, Edit, or Remove approval groups from the current workflow.
Click Add condition to add a condition to the workflow process.
Click Submit.
Click Save Settings.
Select the Content node from the Content tree.
Click Submit.
Click Save Settings.
Edit site URL: The URL for the editing environment (including schema - http[s]). This is a mandatory field.
Site URL: The URL for the public website (including schema - http[s]). This is a mandatory field.
Email templates: Configure which users receive emails for which workflow actions and modify the templates for those emails.
Instance
WorkflowInstanceViewModel
The view model data for the current workflow. Best explored via Intellisense.
To
EmailUserModel
The model defining the receiver of the email.
string
The user's email address or a group address (if a group email is being sent).
Name
Name
The user's name.
Language
string
The user's language.
Id
int
The user's ID or group ID (when sending to a group email address).
IsGroupEmail
bool
Is the email being sent to a generic group email address?
WorkflowType
WorkflowType
An enum value containing either 1 or 2 for Publish and Unpublish respectively.
ScheduledDate
DateTime
If a scheduled date exists for the workflow, it is found here.
Summary
IHtmlString
A pre-generated representation of the current workflow state.
CurrentTask
WorkflowTaskViewModel
SiteUrl
string
The public URL of your site.
NodeName
string
The name of the node from the current workflow.
Type
string
The workflow type including the scheduled date (if exists).
EmailType
EmailType
OverdueTasks
IList
A list containing all the overdue tasks assigned to the current user.
TaskCount
int
The count of overdue tasks assigned to the current user.
The view model data for the current workflow task. Contains a lot of useful data, best explored via Intellisense.
An enum value representing the current email type that relates directly to the workflow task type.
@model Umbraco.Workflow.Core.Models.Email.HtmlEmailModel
// Refer to the documentation for Email templates for a full rundown on the available fields
// or (better option), edit the template in Visual Studio where Intellisense will save you
<!DOCTYPE html>
<html>
<head>
<!-- will be used as the email subject line -->
<title>Workflow: Approval request</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
</head>
<body>
<div>
<h1>Hello @Model.To.Name,</h1>
<p>Please review the following page for @Model.Type.ToLower() approval:</p>
<ul>
<li>
<a href="@Model.CurrentTask.BackofficeUrl">@Model.CurrentTask.Node.Name</a>
@if (!string.IsNullOrEmpty(Model.CurrentTask.OfflineApprovalUrl))
{
<span><a href="@Model.CurrentTask.OfflineApprovalUrl">Offline approval</a> is permitted for this change (no login required).</span>
}
</li>
</ul>
</div>
</body>
</html>
Umbraco Workflow uses Notifications to allow you to hook into the processes for the backoffice. For example, you might want to execute some code every time an approval group is updated. Notifications allow you to do that. For more information on how Umbraco implements Notifications, see the Using Notifications article.
All notifications reside in the Umbraco.Workflow.Core.Notifications namespace and are postfixed with Notification.
Typically, available notifications exist in pairs, with a "before" and "after" notification. For example, the SettingsService class publishes both a WorkflowSettingsSavingNotification and a WorkflowSettingsSavedNotification when settings are modified.
Which one you want to use depends on what you want to achieve. If you want to cancel the action, you will use the "before" notification and use the CancelOperation method on the notification to cancel it. If you want to execute some code after the settings have been updated, then you would use the "after" notification.
WorkflowContentReviewsReviewingNotification
ContentReviewNodePoco Target
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when ContentReviewService.MarkAsReviewed is called in the API before the node review status is updated. Target: Get an object with information about the node being reviewed.
WorkflowContentReviewsReviewedNotification
ContentReviewNodePoco Target
EventMessages Messages
IDictionary<string,object> State
Published when ContentReviewService.MarkAsReviewed is called in the API after the node review status is updated. Target: Get an object with information about the reviewed node.
WorkflowNodeConfigDeletingNotification
IEnumerable<IWorkflowConfig> DeletedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when ConfigService.DeleteNodeConfig is called in the API before the config items are deleted. DeletedEntities: Gets the collection of IWorkflowConfig objects being deleted.
WorkflowNodeConfigDeletedNotification
IEnumerable<IWorkflowConfig> DeletedEntities
EventMessages Messages
IDictionary<string,object> State
Published when ConfigService.DeleteNodeConfig is called in the API after the config items are deleted. DeletedEntities: Gets the collection of deleted IWorkflowConfig objects. Note these items are no longer in the database and exist only in memory.
WorkflowNodeConfigSavingNotification
IEnumerable<IWorkflowConfig> SavedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when ConfigService.UpdateNodeConfig is called in the API. SavedEntities: Gets the collection of IWorkflowConfig objects being saved.
WorkflowNodeConfigSavedNotification
IEnumerable<IWorkflowConfig> SavedEntities
EventMessages Messages
IDictionary<string,object> State
Published when ConfigService.UpdateNodeConfig is called in the API after the entities have been saved. SavedEntities: Gets the collection of saved IWorkflowConfig objects.
WorkflowGroupSavingNotification
IEnumerable<IWorkflowGroup> SavedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when GroupService.UpdateUserGroupAsync is called in the API before the group is updated. SavedEntities: Gets the collection of IWorkflowGroup objects being saved.
WorkflowGroupSavedNotification
IEnumerable<IWorkflowGroup> SavedEntities
EventMessages Messages
IDictionary<string,object> State
Published when GroupService.UpdateUserGroupAsync is called in the API after the group is updated. SavedEntities: Gets the collection of saved IWorkflowGroup objects.
WorkflowInstanceCompletedNotification
IWorkflowInstance Target
WorkflowType WorkflowType
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowProcess.HandleCompleteNow or WorkflowProcess.HandleCompleteLater is called in the API after the workflow is completed. Target: Gets the completed IWorkflowInstance object. WorkflowType: Gets the WorkflowType enum value representing the workflow type. Will be either Publish or Unpublish.
WorkflowInstanceCreatingNotification
IWorkflowInstance CreatedEntity
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when WorkflowProcess.InitiateWorkflow is called in the API before the workflow is initiated. CreatedEntity: Gets the IWorkflowInstance object being created.
WorkflowInstanceCreatedNotification
IWorkflowInstance CreatedEntity
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowProcess.InitiateWorkflow is called in the API after the workflow is initiated. CreatedEntity: Gets the created IWorkflowInstance object.
WorkflowInstanceRejectingNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowProcess.ActionWorkflow is called in the API before the workflow stage is rejected. Target: Gets the IWorkflowInstance object being rejected. Action: Gets the WorkflowAction being executed. Will be WorkflowAction.Reject.
WorkflowInstanceRejectedNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowProcess.ActionWorkflow is called in the API after the workflow stage is rejected. Target: Gets the rejected IWorkflowInstance object. Action: Gets the WorkflowAction being executed. Will be WorkflowAction.Reject.
WorkflowInstanceResubmittingNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowProcess.ResubmitWorkflow is called in the API before the workflow stage is resubmitted. Target: Gets the IWorkflowInstance object being resubmitted. Action: Gets the WorkflowAction being executed. Will be WorkflowAction.Resubmit.
WorkflowInstanceResubmittedNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowProcess.ResubmitWorkflow is called in the API after the workflow stage is resubmitted. Target: Gets the resubmitted IWorkflowInstance object. Action: Gets the WorkflowAction being executed. Will be WorkflowAction.Resubmit.
WorkflowInstanceUpdatingNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
Base notification class for Approving, Cancelling, Creating, Rejecting, Resubmitting. Can be used in place of these, using the Action value to identify the executed workflow action. Published when WorkflowProcess.ResubmitWorkflow is called in the API before the workflow is updated. Target: Gets the IWorkflowInstance object being updated. Action: Gets the WorkflowAction being executed.
WorkflowInstanceUpdatedNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
Base notification class for Approved, Cancelled, Created, Rejected, Resubmitted. Can be used in place of these, using the Action value to identify the executed workflow action. Published when WorkflowProcess.ResubmitWorkflow is called in the API after the workflow stage is updated. Target: Gets the updated IWorkflowInstance objects. Action: Gets the WorkflowAction being executed.
WorkflowResubmitTaskCreatingNotification
IWorkflowInstance CreatedEntity
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when WorkflowProcess.ResubmitWorkflow is called in the API before the workflow task is persisted. CreatedEntity: Gets the IWorkflowTask object being created.
WorkflowResubmitTaskCreatedNotification
IWorkflowInstance CreatedEntity
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowProcess.ResubmitWorkflow is called in the API after the workflow task is persisted. CreatedEntity: Gets the created IWorkflowTask.
WorkflowTaskCreatingNotification
IWorkflowInstance CreatedEntity
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when WorkflowTaskManager.CreateApprovalTask is called in the API before the workflow task is persisted. CreatedEntity: Gets the IWorkflowTask object being created.
WorkflowTaskCreatedNotification
IWorkflowInstance CreatedEntity
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowTaskManager.CreateApprovalTask is called in the API after the workflow task is persisted. CreatedEntity: Gets the created IWorkflowTask.
WorkflowTaskUpdatingNotification
IWorkflowInstance Target
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when WorkflowTaskManager.ResubmitWorkflow is called in the API before the workflow task is updated. CreatedEntity: Gets the IWorkflowTask object being updated.
WorkflowTaskUpdatedNotification
IWorkflowInstance Target
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowTaskManager.ResubmitWorkflow is called in the API after the workflow task is updated. CreatedEntity: Gets the updated IWorkflowTask.
WorkflowContentReviewsConfigSavingNotification
IEnumerable SavedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when ContentReviewService.SaveContentReviewConfig is called in the API. SavedEntities: Gets the collection of IWorkflowConfig objects being saved.
WorkflowContentReviewsConfigSavedNotification
IEnumerable SavedEntities
EventMessages Messages
IDictionary<string,object> State
Published when ContentReviewService.SaveContentReviewConfig is called in the API after the entities have been saved. SavedEntities: Gets the collection of saved IWorkflowConfig objects.
WorkflowContentReviewsEmailNotificationsSendingNotification
Dictionary<UserGroupPoco, List<ContentReviewConfigPoco>> Target
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when ContentReviewReminderEmailer.SendReviewReminders is called in the API before email notifications are sent. Target: Gets a dictionary containing information about the nodes requiring review, and the assigned review groups.
WorkflowContentReviewsEmailNotificationsSentNotification
Dictionary<UserGroupPoco, List<ContentReviewConfigPoco>> Target
EventMessages Messages
IDictionary<string,object> State
WorkflowContentTypeConfigDeletingNotification
IEnumerable<IWorkflowConfig> DeletedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when ConfigService.DeleteContentTypeConfig is called in the API before the config items are deleted. DeletedEntities: Gets the collection of IWorkflowConfig objects being deleted.
WorkflowContentTypeConfigDeletedNotification
IEnumerable<IWorkflowConfig> DeletedEntities
EventMessages Messages
IDictionary<string,object> State
Published when ConfigService.DeleteContentTypeConfig is called in the API after the config items are deleted. DeletedEntities: Gets the collection of deleted IWorkflowConfig objects. Note these items are no longer in the database and exist only in memory.
WorkflowContentTypeConfigSavingNotification
IEnumerable<IWorkflowConfig> SavedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when ConfigService.UpdateContentTypeConfig is called in the API. SavedEntities: Gets the collection of IWorkflowConfig objects being saved.
WorkflowContentTypeConfigSavedNotification
IEnumerable<IWorkflowConfig> SavedEntities
EventMessages Messages
IDictionary<string,object> State
WorkflowEmailNotificationsSendingNotification
IEnumerable<IWorkflowInstance> Target
EmailType EmailType
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when NotificationsService.SendEmailNotifications is called in the API before email notifications are generated and sent. Target: Gets the object describing the workflow instance used to build the email messages EmailType: Gets the enum value describing the email type
WorkflowEmailNotificationsSentNotification
IHtmlEmailModel Target
List<EmailUserModel> Recipients
EmailType EmailType
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowReminderEmailer.Send is called in the API after email notifications are sent. Target: Gets the object describing the email Recipients: Gets the collection of email recipients EmailType: Gets the enum value describing the email type
WorkflowEmailRemindersSendingNotification
IEnumerable<IWorkflowInstance> Target
EmailType EmailType
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when NotificationsService.SendEmailReminders is called in the API before email notifications are generated and sent.
Target: Gets the collection of objects describing the workflow instances used to build the email messages
EmailType: Gets the enum value describing the email type. Will always be EmailType.Reminder
WorkflowEmailRemindersSentNotification
IEnumerable<IWorkflowInstance> Target
List&EmailTaskListModel> Tasks
EmailType EmailType
EventMessages Messages
IDictionary<string,object> State
WorkflowGroupCreatingNotification
IWorkflowGroup SavedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when GroupService.CreateUserGroupAsync is called in the API before the entity is created. CreatedEntity: Gets the created IWorkflowGroup object.
WorkflowGroupCreatedNotification
IWorkflowGroup SavedEntities
EventMessages Messages
IDictionary<string,object> State
Published when GroupService.CreateUserGroupAsync is called in the API after the entity has been created. CreatedEntity: Gets the created IWorkflowGroup object.
WorkflowGroupDeletingNotification
IEnumerable<IWorkflowGroup> DeletedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when GroupService.DeleteUserGroupAsync is called in the API before the group is deleted. DeletedEntities: Gets the collection of IWorkflowGroup objects being deleted.
WorkflowGroupDeletedNotification
IEnumerable<IWorkflowGroup> DeletedEntities
EventMessages Messages
IDictionary<string,object> State
WorkflowInstanceApprovingNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when WorkflowProcess.ActionWorkflow is called in the API before the workflow stage is approved. Target: Gets the IWorkflowInstance object being approved. Action: Gets the WorkflowAction being executed. Will be WorkflowAction.Approve.
WorkflowInstanceApprovedNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
Published when WorkflowProcess.ActionWorkflow is called in the API after the workflow stage is approved. Target: Gets the approved IWorkflowInstance object. Action: Gets the WorkflowAction being executed. Will be WorkflowAction.Approve.
WorkflowInstanceCancellingNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when WorkflowProcess.ActionWorkflow is called in the API before the workflow stage is cancelled. Target: Gets the IWorkflowInstance object being cancelled. Action: Gets the WorkflowAction being executed. Will be WorkflowAction.Cancel.
WorkflowInstanceCancelledNotification
IWorkflowInstance Target
WorkflowAction Action
EventMessages Messages
IDictionary<string,object> State
WorkflowSettingsSavingNotification
IEnumerable<ISettings> SavedEntities
EventMessages Messages
IDictionary<string,object> State
bool Cancel
Published when SettingsService.UpdateSettings is called in the API before the settings are saved. SavedEntities: Gets the collection of ISettings objects being saved.
WorkflowSettingsSavedNotification
IEnumerable<ISettings> SavedEntities
EventMessages Messages
IDictionary<string,object> State
Published when SettingsService.UpdateSettings SavedEntities: Gets the collection of saved ISettings objects.
Published when ContentReviewReminderEmailer.SendReviewReminders is called in the API after email notifications are sent. Target: Gets a dictionary containing information about the nodes requiring review, and the assigned review groups.
Published when ConfigService.UpdateContentTypeConfig is called in the API after the entities have been saved. SavedEntities: Gets the collection of saved IWorkflowConfig objects.
Published when WorkflowReminderEmailer.Send is called in the API after email notifications are sent.
Target: Gets the collection of objects describing the workflow instances used to build the email messages
Tasks: Gets the collection of objects describing the overdue workflows for each notified user
EmailType: Gets the enum value describing the email type. Will always be EmailType.Reminder
Published when GroupService.DeleteUserGroupAsync is called in the API after the group is deleted. DeletedEntities: Gets the collection of deleted IWorkflowGroup objects.
Published when WorkflowProcess.ActionWorkflow is called in the API after the workflow stage is cancelled. Target: Gets the cancelled IWorkflowInstance object. Action: Gets the WorkflowAction being executed. Will be WorkflowAction.Cancel.
bool Cancel
bool Cancel
bool Cancel