Deploy a Workflow

K2 application elements like workflows, SmartObjects, and SmartForms must be deployed to a K2 server before they can be used. You can deploy from a design tool, such as the K2 Designer, which deploys the new or updated workflow to a K2 server.

Example of a Deployed Workflow

  1. Create the workflow.
  2. Click the File tab and select the Deploy option.
  3. The deployment process starts. You can click HIDE to hide the Deployment Started message.
  4. Your workflow deploys successfully. Click can click HIDE link to hide the Deploy Success message.
  5. To configure the workflow permissions, click the manage permissions... link. This opens K2 Management in a new page where you can set the workflow permissions.
  6. If the workflow doesn't deploy, a Deploy Error is shown.
  7. To see why the deployment failed, you must go to the Error Console. To do this, click the File tab to view the canvas. The error indicator in the lower right shows one deployment error.
  8. Click the red error indicator located at the bottom right of the canvas. The error message details open, giving you a description of the deployment error. In this example, the deployment failed due to a missing line from the Task to the Decision step.
  9. To return to your workflow, click the File tab. Fix any errors and try deploying your workflow again.
  10. To close the workflow, click the File tab and select Close.
  1. When creating your workflow, when you try to deploy it you may see that the option is not available. Take the following workflow as an example. Notice the red exclamation mark on the Claim Rejected Email step.
  2. Click the File tab and notice the Deploy option is grayed out and you can't click it.
  3. You are prevented from deploying your workflow if one or more of the step dependencies are missing or are not configured correctly. Click File to return to your workflow. Notice the error on the Claim Rejected Email step. You can use the Error Console to locate existing errors. In this example, the recipient was not configured.
  4. Add the missing recipient details to the step and then click File. The Deploy option is now available.
  1. When you create your workflow and you are ready to deploy, you notice a warning message about infinite loops.
  2. This message indicates that your workflow contains events that loop back on each other and could cause the workflow to get stuck in a loop at runtime, potentially causing performance degradation on your server. Click File to return to your workflow. Use the Error Console to locate the infinite loop. In this example the loop is on the Send Email step.
  3. You can either fix the infinite loop by redesigning your workflow or you can deploy the workflow with the loop. It is recommended that you resolve the infinite loop. For more information see Infinite Loop.

When you deploy workflows from K2 for SharePoint or K2 Designer, only the person deploying the workflow is granted Admin rights. Any additional Start / Admin / View rights need to be manually configured in K2 Management. All deployment actions use the K2 Server Service account. However, all calls to the server are validated using the users credentials.

After deploying a workflow, use the manage permissions... link on the Deploy Success toast message to navigate to K2 Management. From here you need to manually configure the workflow rights.

To access the K2 Workflow Designer you need Export rights on the Workflow Server. For more information and how to grant rights, see the Server Rights topic.

You need process rights to start, create, edit, and deploy workflows, and view workflow reports.

Process rights are permissions assigned to individuals. As the administrator you can control workflow access with these rights.

Process rights consist of the following:

Process Rights Description
Admin Required to view, add, and edit the Process Rights for a workflow and administer active workflow instances.
Start People with Start rights can start workflow instances assigned to them.
View People with View rights can view reports for all instances of a workflow.
View Participate People with View Participate rights can view reports on only on those workflow instances where they are the originator (submitted the original form), or where they actioned a task.
Server Event This is a special type of permission used for asynchronous server tasks, where an external system completes a server event such as a Send Email step.

For more information on managing workflow rights and roles see the Manage Workflow Rights and Manage Roles sections within the Workflows topic.