(Community manager's note: If you'd like to learn about the value of Workflow Constants, please see Tomasz's post in the Nintex Product Blog: Did You Know: Workflow Constants )
There are a lot of challenges when migrating Nintex from on premise to Office 365, even using Sharegate to help you. The most important one in case of Workflow Constants is… there is no such feature available in Nintex Workflow 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. 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):
- Title (the default column in a custom list)
- StringVal (the regular Single line of text column)
- NumberVal (the regular Number column)
- 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.
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.
How to map sensitivity?
Again, the most straightforward way is to change the specific item’s permissions.
Remember, to use the “Action Set” action with the “Elevate permissions” checkbox checked to execute actions requiring access to those Constants.
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.
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.
Summary
Moving into Office 365 from on-premise is getting more and more popular and is also advertised as the most recommended approach by the Microsoft (there are numerous benefits on the one hand and so many doubts and questions on the other). Having your stable Nintex processes already created in SharePoint on-premise demands a lot of preparation before moving them to Office 365. One of the key features, that is often used in SharePoint, but not available in SharePoint Online, are the Workflow Constants. I hope this post will help you in their migration.
For more information regarding preparing your Nintex to be ready for Office 365 please read my other post: Nintex Workflow Migration from on premise to Office 365.
Please, feel free to share your thoughts and approach for working with Workflow Constants after moving from on premise to Office 365.
