Versions

When a new instance of a workflow starts, it uses the Default version of the workflow. You can use the Versions tab to set a different workflow version to the default version of the workflow used for all new workflow instances.

When you publish (deploy) a new or updated workflow definition, a new version of the workflow is created in the target environment and this new version automatically becomes the default version; all new instances of the workflow use the default version.

Follow the steps below to configure a workflow version as the default version for new instances:

1. On the Process Details page, click Versions.
   
   
2. The top list displays a list of the workflow versions including information, such as when the workflow was modified and information about the workflow instances for that version.
3. Select the version you want to set as default and click Set as Default.
   
   
4. Click OK on the confirmation message.
5. The new default version is tagged with (Default).
   
   

Considerations when setting the default version of a workflow

Keep in mind the following items when setting a default version:

• Existing workflow instances are not affected when you change the default version of a workflow, only new instances of the workflow started after the applied change are affected.
• When you deploy a new version of the workflow, the deployed version automatically becomes the default version, even if you had previously set a different version as the default . You may need to reset the default version of the workflow after deploying a new version, depending on your intention.
• Nintex K2 does not automatically switch active instances of the process to the latest version

• Since SmartObjects and SmartForms always use the latest deployed version, modifying the default version of a workflow could cause errors and unexpected behavior if there are newer versions of SmartObjects, views, and forms referenced by the workflow. Since it is unpredictable how you are using SmartObjects, views, and forms in your workflows, it is impossible to provide specific guidance other than to be aware of this potential impact when setting a default version. Where possible, we recommend you allow existing instances of the workflow to complete before making changes to the default version of a workflow, especially when they also require updates to the SmartObjects, views, or forms used in the workflow.

You can delete old versions of the workflow or the entire workflow definition using the Versions page. See Considerations when deleting versions of a workflow for important notes about deleting workflow versions, How to: clean your environment by deleting application artifacts for more information about deleting application artifacts, and Workflow versioning for differences between design time versions and runtime versions.

The workflow definition life cycle begins in one of the Designers which you use to deploy the workflow to the server. There may be additional dependencies or artifacts, such as SmartObjects or reports, that rely on the data generated by the process. When you deploy the workflow, instances of that workflow start, complete, and generate reporting data in the database and other SmartObjects.

Since process definitions are continuously updated and redeployed to suit changing organizational needs, there may be multiple versions of the workflow and associated artifacts, data and other dependencies that go along with it, especially in development environments. You can delete workflows and their associated reporting data from an environment to clean up the Versions page and to reduce the size of the K2 database.

To delete a workflow version, follow these steps:

1. Select a workflow version and click Delete.
   
   
2. On the Delete Workflow page, select the options for the deletion operation (Use the table below for more information on the options listed).
   Take note of the dependencies at the bottom of the Delete Workflow page before deleting workflow versions, and remember to address other dependencies after deleting the workflow
   
   

Delete Option	What does this option do
Delete version X	This option is selected by default. When you select this option, only the selected version of the workflow is deleted.
Delete all versions except for default	This option deletes all the workflow versions except for the default version.
Delete all versions	This option deletes all workflow versions including the default version.
Delete all historical (log) data for selected versions	This check box is used in conjunction with the option for the workflow version being deleted. Select the check box if you want to remove the reporting data for the workflow version you are deleting. Selecting this option effectively deletes any history of workflow instances for the deleted versions. Use this option with caution since auditing requirements in your organization may require you to keep log data.
Delete workflow reporting SmartObjects	If the workflow contains reporting SmartObjects, use this option to delete these SmartObjects. Use the check box in conjunction with the option for the workflow version to be deleted, marking the check box if you want to delete the associated reporting SmartObjects.
OK Button	Click OK after you made your selections to delete the workflow version.
Cancel Button	Click Cancel if you do not want to delete the workflow version.

Considerations when deleting runtime versions of a workflow

• Although the Delete Workflow page attempts to identify relevant dependencies, due to the diverse and complex nature of solutions and dependencies, it is not possible to identify all dependencies impacted by deleting a workflow version. The following dependencies are checked:
• Process Version with all instances associated with that version (including Active, Running, Error, and Completed instances of the workflow)
• IPCs events (One level deep)
• Reporting SmartObjects
• SmartObjects with an association to Reporting SmartObjects (Only deleted if the Reporting SmartObjects are deleted as well)
• Event Bus Constructs / Notifications based on process name
• Check with the workflow developer so that all the related artifacts are deleted when a workflow version is deleted
• When you delete a workflow, if you see a warning notification, use caution before deleting the version
• Determining IPC dependencies depends on how you configured the IPC, Synchronous or Asynchronous:
  • Synchronous: Dependencies are determined provided at least one process instance of the parent and child is active or completed
  • Asynchronous: Since the parent process does not rely on the outcome of the child, there is no link between the two and dependencies may not be shown
  • Regardless of the IPC style used, child processes that have never been executed in the environment may not be identified and appear as dependencies

Use the Run As button to configure a workflow server event to run using different user credentials instead of the service account.

By default, server events are run as the service account. If the service account does not have the necessary permissions in a line of business system to perform the action, you may need to set a different account for the server event to use. For example, suppose that a SharePoint list is set to read-only for all users except for a particular account. The SharePoint site owner is unwilling to give the service account permissions on the list because it means a workflow designer could create a workflow that modifies the list. Because the server event is executed by the server, they could use SharePoint events in the workflow to modify the SharePoint list. One approach you can use to address this requirement is to use Run As to change the user credentials for the server event (or events) that modify items in a protected SharePoint list. Select the version of the workflow you want to modify, then select the specific event in the list of server events and set alternate credentials to use when that event is executed at runtime.

Follow these steps to configure alternate credentials for specific server events in a workflow

1. Select the Activity Name and Server Event Name from the Process Events view of the Versions tab and click Run As.
   
2. On the Configure Run As Credentials page, the default option selected is the Service Account. Select the Specified Account option to specify a different account.
   
3. Specify the credentials for the account and click OK.
   
4. When subsequent workflow instances reach this step, the event is executed using the specified credentials.
   

Considerations for setting alternate Run As credentials for server events

• It is not possible to determine and pass credentials dynamically at runtime. This means that you cannot force the system to impersonate the originator of the workflow when it performs a server event, since it is not possible to impersonate a user dynamically from a server event.
• If the specified user account’s credentials expire (for example, the password changes), the server event will fail. You must update the password when setting alternate credentials.
• The security credentials are not automatically applied to new versions of the workflow. If a new version is deployed, you must set the security credentials again.
• It is also possible for the workflow developer to assign security credentials for server events at design time. If this approach is used, the alternative credentials are automatically applied to the events when the workflow is deployed for each deployed version of the workflow. In this case it is not necessary to use Management tools to set Run As credentials again for each deployed version fo the workflow.