Workflow A Form Entry Between Users (Process Steps)

Often, a business process requires more than one person to complete it. In these scenarios, just capturing a Form entry is not enough: multiple users must review, approve, reject, or update it.

The Process Step field type found in the Form Designer enables these kinds of workflow cases, and mastering this field unlocks a host of mobile process options.

You can think of Process Step fields as "gates" between the various steps of your overall process as represented in a single Form's pages. Each time a user hits a Form page containing an incomplete Process Step, they cannot proceed to any Pages further in the Form - i.e., the Process Step will hide the rest of the Form away from them, acting like a "gate."

The best way to explain how to use the Process Step is to work through an example. For this recipe, we will work through an existing example app found in the Examples Catalog on the platform. Head over to the Examples Catalog (found under the App Builder menu), look for the example named "Asset Check Process" and install it now. The Asset Check Process example assumes the following business process:

A field worker goes out to physically inspect critical machinery assets.
The logs of this checkup must be reviewed by a supervisor to ensure all required aspects have been correctly captured.
If the supervisor finds a capturing error or needs more detail, they will reject the checkup and send it back to the original field worker for rectification. Otherwise, they approve the checkup logs and sign it off.

This scenario involves two key steps in the process:

The field worker submitting the check log for review
The supervisor accepting or rejecting the log

We can represent this in a high-level Form flow as follows:

field worker page(s) | supervisor page(s) | end form or go back to field worker

where the "|" above will be where our Process Step fields are placed.

The field worker page(s) will have a Process Step field on the final page in that set, and the supervisor page(s) will similarly end with a Process Step.

Let's get into the example.

1. Open the Asset Check Process design in the Form Designer. You will see the "Confirm ready to review" Process Step field (dataname: step1). Note also the fields named "Send to Reviewer" (dataname: reviewTo) and "Any comments..." (dataname: reviewComments):

2. Click on the "Confirm Ready" field to view the field's properties on the right hand side:

Here's what the app will do when the field worker user hits this Process Step in the Form:

The user will not be able to proceed past the page containing the incomplete Step. This is what we mean by Process Steps acting as "gates": users cannot go further in the form when they hit an incomplete Step.
The user will have to confirm the Step by pressing the "Ready To Review" button that appears in the Form page. If they move forward in the Form they would hit the standard Upload Form page. We could, of course, put a User Action field underneath the Process Step field, with an interaction of "Upload Form" if you wanted to shortcut the user having to go forward to get the standard upload page.
When the Form is uploaded, the platform will see that a "Next Process Step" is configured on the step1 field. This triggers the platform to create and send a Task to the supervisor user identified by the email address found in the "Send Form To" property. In our case, the email address of the target supervisor user is retrieved from the ReviewTo choices field seen earlier.
The Task created will have the title as set out by the "Task Description" property. Note that you can embed values from other form fields into the Task title using our standard {{dataname}} syntax.
The Task will have a due date automatically set according to the current date/time + the number of days set in the "Complete By" property.
The Task's additional information field will contain any text entered by the user into the reviewComments text field.

3. Click on the reviewTo and the reviewComments fields and take a look at their Visibility properties. Once the step1 field is complete, the reviewTo field is be hidden due to its formula, which requires that the current Step be the step1 field. The reviewComments field will display only once the step1 field is tapped by the user, and thereafter as well - i.e., once the step1 field has a value in it.

The Visibility properties make use of some of the Process Step-specific formula functions available for you to use. Launch the Formula Builder from a property - i.e., click on the little "hammer" icon that appears next to these properties. If the Formula Builder, you can see these Process Step functions in the functions drop down list. Mouse over each function to see help text about each one:

4. Now head over to the second page (dataname: reviewPg) in the Asset Check Process design. You should see a Process Step field titled "Approve or Reject this Check?" (dataname: step2), along with rejectReason and acceptSign fields below.

5. Click on the "Approve or Reject" field and take a look at its properties on the right hand side.

Click on result 1 (the green box) and then on result 2 (red box) and notice the differences in property values between the result options.

Here's how the app will behave for the supervisor following the field worker uploading an Asset Check Form:

