Rules, Filters, and Boolean Logic

Text version:

Introduction

A fundamental part of designing any application is the logic that governs the behaviour of the systems. The joy of doing this in a no-code platform is that much of the work is done automatically – you just need to define the rule and the platform will create the process that drives it.

For Intelastel you will need to apply this to three areas of your application design:

Fortunately these are all governed by the same kind of logic, which is called Boolean logic.

You may be familiar with Boolean logic from using Excel.

Regardless, this guide will cover the basic concepts with relation to your no-code application design.

Definition:

Boolean logic is just a logic system named after the philosopher and mathematician Charles Boole. If you want to impress your friends with the formal term, it is also known as Zeroth order predicate logic.

It is not code.

To put this in lay terms, the logic you use to design your application should always be formatted as statements, which, when queried by the system, will be answered with either TRUE or FALSE. These are called ‘IF statements‘.

IF statements are analysed by the software to form rules. They use operators – you will be familiar with mathematical operators (plus, minus, times, divided by).

For the basics of Boolean logic they are as follows:

AND – If x AND y is TRUE then…
OR – If x OR y is TRUE then…
NOT – If x but NOT y is TRUE then…

Almost any process can be described using a combination of these operators and statements.

Having an understanding of this will help you streamline the design of your system (the underlying processes that drive your application), and make designing your application features and functions more robust.

Example:

Here’s a simple example; a set of rules, and the input, process, and output. Imagine asking an employee if they are hungry:

RULES:
IF HUNGRY = TRUE THEN GO GET LUNCH
IF HUNGRY = FALSE THEN GO BACK TO WORK
WHERE YES = TRUE
WHERE NO = FALSE

Here we have mapped the values of True and False to ‘Yes’ and ‘No’ respectively – mapping just means to create a direct relationship between two entities. You may well be familiar with mapping if you have explored any of the Integromat scenarios – see our Getting Started With Integromat guide for more examples.

Query: Are you hungry?
Input: “Yes”
Output: Go get lunch!

Method:

1. Knowing how your business processes work, write down the functions needed for your no-code application.
2. Translate the requirements for these into IF statements.
3. Write these down.
4. Arrange the statements into dependency order – work which statements must come before others.
5. Create rules, filters and Integromat scenarios based on these statements.

Example:

Your business sells cars. You have two showrooms, one for new cars, one for used cars. You want to automate parking space allocation.

You could write this requirement as the following statements:

IF any given car is ‘new’ THEN it should be sent to ‘Showroom A’.
IF any given car is ‘used’ THEN it should be sent to ‘Showroom B’.
IF a car’s status is known THEN it should be sent to the appropriate showroom.

As with everything related to application design, these processes are based on input, process, and output.

• The inputs are queries about your statements.
• The processes are the rules based on your statements.
• The outputs are the results based on your rules.

Advanced:

For situations with multiple outcomes, you will need to create nested rules.

These are just a combination of IF statements and operators.

You will need to decide on the order of dependency – which statement must be analysed first in order to determine the flow of the logic, and which operators to use.

Look at a simple example:

Query: Do I need to put my umbrella up?

Let’s make some assumptions to simplify the example:

• Assume that umbrellas exist, and the person making the query has an umbrella.
• Assume that an umbrella should only be deployed when outdoors.
• Assume that an umbrella is only deployed when it is raining.
• There are countless other assumptions but we can ignore them for the sake of brevity.

First, we need to analyse this query and turn it into something a robot would understand:

(IF the user is outdoors) (AND) (IF it is raining) (THEN an umbrella should be deployed)

This query relies on two IF statements: the position of the person making the query; and whether it is raining.

It uses the AND operator to combine the statements.

Now look at the available combinations:

AM I OUTDOORS? TRUE/FALSE
AND
IS IT RAINING? TRUE/FALSE

We can put these into a table:

IS OUTDOORS?	IS RAINING?	UMBRELLA DEPLOYED?
TRUE	TRUE	YES
TRUE	FALSE	NO
FALSE	TRUE	NO
FALSE	FALSE	NO

The formal name for this is a Truth Table.

As you can see, there is only one outcome where the umbrella will be deployed, but you must design rules for every outcome to be covered.

The same applies to all logic you use for your application design – design your solutions so that all possible permutations are covered by one of your outcomes.

Hint

To determine the logical structure for a given business rule, just work backwards.

This is to say, take the process you wish to add to your application, and start with the results you wish to see.

Call these your outcomes.

Try to split your outcomes into unique categories, based on a common set of rules.

Take each rule and analyse it as a statement – if you can apply the statement to the given situation, then label it as TRUE. Inversely, if the statement cannot be applied then a FALSE value should be returned.

Uses

Using a combination of Integromat Router modules and IF statements in filters, you can build powerful logic engines to reliably automate your business processes.

Intelastel configuration

Inputs:
An attribute field in an entity can be a Boolean value: This must be a true or false value.
In the UI (the user interface) the user sees a checkbox which can be toggled to indicate true/false.
‘Yes‘ is always mapped to TRUE.
‘No‘ is always mapped to FALSE.

You have the option to define the UI labels here as well – for example, you could map the TRUE outcome to display ‘Correct’, and the FALSE outcome to display ‘Incorrect’ for an online quiz.

Outputs:
Records that use the Boolean field will display with the UI labels you set in the section above.

Integromat example scenario

Single rule filter:
Here we have used a Router module to process the logic. Based on the input, the Integromat scenario will check each rule (applied as a filter), and route the data to the appropriate module.

Any link between two modules can have a filter applied in Integromat.

There are many filters to choose from – see the Integromat documentation for more information, but the ‘Condition X’ Equal to ‘True‘ filter is of interest here. Use it to define your rule:

Here’s a scenario which contains a nested rule:

Note: Integromat filters include more than just IF and AND functions – learning to use these to create your rules will be more efficient than creating chains of nested rules.

Primer:

A final word on nulls:

You should consider the possibility of a third variable in your design: Cases where the outcomes return neither true nor false. This is known as a Null value. To design a robust system, you should include filters to handle this.

The simplest way of achieving this is just to assume that every case that goes through your system will take one of the options by default.

For example, make it so your scenarios are always going to have True as the outcome unless the rules say otherwise.

In logic, these are called ELSE statements:

IF TRUE THEN DO THIS…
IF FALSE THEN DO THAT…
…ELSE TRUE

Example flow diagram where null values are handled as if they are always true