Blog Posts Business Management Process Management

Business Rules

Blog: Comidor Blog

Comidor offers a variety of features in order to apply business rules in processes and custom apps to cover any possible scenario and enhance the capabilities of your apps and workflows.

In particular, you can include the following business rules:

Gateways
Conditional Flow
Field rules
Field Validations
Shell commands
Scripts before save

Gateways

One of the business rules is the Gateways in a workflow.

A gateway is used to determine the branching, forking, merging, and joining of paths drawn by sequence flow. In Comidor we have Exclusive, Inclusive, and Parallel gateways.

Workflow design | Comidor Platform

Inclusive (OR) Gateway: Inclusive Gateway refers to activating one or more flows when dividing. For incoming, all paths may be taken/fulfilled, from one to all.
Parallel (AND) Gateway (Fork/Join): Parallel Gateway refers to dividing into two or more flows (fork). For incoming flows, the parallel gateway will wait for all incoming flows before continuing (join).
Exclusive (XOR) Gateway: Exclusive Gateway refers to choosing “either/or” and will limit the outcome to exactly one single flow of the output branches.

Conditional Flow

Through Conditional Flows, you can connect your workflow elements (activities, gateways, or events) and design any possible/desired alternative path. For example, once a Task is created you should connect it with the previous element with a Conditional Flow. In the conditional flow form:

Drag and drop a conditional flow from a Start Event to an Activity and select the Target State, which is the initial state of the target activity (state can be Scheduled or Running). Type a brief description of the conditional flow that will help users in understanding this part of the workflow.
Drag-and-drop a conditional flow from an Activity/Gateway and select the Source State and Target State, which are the trigger state (can be completed/failed/cancelled) and impact state (can be scheduled/running/paused/completed/cancelled/failed), respectively.
Conditions can be added in both cases from the Advanced Conditions tab/Custom condition builder. Add further conditions through custom condition builder using either database system fields or any custom user fields you have created in User fields and have added in a User form.
In more complicated workflows, there might be a need to combine and use more complex Advanced conditions. In these cases, the workflow will check more conditions as you can see below. Click on icons “<“,”>” to add parenthesis before or after the condition you want, and select AND, OR between the conditions in each case accordingly. With the “+” and “-” button you can add or delete a condition.

Workflow conditions | Comidor Platform

Once the above step(s) have been completed, a conditional flow with your brief description will be added to your workflow design between the standard start event and the task you have created or between activities/gates.

Diamonds in the conditional flow refer to Source state and arrows to Target State, blue: Running, green: Completed, black/white: Canceled, red: Failed, grey: Scheduled, orange: Paused.

Field Rules

Another type of business rule is available both in workflows & app designer, for process and non-process enabled apps.

The field rules functionality enables you to hide or show fields inside forms when certain conditions are met.

Create custom condition scenarios for fields and select in which scenario the fields are going to be shown or hidden.
Select more than one scenario – field condition for a specific field. This enables you to cover multiple scenarios.
Eliminate the number of forms that need to be created and make your adjustments to one simple form.
Hide sensitive information which should be displayed only for certain users, roles, or groups in a workflow.

To access Field Rules go to the App Factory icon > Workflow Automation > Workflows. Access the Workflow you are working on and select the tab Field Rules.

Create Field Rules

To create a new Field Rule press on the “+” button, and a creation form opens.

Give a Rule title
Select the Action to be performed: you can either Hide or Show a field
Choose the name of the User Field that you wish to perform the above action to
Set in which Form you wish this rule to be applied (from the user forms that the selected field is displayed)
Select the desired Save option (refer to Quick Reference Guide)

Custom Condition Builder

After saving the Field Rule, and while being at the view form, you can add conditions.

Click on the ‘+’ icon to insert a new row
Select the unit that the field comes from (Process, Application name, etc.)
Choose the Name of the Field and its value
Use AND, OR, and parenthesis to form your conditions
After adding all the rows of conditions you need, click on the Publish condition button.

Manage Field Rules

If you want to make any changes to a Field Rule, simply select the respective Field Rule and click on the pencil icon.
After making any changes click on Save.
In order to change the conditions, simply make the changes you wish in the view form of the Field Rule, and then, press the Publish condition.
You can Delete one or more Field Rules, by multi-checking them in the Field Rules table and then clicking on Delete.

Field Validation

This kind of business rule can be applied both to process-enabled and non-process-enabled apps.

In the form designer, you can set desired properties to each user field:

The value on the “Pattern” field should be a “Regular Expression” in order to validate the input data on the field. The “Pattern Error Message” field is the custom error message that should be displayed if the validation fails.

Links for creating and testing “Regular Expressions”: https://regexr.com/ and https://www.regular-expressions.info/

Here are some examples of “Regular Expressions”:

To search for an email address: b[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,}b
For an email field with the option to leave the field empty: ^$|^([a-zA-Z0-9_-.]+)@([a-zA-Z0-9_-.]+).([a-zA-Z]{2,5})$
For a text field with only alphabetical characters: ^[a-zA-Z ]*$
For a numeric field having only digits: ^[0-9]+$
For a numeric field with only 3 digits between 1 to 9: [1-9]dd
For an integer number that can be negative and has a maximum of 10 digits: ^s*-?[0-9]{1,10}s*$
For allowing the field to remain empty use this string : ^$| and then use the correct pattern.
- Note: In a non-mandatory field with a pattern, if the pattern is not set to allow the field to be left blank, the “Pattern Error Message” will be displayed.
Pattern for Greek IBAN:^GRd{9}[0-9A-Z]{16}$ (you can find IBAN patterns in this link)

Additionally, you can hide user fields if their value is not set, or only when they have value – depending on your scenario. Choose the respective option in your form.

Shell Command & Script before save

You can add scripts to a workflow design within forms to the “script before save” section and/or to the Shell Command component of the workflow design.

Scripts can also be added in form of non-process enabled apps in the app builder.

When adding a Shell Command you can define:

The Title is one of the required fields.
The Parent Stage is the stage of the parent process as soon as this step is reached.
The Shell Type, selecting between Unix (sh), Windows (cmd), Windows (Powershell), Platon script, Sikuli script.
The Shell Script Variables by giving the Key, the Field (Runtime value), and its Value.
Tip: By clicking on the “+” button you can add as many keys as required or needed.
The Shell Script Body text.
The Shell Response.

If you add a script within forms to the “script before save” section, the script will run after the user saves the form/completes a task with this form.

We commonly add a “script before save” to check the user’s input and populate error messages. For example, we can include if statements to check the values of fields, assign values to fields, and many more.