Workflow constants are a feature available only in Nintex Workflow for SharePoint on premises, allowing you to store globally used workflow variables in a single place. These variables can be then used across all web applications and site collections in your SharePoint Farm, or just in a single site – depending on the scope where they were created.

There are numerous use cases where Workflow Constants can be used: keep user credentials used for authentication in actions, keep thresholds for approvals, or keep specific dates, which are important for your company operational processes and many more, generally related to the “dictionary” purposes.

What is a Workflow Constant?

There are three scopes on which you can create Workflow Constant:

1. Farm level (available only via SharePoint Central Administration: {CA-URL}/_layouts/15/NintexWorkflow/ManageCredentials.aspx?scope=farm&src=/_admin/NintexWorkflow/Management.aspx),
2. Site level ({SP-URL}/_layouts/15/NintexWorkflow/ManageCredentials.aspx?Scope=Site),
3. Web level ({SP-URL}/_layouts/15/NintexWorkflow/ManageCredentials.aspx?Scope=Web)

You can choose between five types:

1. String
2. Number
3. Date
4. Credential
5. Secure string

There is also a possibility to mark a Constant as “sensitive” (so there won’t be a possibility to display its contents ex. when logging to workflow history). The “Credential” and “Secure String” constants are “sensitive” by default. Moreover each can be set to be available either for everyone or for a specific users (and groups).

My recommended approach for Workflow Constants migration

There are a lot of challenges when migrating Nintex from on premise to Office 365, even using Sharegate to help you (read about them here: Nintex Workflow Migration from on premise to Office 365). The most important one in case of Workflow Constants is… there is no such feature available in Nintex for Office 365 at all. And that basically means migrating them requires many manual operations.

When attempting to do a migration with Sharegate, application will show you all the issues it finds in the process, also telling you, that you do have Workflow Constants used by your workflow that are not supported in migration. Workflow will be migrated, however won’t be published, as it contains references to variables not defined in target environment.

To overcome it, the best way is to create (depending on the scope of your variables) in a current Web or Site, a dedicated “WorkflowConstants” SharePoint custom list. Obviously the Farm scope is unavailable, but for that purpose you can create a list in the main site collection of your tenant. The list in my case was built of the following columns (they don’t have to be Site Columns – it doesn’t matter for this case):

1. Title (the default column in a custom list)
2. StringVal (the regular Single line of text column)
3. NumberVal (the regular Number column)
4. DateVal (the regular Date column)

It should have the “Read” permissions set for all users.

How to map types?

Depending on the type of your Workflow Constant, copy paste its value in the column having the right type.

Regarding the “Credentials” type – unfortunately there is no counterpart functionality yet available in Nintex for Office 365, however work has recently started (https://nintex.uservoice.com/forums/218291-3-nintex-workflow-for-office-365/suggestions/7012107-secure-password-variable).

Regarding the “Secure string” – this should be copied into a “StringVal” column.

How to map permissions?

If the Constant was available to ”Everyone” then no changes are required.

In case it was only available for specific users, then what you should do is to open that specific list item’s permissions, break its inheritance and then set these permissions to be equal to the source one. 

[tds_warning]    Unfortunately this will not work as it did in on premise – user will be able to publish a workflow using variable, however it will be empty.[/tds_warning]

How to map sensitivity?

Again, the most straightforward way is to change the specific item’s permissions. 

[tds_info]    Remember, to use the “Action Set” action with the “Elevate permissions” checkbox checked to execute actions requiring access to those Constants.[/tds_info]

How to use them in a workflow?

The most straightforward way is to first create a Workflow Variable for each Constant you need to use, then just assign a specific value using the list lookup and item’s title as the filter, ex:

Do it for each Constant you have to use.

Workflow gets suspended?

Due to the fact, that when referencing to the Constants (by the List lookup), during publication Nintex does not check whether the user who designs the workflow, has access permissions, all potential issues with the access arises when the workflow is executed and the lookup is resolved. If the constant is crucial for a specific action to work, the workflow can possibly get suspended, because of an error.

[tds_note]    Unfortunately there is currently no better way to handle the Constants, so be sure to put crucial actions inside “Action Sets” (with elevated permissions) and to test your workflow with regular users, to be sure it gets executed without problems.[/tds_note]

 

Please, feel free to share your thoughts and approach for working with Workflow Constants after moving from on premise to Office 365.