WorkPoint Automate - Step execution rules – Welcome! How can we help?

Before execution rules can be used to evaluate a condition before a given step is executed and perform a selected action based on the result of said evaluation. An example could be to skip a step if the value in a previous form was below a specific number. Another examples could be to evaluate a condition in the process and put it on hold based on the result. The user can then go back to a previous step and resolve whatever input resulted in the on-hold result.

Before execution rules can be illustrated in the following way:

Parallel execution rules

Parallel execution rules can be used to allow action steps to run parallel to other steps in the same process and to define steps dependent on the completion of the action. An example could be to start a step which creates a new entity with a site on a business module, but immediately continue to an item form, feeding it's data into another action step which creates the item on the new entity site. The create item step is dependent on the process first completing the create entity step, and can be defined as such on the Parallel execution rule on the Create entity step.

Parallel execution rules can be illustrated in the following way:

In this article we will go through how to configure the different types of step execution rules, as well as give a couple of examples of use.

Note that the Parallel execution rule type is only available from WorkPoint 365 version 4.7 onward.

2. Configuration

Step execution rules are configured in the "Rules" tab of WorkPoint Automate steps.

This tab always displays options for "Pre-evaluation title" and "Pre-evaluation message", as well as a button for configuring execution rules for the specific step:

WorkPoint Process Builder - Google Chrome

The pre-evaluation title and pre-evaluation message fields are always available in the "Rules" tab of any step. In these fields, you can type in a title and a descriptive message to indicate to users that this step has an execution condition, even before the step has been reached in the process. The title and the message are displayed when clicking the information-icon next to the step in the process overview when the process is run:

The pre-evaluation title and message are displayed in the information box before the rule has been evaluated. The system can be configured to display a different title and message after the step execution rule has been evaluated.

Clicking the "+ New configuration" button allows you to select which type of step execution rule you want to create on the current step:

Clicking either "Before execution" or "Parallel execution" adds that type of step execution rule to the step, which can then be further configured.

2.1. Disable context reload

The "Disable context reload" option is an optimization option which can help improve a process step's performance. Normally whenever a step is loaded in a process, it automatically reload the process context with the most up-to-date data, which can take a few seconds. However, in some cases, a certain step may not need the most up-to-date information from the context in order to perform.

The concept is outlined in the following image:

In this example, a process in initially loaded. A user then inputs some data into an entity form, which is passed on to an Update entity step. At this point, the process context is updated with new data for the entity. The next step, the custom form, has the "Disable context reload" option enabled. It will therefore not reload the context but instead use the original context data from when the process was initially loaded. This means that the custom form has access to the context data from the initial process loading, but not the most up-to-date data created by the Update entity step.

This results in improved performance of the process in general, and may provide a better user experience, at the cost of the custom form not having access to the most up-to-date data.

You can disable reload of the process context by enabling the following option in the "Rules" tab of any process step:

Note that the "Disable context reload" option is available on all steps.

2.2. Disable output data load

Sometimes WorkPoint Automate steps may send a lot of data along to subsequent steps, some of which is not necessary for the subsequent steps to perform their tasks.

If the "Disable output data load" toggle is enabled, the step will only send minimal data along to subsequent steps.

An example of use could be a process which creates a new project using a Create Entity. The next step in the process creates a new document on the project using a Create Item step. To create the new document, the Create Item step needs an ID reference to the new project, which it can get from the context. However, without the "Disable output data load" setting enabled, the Create Entity step will pass a lot of data long to the Create Item - much of which is not needed. This may result in a longer load time of the Create Item step than necessary.

In this example, perceived performance can be enhanced by enabling the "Disable output data load" setting, which will result in the Create Entity step only passing the WebUrl, ID, and List properties along to subsequent steps in the process.

2.3. Before execution rule configuration

When a Before execution step execution rule has been added, it can be configured as follows:

Clicking the header of the execution rule expands or collapses the rule options.
Clicking the recycle bin removes the specific Before execution rule.
The title of the execution rule is used for differentiating rules from one another and is not shown to the user.
In the "Action" field, you can select what the action of this rule should be. Options are:
- Skip: If the condition(s) of the rule is met, the step will be skipped.
- Hold: If the condition(s) of the rule is met, the step will display the text in the "Response title" and "Response message" to the user, and disallow them to continue. The user can click their way back to the previous step to resolve eventual issues.
- Cancel: If the condition(s) of the rule is met, the process status will be set to "Canceled". The user can close the process afterwards.
- Fail: If the condition(s) of the rule is met, the process status will be set to "Failed". The user can close the process afterwards.
In the "Condition(s)" field, you can configure one or more conditions for the execution rule. If these conditions are met, the action configured for the rule will be enforced. An example could be a condition which checks if a company being created is of a specific size, or a specific type. Depending on the evaluation outcome, the action of the rule can be enforced. Multiple conditions can be configured for each rule and joined using either AND or OR. To create or edit conditions, click the "Advanced" button.
In the "Response title" and "Response message" fields, you can type in a title and message which will be shown after the evaluation/enforcement of the execution rule. This message is shown both in the main section of the process (if process is canceled or failed), and in the information box in the process overview:

