It is common that as we build a system to automatically replicate what an intelligent person does, we discover that aspects of your business logic were not disclosed.
But they only become clear as we try and codify (i.e. make explicit) the logic in order to automate it.
Don’t worry – it’s normal to discover things as we go ... we call it emerging logic. It happens and is a natural part of automating a business.
Worked example of emerging logic
You might have told us you needed an if this then that workflow (a TRIGGER then ACTION type of thing). For instance: When a web form is submitted (TRIGGER) create deal in CRM (ACTION), i.e.
if TRIGGER then ACTION
But now you see that automation working, you realise it wasn’t as simple as that: There are actually multiple outcomes you might need depending on some other conditions (VARIABLES). So you actually need something like this:
if TRIGGER (and VARIABLE A) then ACTION A
if TRIGGER (and VARIABLE B) then ACTION B
if TRIGGER (and VARIABLE A & VARIABLE B) then ACTION C
So now you realise that you need it to do something that it’s not currently built to do. OK, let’s see what we can do about that:
1. Hardcode additional ‘branches’
So we could edit your automation to ‘hard code’ in three branches to handle each combination of your variables. In Zapier this will be three ‘paths’ in Make, three ‘branches’ based on router modules.
This works fine for the variable combinations you know about now... but if something changes, you’ll need to edit your hardcoded branches – perhaps needing to call us or another specialist. If nothing is going to change, then go with this option. But if you may need to ‘flex’ read on...
2. Build in flexible logic
But then what if one day you realise that it’s too rigid to only have three branches, and you actually don’t know how many you will need? Maybe you need to temporarily change what happens when VARIABLE A because someone who normally deals with those deals are on holiday?
That’s when you need ‘flexible middle’ logic, commonly it will work exactly like a ‘lookup’ function in an excel spreadsheet. We will provide you with a dedicated space to manage some ‘matching’ logic, and then build your automation to stop by at this dataset to follow your instructions on how to proceed with later stages of the workflow.
🚥 Flexible logic
For example, what if you wanted to be able to dynamically choose a colleague to assign a new CRM deal to, based on a form field such as Country of Residence of the prospect?
People come and go, so you need to make sure you can change this at any point without rug-pulling your tech. The goal is to avoid hardcoding that person’s email anywhere in your automations.
We can handle that matching logic in a tool like Airtable or Coda (this page is a Coda doc)
You have one table called countries and one of sales associates. In the countries table (see below) you have a relationship to the sales associates table, allowing you to pick the right person to handle leads from that country.
In the same way you can select a country below and see the relevant sales associate, so to will your automation if we construct it with flexible logic.