To date in Nintex Workflow Cloud (NWC), designers and developers have had the capability to publish changes to any type of workflow. If this works for you, you can leave this setting in place...however, if your organisation insists on additional governance or demands greater visibility of when changes are being made, NWC now offers configuration options to specify who should have the ability to publish changes to workflow.

Let's find out more!

Your admins will find new options available on the Workflow settings page under Settings. The Workflow publishing section is where to look to begin configuring the new feature.

When you first visit this page, the Designer and Developer option will be selected under Workflow publishing. This is the status quo...how NWC has worked up until now. If you are happy with this model for publishing, you need do no more!

Now let's look at the second option...Groups. Toggling the main setting to Groups allows us to add one or more groups of users who will be permitted to approve publishing of workflows. Groups can be created and managed on the User management page - you may have used this previously to assign groups of users for workflow ownership.

Let's create a new group and add a user.

And now I'll assign that group to the workflow publishing approval feature - the option to send an email notification to the group members has been selected.

Now let's look at the impact of this change. Switching my profile to a different user, Taro, who has a designer role in NWC (but is not a member of the publishers approval group). Taro has made a change to the workflow and is ready to publish. On selecting the Publish option the first notable change is the yellow banner warning message displayed. This indicates that publishing is on request only.

At the bottom of the form the action button reflects this.

The confirmation message is again clear that publishing has not yet taken place:

The status of the workflow is now reflected as Publish requested.

Now let's look at what the members of our workflow publishing approval group are seeing.

Each of them will have received an email notification. The notification contains a link to the list of workflows with a filter applied to show only those for which publishing has been requested.

Here's what the approver sees, note the pre-configured filter for workflow status:

Typically then the approver will open the workflow, perform their technical review and typically inspect the version history to review commentary added by the developer e.g.

(remember you can also make version comments mandatory in Workflow settings).

Member of the approvers group can then publish the workflow normally, bypassing the request feature.

In the example above we saw a workflow that did not have a previously published version. Below we can see how this looks in the workflow list if a published workflow has a new publishing request submitted (this is similar to how we view draft versions now).

Let's consider a couple more scenarios:

• The approver is unhappy with the changes and does not wish to publish the workflow
• The developer identifies a problem or wishes to continue making more changes

Both the developer or the approver group have the ability to cancel the publish request by using the Cancel publish request option that now appears on the context menu for the pending workflow item.

As you might expect, the impact of that is to set the status of that pending workflow back to Draft.

We are already familiar with the concept of 'Assigned use' for our workflows...that being Production or Development. So, it's important to know that the publishing approval feature ONLY applies to Production workflows.  Your developers can readily continue to work on their dev workflows, and publish them without waiting for further approval.