Workflow A Form Entry Between Users (Process Steps)

Often a business process will require more than one person to be involved to get the job done.

For these scenarios, just capturing a Form entry is not enough, you need that entry to be reviewed, approved, rejected or further updated by multiple users.

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 will not be able to proceed forward 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 Cataloge on the platform.

The Asset Check Process example assumes the following business process:

-  A field worker goes out to physically inspect key machinery assets.

- The logs of this checkup needs to then 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:

1. The field worker submitting the check log for review

2. 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:

i.) 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.

ii.) The user will have to confirm the Step by pressing the "Ready To Review" button that appears in the Form page.

iii.) 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.

iv.) 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.

v.) 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.

vii.) 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.

viii.) 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 it's 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:

i.) The supervisor user will receive a review Task and they'll open the Form entry attached.

ii.) 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?".

iii.) 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.

iv.) 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).

v.) If the supervisor chooses "Reject", they can continue on to the "Upload Form" page.

vi.) The rejectReason field will display if the supervisor selects the "Reject" button on the app.

Similarly to the acceptSign field, this is driven by the Visibility formula assigned to the rejectReason field.

vii.) 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.

viii.) 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.

Whew!

That's a lot to take in!

At this stage hopefully you have a better idea of how to use Process Steps, and with luck some cool possibilities are now starting to form in your imagination :-)

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

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 - e.g. 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.

Running Form Connectors only on certain Steps in your process

• A current Step will be considered complete as soon as the app user uploads the Form entry.
  As such the current Step will always be complete BEFORE connectors run.
  
  
• Any connectors that you want to run on specific Steps should have a "run condition" added.
  You do this via the "Add Run Condition" option found on most Form connectors.
• We recommend using STEP-COMPLETED() in your condition formula, though you can also use STEP-CURRENT() or STEP-ISCURRENT().
  The CURRENT formula functions will require you to specify the next step's name for accurate results.
  e.g. Only run Connector when "Step 1" is completed (and the process has moved to "Step 2"):
  STEP-COMPLETED() = 'Step 1'
  or
  STEP-CURRENT() = 'Step 2'
  or
  STEP-ISCURRENT('Step 2')