Chapter 3 - Workflow steps

A Central Flows workflow is a list of steps (the statuses a form goes through) and, for each step, the action buttons that move the form to the next step and assign it to the next person. You define them per form template in the Central Flows Config form, without changing the template. This chapter uses a bug-tracking form as the example; Chapter 2 must be done first.

3.1 Open the Config form

1. Open a form of your template in FormsViewer (for example Open from the FormsDesigner menu, or a new form from the template list).
2. In the workflow task pane on the right, click the gear icon at the top right.
3. The Central Flows Config form opens for this template. Its tabs are Approvals (the workflow steps), ProxyList, Admins and Custom Data. This chapter covers Approvals; proxies and admins are in Chapter 6.

The Approvals tab has two layouts: a table, and a card layout that shows each button as a card. Switch with the right-most button at the top of the Config form. Both edit the same steps.

3.2 How steps and buttons work

• A step is a status name, such as New, Active or Resolved. A new form starts in the step New.
• Each step has one or more action buttons. When a form is in a step, its assignee sees that step's buttons in the task pane.
• Each button has these settings:

Clicking a button saves the form, moves it to the next step, assigns it, records the action in the history and, by default, e-mails the new assignee.

3.3 Assignee types

An XPath assignee lets the person filling in the form choose who handles it: the workflow follows whatever the field contains.

3.4 Build the steps

1. On the Approvals tab, the first step section is Step: New with one empty button row. Fill in the first button.
2. Click + Action to add another button to the same step.
3. Click + New Step to add a step, and type its name in the Step box.
4. Use Delete Step to remove a step.
5. Click the Save icon at the top right of the Config form.

Example: a bug-tracking workflow with four steps.

A new bug is assigned to the developer named in the form when it is opened, goes back to the person who reported it when it is resolved, and can be reopened at any time.

3.5 Conditional buttons

Give two buttons the same label and different conditions to send the form to different places depending on its data. For example, expense reports up to 100 are approved at once, larger ones go to the manager:

In the card layout, click + Condition on a card and enter the XPath expression. Make sure that exactly one condition is true for any data, so that the button always has one destination.

3.6 What happens when a button is clicked

The workflow buttons already contain the usual submit checks, so you do not need your own Submit button:

• Validate and Stop if Errors run the form's validation and stop if anything fails.
• Require Comment and Require Approver check that a comment and an approver are given where the step needs them.
• The form is then submitted (to SharePoint or DBXL, Chapter 2, section 2.7) and closed.

If you are adding Central Flows to a form that already had a Submit button, move the button's own logic and then delete the button:

• Rules that set values before submitting (for example a case number, or the file name) go to v2_XtpLogic_CentralFlows > XtpLogic > Actions > Submit: select the node, click Rules and paste or add them there.
• The name of the task (shown in e-mails and on the dashboard) is Tasks_FormName, under Main > myFields > QdCentralFlows > SubDocuments > qdxtp_Tasks > Content > CentralFlowsTasks. Set it in the same rule. The rule runs in the XTP's data source, so refer to main fields through the main DOM, for example concat(xdXDocument:get-DOM()/my:myFields/my:Category, "-", xdXDocument:get-DOM()/my:myFields/my:CaseID).
• Validation rules need no change: the workflow buttons run them.
• Because the form closes after a workflow action, a success message shown by your old Submit rules is not seen. To show a message, use the XTP's toast command in a rule, for example "CustomPromptToast /title=Success /text=Your form was submitted. /type=success" (/type=error for an error).

3.7 Keep form fields in step with the workflow

The workflow status lives in Central Flows. If your form has its own fields that should follow it, such as a Status field, a resolved date or the name of the person who closed the case, set them with rules on the workflow button:

1. On the canvas, select the workflow button in the task pane and click Rules.
2. Add an action rule, for example Update Status Field, with the condition Action is not equal to Save, and the action Set a field value: your Status field = WorkflowSteps_CentralFlows > WorkflowSteps > Rows > row > NextStatus.
3. Add rules for the milestones you track, for example Action is equal to Resolve: set ResolvedDate to now(), and ResolvedBy to the current user's e-mail (v2_XtpLogic_CentralFlows > XtpLogic > Actions > SetCurrentUser > @email).
4. Move these rules so that they run after Stop if No Workflow Step Applies and before Set Task Values in Main DS.

Action is the label of the clicked button, so the conditions use the labels from the Config form.

3.8 Test the workflow

1. Save the template and open a new form. The task pane shows Status: New and the buttons of the New step.
2. Fill in the form and click a button. The assignee receives an e-mail with a link to the form.
3. Open the form from the link: the status and the buttons are those of the next step.
4. Click the history icon in the footer to see each transition with its user, time and assignee.
5. If something does not happen as expected, click the Solution Version text in the footer. A debug panel opens with the qRules commands the workflow ran and their results.

For help, active customers can use the Customer Support Portal. For anything else, use Contact Us or e-mail [email protected].

Next: Chapter 4 - E-mail notifications