Overview
After creating an NWC workflow, it must be deployed for consumption. There are 3 different approaches one can take when deploying an NWC workflow.
Use OOTB UI deployment with one environment. Not recommended, especially if the solution being deployed has several connections and each could have different environment configurations.
Note: It’s also possible to export/import from/to the same environment, as you are able to set a new name as “import time”. Use the OOTB UI deployment to export/import to multiple environments. Recommended and outlined below. Use NWC's API to handle deployments in bulk to multiple environments. Powerful automated approach for solutions with multiple workflows, but proceed with caution, as the aforementioned deployment tool has yet to be fortified and undergo rigorous testing. This has been tested w/about 100 workflows and appears to work well. The only shortcoming of using the API is you cannot import a workflow if one with the same name already exists, which is available from the UI when publishing.
Note: At the time of writing this article, it’s rumored that this feature is coming.
Environments
It’s recommended to setup distinct environments to manage changes that occur during the life cycle of a project. Dev, Test, and Prod, for example. This allows development, testing, and usage of the solution to take place simultaneously.
Example of one environment:
https://acme.workflowcloud.com/
Example of multiple environments (recommended):
https://acme-dev.workflowcloud.com/ https://acme-test.workflowcloud.com/ https://acme.workflowcloud.com/
Connections
Within most workflows, connections are used to access various systems. Each environment will have a different configuration. For example, the configuration for a SQL connection in Dev will be different than the one for Prod.
Be sure to use the same name for the connections in your workflow across environments. This will allow NWC to automatically map to the new settings for the target environment.
Ideal 👍
| Dev | Test | Prod |
| “My SQL Conn” | “My SQL Conn” | “My SQL Conn” |
Asking for trouble 🤔
| Dev | Test | Prod |
| “My SQL Conn – Dev” | “My SQL Conn – Test” | “My SQL Conn – Prod” |
If you do not keep the connection names the same, NWC will not auto map the connection configuration when deploying the workflow to a new environment. This will require extra effort and introduce unwanted risk.
Not only will this take extra time to manually reconfigure each connection, but introduces the possibility of human error. When deploying from one environment to another, best to not have to make any edits to the solution at hand.
Note: Xtensions may behave differently. It’s recommended double checking this. We know they are not part of the “deployment” but it’s possible connections may not map even if the names are identical.
Deployments
Option #2 - Using the OOTB UI with multiple environments:
Export the workflow (i.e., “My Workflow”) and copy the key. Import the workflow key into new environment. When using the same name as the target workflow, an option becomes available to override the existing workflow -- “A workflow with this name already exists. Overwrite the existing workflow? Yes/No” Answering Yes to this question will override the existing workflow with the new version that was initially published as a draft. By doing this, several key things to note:
A new version is created. The workflow gets updated, but the connections switch to using the target environment’s configurations (if the connection names are identical). The URL stays the same. No manual edits required. In-flight workflow instances remain on the current version, but performing verification testing in a lower environment is recommend prior to deploying to production.
Delete draft workflow.
Option #3 - Using NWC’s REST APIs with multiple environments:
There's also an in-house tool that was developed to publish workflows in bulk using in Nintex’s REST APIs. It's called, “NWC Package & Deploy”.
This tool allows selecting an array of workflows that can then be published from one environment to another at a click of a button. This tool essentially follows the steps outlined above but automates and executes commands in a batch.
This tool is not public and is only available to internal team members upon request.
See https://developer.nintex.com/ for more details. For example, here’s how one would get a list of workflows: https://developer.nintex.com/docs/nwc-api-docs/b3A6MTMxODMzNDU-list-workflows
