Pre-requisites:

The steps to create a new document workflow are mentioned below:

1. Navigate to the 'Workflows' tab and select the project in which a new workflow needs to be created.

2. Click the 'Create Workflow Definition' button to start creating a new workflow.

Alternatively, right-click the project name and select 'Create Workflow Definition'.

3. Capture required details in mandatory fields and click on 'Create' to create a new workflow record.
​
Workflow Name - Name which you want to give to the new workflow.
​
Description - Capture a brief description of this new workflow.
​
Workflow Context - Select 'Document' as workflow context.
​
Total Workflow Days - Total length of the workflow in number of days.

4. Once you click on 'Create', the visual workflow designer screen will appear. Within the shape repository in the left panel, various shapes are available to configure the workflow described below:

Accordingly, below is a description of various tools available in the top panel:

5 Example Scenario

Let us create an example workflow using all of the above shapes as per below mentioned process:
​
5a. Workflow starts when a new document revision is uploaded.
​
5b. The document controller has to change the status of newly uploaded files in 2 days.
​
5c. If document status is 'QA Checked', it should go to lead reviewer for further action.
​
5d. If document status is 'QA Rejected', then workflow should end.
​
5e. If the document status is different from the above two, then it should go back to the document controller.
​
5f. Lead reviewer changes the status again and distribute the document with other reviewers.
​
5g. If lead reviewer assigns status as 'Parallel Client Review', then document should go to the client and it should also go to other reviewers.
​
5h. Other reviewers create an aMessage on the document within 5 days.
​
5i. Client creates an aMessage on the documents.
​
5j. All documents from other reviewers and client reaches to lead reviewer.
​
5k. Lead reviewer releases the required aMessages, post which documents should reach document controller for status change.
​
5l. Workflow should end with the above step.
​

Steps to create workflow as per the above example:
​

5.1. Drag and drop the 'Play' shape onto the drawing board to start creating a new workflow. This is the starting point of workflow.

5.2. Drag and drop a connecting object (arrow) coming out from the start event.

5.3. Add a new user task which is connected with the start event using the connecting arrow mentioned above.

5.4. Once the new user task is added, you need to configure properties for the same.

Name - Key in a name for this user task.
​
Description - Enter a brief description of this user task.
​
Task - Select the task you want the user to perform. In this example workflow, it will be 'For Status Change'. See below for a list of supported user tasks:

To - Select the user who needs to perform the above task. You can select multiple users. In this example workflow, it will be a document controller.

Roles and organizations can be selected instead of individual users if a task needs to be assigned to multiple users.
Tasks can also be assigned to 'Document Publisher', 'Workflow Originator' as well as 'Document Publisher's Organization'. The visual workflow engine will pick up these values dynamically based on the actual document or workflow being executed.
​
Due Days - Specify the number of days you want to allow the user to complete a given task. Please key in '2D' if you want to give 2 days.
​
Workflow Transition Condition - Select an appropriate option from the dropdown.
Wait for all users to complete task: Workflow will halt until all selected users have completed the tasks assigned to them.
Proceed after any one person completes task: Workflow will start progressing the moment at least one user completes the task.
​
5.5. Similarly drag and drop the user task for the lead reviewer and configure its properties using the status change task and 5 due days to complete the task.
​
5.6. Now let us drag and drop an exclusive gateway on the drawing board and configure its status conditions:
​
If the document status is 'QA Checked', it should go to the lead reviewer (user task) for further tasks.
​
If the document status is 'QA Rejected', then the workflow should end.
​

To configure a status condition, click on the connecting object moving out of the exclusive gateway.
​
Click the connecting object between the exclusive gateway and lead reviewer nodes.

Now configure the properties for this connecting object:
​
Name - Key in a name for this condition.
​
Description - Key in a small description about this step if required.
​
Conditional Flow - Select 'Yes' as this flow has a condition i.e. document status marked as QA Checked. You need to select 'No' if there is no condition.

Flow Condition - Here we need to key in a small query to select the status value as 'QA Checked' as per the below steps:
​
Click on the value field in front of the flow condition.