The supervisor user will receive a review Task and open the Form entry attached. They will be able to see the first page and information filled out by the field worker. The step1 field will not be editable since it is already locked by the field worker completing that step. Because step1 is complete, the supervisor will be able to reach the second page (dataname: reviewPg). Here they will hit the second Process Step field - "Approve or Reject?".
If the supervisor chooses Approve, then they can continue on to "Upload Form" page. On upload, the form entry is finished and the process is complete. This is driven by step2's Result 1 option - the "Approve" case. We can see this outcome has a blank "Next Process Step" - i.e., there are no further steps in the process once approval is given.
The acceptSign field will display if the supervisor selects the "Approve" button in the app. This is due to the acceptSign field in the Form design having a Visibility formula that hides the field unless the step2 field is set to a value of "Approve" (which occurs if the supervisor selects the "Approve" result).
If the supervisor chooses "Reject," they can continue on to the "Upload Form" page.
The rejectReason field will display if the supervisor selects the "Reject" button on the app. Similar to the acceptSign field, this is driven by the Visibility formula assigned to the rejectReason field.
On upload, the form entry will be send back as a Task to the original field worker who completed step1. This is driven by the step2's Result 2 option - the "Reject" case. We can see that the "Send Form To" property uses the STEP-EMAIL() formula to extract the email address of the user who completed step1.
The reject Task will have title and addition information as configured in the step2 properties. Additionally the step1 field on the form entry will be unlocked / reset to an incomplete status. So when the field worker opens the reject Task and enters the Form entry, they will be gated back at the first page by the incomplete step1.

Your next action from here should be to try out the Asset Check Process example for yourself. Run the form on your device and send the review to yourself. Before you do so, make sure that you update the "Users Example" data source that is attached to the reviewTo choices field. You need to add your own user email address to the data source so that you can select yourself from the choices field displayed under "Send Review To" on the app.

When you build your own processes in a Form, start with just a single Process Step first. Then you can add more Steps progressively, which should make testing easier.

Tips & Tricks
Connector Run Conditions
You may not want your form connectors to fire until the workflow reaches a certain point, such as approval by a second party. In order to accomplish this, you can "Add a Run Condition" on your connector, such as:

{{Step2}} = 'Approved'

This will keep the connector to the email, database, SharePoint or otherwise from running until that condition is met. This will avoid data being sent via connectors (especially emails) every time a task is sent between parties, allowing for only one connector submission once the task is complete.

How to make previously-entered step fields read-only
With Process Steps, we don't apply any edit prevention by default. However, you can set this up as desired by defining Read Only Conditions on the relevant fields. So, for example, if a field is not allowed to be edited AFTER completing a Process Step named "step1", then you would set the Read Only Condition on the field to be: ISBLANK(STEP-CURRENT()) OR NOT(STEP-CURRENT() = 'step1')

The ISBLANK() piece above is to cater for the situation where no steps have been completed yet - i.e., this is the initial creation/entry of the Form. If the target field's editable state relates to a step beyond the first in your Form design, then the ISBLANK() is not needed.

*IF YOU HAVE TABBED PAGES TURNED ON, READ BELOW*

If your forms use 'tabs', then steps on following pages (i.e., step 2 is on page 2) can be accessed by the user. However, there is a method of hiding process steps preferred by clients:

To prevent subsequent steps from being viewed or entered, you can use a visibility control to check whether the last step has been completed. This method uses the new step completed function: STEP-COMPLETED()= 'step1'. This will successfully hide Step 2 (and any other fields related to Step 2), until the task is assigned and started.

Sync Times
There may be times when receiving the next task in a workflow is not instantaneous. A workflow requires a server update; if the user's device completes its sync process before the server was able to complete the task, another connection will need to be made, Because everything has to be queued, the server may have been busy at the time a task was submitted, with the user's submission being next in line for processing.

How to skip process steps in-app

One of the features of our Screen Title Bar is that you can configure your app to display tabs for each page in your app, which can be useful for providing easier navigation on multi-page forms.

As soon as you select "Display Pages as Tabs", you will be able to set the option to "Only Display Tabes to Current Step".

If the "Only Display Tabs to Current Step" option is enabled, then only tabs up to the page containing the current process step will be displayed.

If the option to "Only Display Tabs to Current Step" is NOT selected, then that means that tabs for all pages will be shown regardless of the current process step and, in this way, users will be able to skip process steps.

English