2.4. Parallel execution rule configuration

When a Parallel execution step execution rule has been added, it can be configured as follows:

Clicking the header of the execution rule expands or collapses the rule options.
Clicking the recycle bin removes the specific Before execution rule.
The title of the execution rule is used for differentiating rules from one another and is not shown to the user.
In the "Controller execution" field, you can select whether to execute the step action as a web job or as a separate thread by the WorkPoint API. This allows Parallel Processing to be executed not in a web job but within the API itself, in a separate thread (unless the action is set to async, such as the Convert Documents to PDF step using the async option, in which case it will still create a web job). This can e.g., be used for smaller parallel executions. For larger ones, one should avoid controller execution to prevent timeouts. If you expect the step action to take a while, you should select "No" to avoid Time-out errors.
In the "Dependent step" field, you can select a step later in the process which is dependent on the completion of the step on which this rule is configured. When the process reaches the dependent step, it will await completion of this step before processing.
In the "Condition(s)" field, you can configure one or more conditions for the execution rule. If these conditions are met, the action configured for the rule will be enforced. An example could be a condition which checks if a company being created is of a specific size, or a specific type. Depending on the evaluation outcome, the action of the rule can be enforced. Multiple conditions can be configured for each rule and joined using either AND or OR. To create or edit conditions, click the "Advanced" button.
In the "Response title" and "Response message" fields, you can type in a title and message which will be shown after the evaluation/enforcement of the execution rule. This message is shown both in the main section of the process (if process is canceled or failed), and in the information box in the process overview:

2.5. Disable interaction

The "Disable interaction" option in the Rules tab can be used to toggle whether the current step should show that it is running in the Process steps overview. This option is only relevant to the very first step of your WorkPoint Automate process.

The best way to understand this functionality is to think of a process which starts with an action step which does something, e.g., a Get Entity or a Send Http request step.

If "Disable interaction" is enabled, the process will load, and not display that the step is running. The step will still be executed but the process, once it is loaded, will appear to go directly from loading to the next step of the process where an input is needed (or the process is completed).

If "Disable interaction" is disabled, the process will load, and then display that the first step is running.

Examples of the behaviours can be seen in the following GIFs:

Disable interaction on:

Note that the process overview does not display that the first step is running, but appears to jump directly to the Entity form step. Also note that the Get entity steps are executed even though the overview does not show them running.

Disable interaction off:

Note that once the process is done loading, the first Get entity step appears to be running, then the next, and eventually it reaches the Entity form step.

3. Examples

3.1. Provide justification if high budget

3.1.1. Configuration

In this example we will use a "Before execution" rule to ensure that users creating a new project provide a budget justification if the budget exceeds a certain value.

For this purpose, in a process titled "New project", we will use an entity form in which users can provide project meta data. We will then use a custom form for providing a budget justification and a budget signee, but only if the budget is at or exceeds 25000. We will then finish the process off with a Create entity step which creates the final project entity and site.

Note that these steps will be titled "Project information", "Budget justification", and "Create project" in the process.

In the Entity form, titled "Project information", we are using the following options:

In the "Fields" tab, we have hidden the "Budget justification" and "Budget signee" fields, and made the "Budget" field required. The "Project ID" field is set to hidden because it is automatically generated by a Numerator Service:

In the Custom form, titled "Budget justification", we have created three custom fields; "Budget", "Budget justification", and "Budget signee":

The "Budget" field is a read-only field which displays the budget that was set in the Project information form. The "Budget justification" field is a "Note" field in which the user can provide a justification for the budget. The "Budget signee" is a User field in which the user can assign a person who has to sign off on the budget.

In the "Rules" tab of the Budget justification form we have configured the following options:

In the "Pre-evaluation title" and "Pre-evaluation" message fields we have types in some information about the check that is going to be made when moving to the Budget justification form. In this case, we inform the user that if the project's budget exceeds 25000, they will need to provide a justification.
We title the execution rule "Budget check".
In this instance, we want to skip the Budget justification form if the budget provided for the project is below 25000. We therefore select the "Skip" action.
In the "Condition(s)" section, we have configured the following condition:

In the condition we check if the number in the "wpBudget" field from the Project information form is less than 25000. This condition is represented in the execution rule as "ProjectInformationForm.wpBudget < 25000":

In the "Response title" and "Response message" fields we also provide some post-evaluation information about the execution rule.

3.1.2. Execution

When we execute the previously configured "New project" process, we first get the opportunity to input all necessary meta data for a new project:

