With Umbraco Workflow, it is possible to customize the functionality with different configuration values.
All configuration for Umbraco Workflow is held in the
appSettings.jsonfile 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 below the Umbraco element and as a sibling of 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:
“DateFormat”: “MMMM d, yyyy h:mm tt”,
“DateFormatNoMinute”: “MMMM d, yyyy h tt”,
“DateFormatShort”: “MMMM d, yyyy”,
“TimeFormat”: “h:mm tt”,
TimeSpanrepresenting the period between checking for, and sending, reminder notifications for overdue workflows. This setting is used in conjunction with
ReminderDelayto determine if a workflow is overdue.
boolvalue used to enable or disable the test license. When true, and running Umbraco in development mode, all licensed features are available on local domains.
stringvalue representing the path to the email notification templates.
An instance of
DateTimeSettingsallowing customization of date string formats. The
DateTimeSettingsclass contains properties for long and short date and time strings, plus a long date variation with no minutes.
An instance of
ColorSettingsallowing 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.jsonfile. Settings can be read-only or hidden entirely in the BackOffice. Optionally you can set the values here.
SettingsCustomizationobject has two child properties:
Both are dictionaries of
SettingsCustomizationDetailobjects. 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
SettingsCustomizationoptions are illustrated below along with their respective values:
“FlowType”: 0|1|2 matching the FlowType enum values,
These are complex types and not recommended to have values set from Configuration. Instead, these values can be set from the BackOffice to hidden or readonly to prevent further changes.
Sets the workflow type to one of Explicit (0), Implicit (1), or Exclude (2):
- Explicit requires all steps be approved, including steps where the original change author is a group member
- Implicit auto-approves steps where the author is a member of the approving group
- Exclude behaves similar to Explicit, but excludes the original author from any notifications (that is the author can not approve their own work)
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.
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
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
BlogItemtype 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 segements 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 which 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
ReviewPeriodis 20 and the
ReminderThresholdis 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 readonly, 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.
It is possible to include settings outside of those referenced by Workflow, which can be useful for providing values for use in extensions and customisations. These settings are not validated on startup, so can have any value.