Key in the status query as ${status== and you will see a list of available statuses along with their IDs.

Similarly, you can key in the purpose of issue query as ${poi== to see a list of available purpose of issues along with their IDs.
Status and purpose of issue conditions can be used jointly along with logical operators 'AND' and 'OR' as:
For example if 's1' is the id for the required status and 'p1' is the id for the required purpose of issue. Then:
For the 'AND' condition, the flow condition will be: ${status==s1 && poi==p1}
For the 'OR' condition, the flow condition will be: ${status==s1 || poi==p1}
Note: ${status==s1} is when the status id is equal to 1 and ${status!=1} is when the status id is not equal to 1, where == is 'equals to' while != is 'not equals to'.
​
For applying condition on multiple statuses, the flow condition will be: ${status==s1 && status==s2} where 's1' is the first status id and 's2' is the second status id respectively.
For applying condition on multiple purposes of issues, the flow condition will be: ${poi==p1 && poi==p2} where 'p1' is the first poi id and 'p2' is the second poi id respectively.
Select the appropriate status from the dropdown list i.e. in this example workflow it will be 'QA Checked'.
Complete the brace bracket and click 'OK'.

5.7. Drag and drop an end event connecting with the exclusive gateway for 'QA Rejected' status as the workflow should end if the document is rejected.
​
5.8. Configure the properties of the second connecting object between the exclusive gateway and end event as mentioned above by selecting status as 'QA Rejected'.
​
5.9. Now it is required to ensure that if the document status is anything except 'QA Checked' and 'QA Rejected' then it should go back to document controller. Drag a third connecting object coming out from exclusive gateway and going back to a system task with status change task to document controller. See below for a list of supported system tasks:

A5 10. To complete the loop, add a connecting object as output from the system task connecting it with the original user task for the document controller.
​

5.11. Continuing from steps 5e & 5f, once the document that is in 'QA Checked' status reaches the lead reviewer who reviews the document and changes its status.
​
5.12. If the status is 'Parallel Client Review' then the document should go to the client and it should also go to other reviewers, to ensure this you need to use an inclusive gateway.
​
5.13. Drag and drop an inclusive gateway on the drawing board ahead of the lead reviewer user task and connect both with a connecting object. The connecting object will be output from the lead reviewer user task and input for the inclusive gateway.
​
5.14. Now you need to ensure that documents having the status 'Parallel Client Review' should flow to the client and all others should flow to other reviewers.
​
5.15. Drag and drop a user task to the drawing board for 'Distribute' to the client and configure its properties as a user task to distribute documents to the client. Configure the properties for this task as mentioned in step d above and select 'For Distribution' task and assign it to concerned user with time line of 3D i.e. 3 days.
​
Use a connecting object to connect the inclusive gateway with the above user task. This will be the first output of the inclusive gateway. Configure the status condition in properties as described in step f above using the status value 'Parallel Client Review'.
​
5.16. Drag and drop a user task for other reviewers and configure its properties as mentioned above using the 'For Comment' task and task time as 5D i.e. 5 days and assign this task to all users who need to review these documents.
​
5.17. Use a connecting object as the second output of the inclusive gateway and input to the above-mentioned user task and mark it as default flow. This ensures all the documents having status except 'Parallel Client Review' will take this flow.
​

5.18. Using boundary timer event: The task time line mentioned in step p is five days. If we want the user not to complete this task within the stipulated timeline, then the workflow should not stop here and it should move forward to the next step. For this, put a boundary timer event on the 'Distribute to Client' user task.
While configuring the properties of the boundary timer, you need to ensure that the task time line for the main task should be less than the boundary timer time line. In this task, if the user doesn't complete the task within 5 days then after the sixth day boundary timer will trigger and the workflow will move ahead.
​
Timer interval - The boundary timer would trigger after the lapse of the duration mentioned in 'Time Interval'. This timer is to be placed on a user task and the interval set on the timer should be more than the user task. You can define the interval in days like 1D for 1 day, 2D for 2 days, 3D for 3 days and so on.
The capital letters P, M, D, T and R are designators for each of the date and time elements.
​
P is the duration designator (for the period) placed at the start of the duration representation.
​
M is the month designator that follows the value for the number of months.
​
D is the day designator that follows the value for the number of days.
​
T is the time designator that precedes the time components of the representation.
​
R is repeating intervals.
​
Time recurrences - This value indicates the number of recurrences of the boundary timer. If the value is kept as 1, the boundary timer will be executed once and the user task will be marked as cancelled. For values greater than 1, the boundary timer would execute after the lapse of the timer interval, and wait for the same time interval, to be executed again, and the user task will not be marked as cancelled after the mentioned recurrences.

5.19. Output from boundary timer: The boundary timer event has its output. In this case, let's use an exclusive gateway. Drag and drop an exclusive gateway and connect the 'Distribute to Client' user task's output and boundary timers output as input to this exclusive gateway.
​

5.20. Now we have outputs coming out from two nodes. We need to wait for both of them before proceeding ahead.
​
Output coming out of the exclusive gateway mentioned in step s and
​
Output coming out of the user task mentioned in step p
​
5.21. Now workflow cannot proceed unless both above tasks are completed, hence we will use a parallel gateway.
​
5.22. Drag and drop a parallel gateway and connect it with outputs mentioned in t --> i & t --> ii
​

5.23. Now the workflow will wait at the parallel gateway till it receives input from t --> i and t --> ii. Once both inputs are received workflow will progress to the next node i.e. distribute files to the lead reviewer where in lead reviewer will release selected aMessages on the files.
​
5.24. Drag and drop a user task after the parallel gateway which has a single input coming in from the parallel gateway.
​
5.25. Configure the user task properties using the 'For Comment Coordination' task with a task time of 5 days and assign it to the user who is the lead reviewer.
​
5.26. The next step after the lead reviewer releases selected aMessages as document status change by the document controller.
​
5.27. Drag and drop a user task for document controller status change having a 'For Status Change' task assigned to the document controller with a task time of 5 days.
​
5.28. Once the document controller changes the status of files, the workflow should end.
​
5.29. Drag and drop an end event and connect it with the document controller user task i.e. output of the user task is the input of the end event.
​
5.30. Now the workflow is fully configured & you need to save it by clicking on the 'Save' button in the top left. The completed workflow is shown in the image below:
​

6. The system will give a prompt if the workflow needs to be published now or later. Workflow once created needs to be published to be able to run it.

Click 'Yes' to publish the workflow or click 'Later' if you wish to publish it later.

7. Clicking 'Yes' to publish the Workflow, you are prompted to create a trigger event for this workflow.
​

8. Click 'Yes' to configure a trigger event for this workflow. Click here for detailed help on how to create a trigger event.

9. Once the trigger event is configured, the workflow is ready to use and it will start working the moment the trigger event occurs.
​

Note: A maximum of 2000 workflow definitions are allowed to be created on a single project or a single project template. This can include workflows of all types including files, forms and custom objects.