If we click on the information icon next to the "Budget justification" step in the process overview, we see the Pre-execution title and message from the step execution on that step.
In the Project information form, we have input a budget of 50000. This number is of course larger than 25000, and will therefore require a budget justification.
To proceed, we click the "Continue" button.

Since the budget exceeds 25000, we are taken to the "Budget justification" step:

In the Budget justification form we type in a justification and assign a signee.
To proceed to the "Create project" step, we click "Continue".

Our project is now being created:

Once created, our project can be found in our Projects list:

anm0031 - Projects - All Items - Google Chrome

Let's create another project with a budget below 25000:

For this project, the budget is set to 10000.
To proceed, we click "Continue".

This time, the "Budget justification" step is skipped, and our project is simply created:

Note that after the Budget justification execution rule has been processed, the information pop-up now displays the response title and message from the execution rule.

3.2. Putting a process on hold

In this example, we will use the "Hold" action type for a step execution rule.

We will build upon the previous process example and use the "Hold" action so that users cannot create a new project with the name "MASTER". We will create a message for the user that that name is reserved (in this case for the master site of the Projects business module). The user will be able to return to the Entity form and use a different name for the project.

3.2.1. Configuration

As mentioned, we will build upon the previously configured "New project" process, specifically on the "Create project" step:

In the "Rules" tab of the "Create project" step, we type in a pre-evaluation title and message to display to the user before the step execution rule is evaluated. We inform the user that the title "MASTER" is reserved.
We then add a Before execution rule and title it "Check project title".
For "Action", we select "Hold". This action makes it possible for us to stop the user from creating the project and display a message to them. After this, they can return to a previous step.
Since we want the process step on hold if the user has selected the title "MASTER" for their project, we create the following conditions to check for that (note that we also check for lowercase spelling):

In the response title and message, we give the user some information about why the step is put on hold, should they have chosen the title "MASTER" or "master" for their project. In this case, we let them know that the title is reserved, and that they should try a different title for their project. Note that we are using the title provided in the "Project information" form in the response message.

With this configuration, users who use the "New project" process should be prevented from using the title "MASTER" or "master".

3.2.2. Execution

When we execute the previously configured "New project" process, we first get the opportunity to input all necessary meta data for a new project. In this case, we use the title "MASTER":

When we proceed to the "Create project" step, we are met with the following window:

The process is put on hold on the "Create project" step and in the information pop-up we can see the response title and message. In this case, the message informs us that the name "MASTER" is reserved and that we should try a different title for our project.
Next, let's click the "Go back" button.

We are returned to the Project information form in which we can type in a different title for the project. In this case, we select the title "Project Black".
We click "Continue" and try to create the project again.

This time the process succeeds:

And the project is created and available in our Projects list:

3.3. Project creation parallel with subsequent steps

Some actions in WorkPoint may take a while to complete. These could e.g., be entity creation or converting a big stack of documents into PDFs.

In this example, we will demonstrate how you can use a Parallel execution rule to run a given action step in parallel with subsequent steps of the process, which allows you to continue to said subsequent steps while the previous action step is still processing. This functionality can potentially increase efficiency while working with WorkPoint Automate processes.

We will use the following four types of steps in the process: an Entity form, a Create entity action step, a Custom form, and a Create item action step. In the process, these steps will be titled "Project information", "Create project", "Document options", and "Create document" respectively.

The process will be titled "Create project with document".

3.3.1. Configuration

In the Create project with document process, the Entity form options are configured as follows:

All other settings are left at their default values (except the title of the step).

The output from the Entity form is passed into the "Step Input" of the Create entity step:

and the step options are configured as follows:

In the "Rules" tab, we have configured the following options:

First, we have typed in a pre-evaluation title and message to let users know that this step will run in parallel with the subsequent custom form. Further down, we have defined a Parallel execution rule, which ensures that once this step starts processing, we immediately continue to the next step in the process (which in this case is the custom form).

In the rule, we have also defined a dependent step, the "Create document" step. This means that once we have completed the custom form and proceed to the "Create document" step, that step will hold and await completion of the Create entity action. In this case, this is necessary because we cannot create a document on an entity which has not completed creation of it's site yet (where would we put it?).

In this demonstration, we have not defined a condition for the rule, so it will run every time. We have also not typed in a response title or message, but these can be used to switch the pre-evaluation title and message out after execution of the rule to inform users.

Next, the Custom form is added to the process. This Custom form has a single text field for inputting a name used for the document being created in the next step:

Lastly, we use a Create item form to create a new document on the project also being created by this process:

The value from the text field on the Custom form is then used as name and title for the document created by the Create item step:

With these process and step configurations, we should be able to input meta data for a new project, then start creating the project, but at the same time, proceed to the form where we can input a name and title for the document we want to create, and lastly proceed to the Create item step, which creates the document as soon as the project creation has finished.

3.3.2. Execution

The execution of the process configured in the previous section is shown in the following GIF:

WorkPoint Automate - Step execution rules

Contents

1. Introduction