A quick example

The fastest way to understand how rules work is by example.

Let’s say we’re working at a software company and have a few automations on Zapier that help us engage prospects that sign up on our website, follow up with them as potential customers, and add them to our CRM, and we’re looking to start scoring these prospects so we have a better understanding of which are more likely to convert and actually provide us with their business.

Our ideal customer could be anyone, but for the purposes of this example let’s say we’re looking specifically for startups in financial technology– these are the people most likely to buy our software. From some form responses and lead enrichment technologies, we have a bunch of data on each prospect, and we mainly need to look for industry and company size matches.

There might be some exceptions here, however– if someone from a particularly big company reaches out, we’ll probably at least want to talk with them to understand their needs, so we can score them highly. And our market might be local to the US, so we might like that as well.

From what we’ve written down so far, a decision table to score leads for our business might look like the following:

Conditions

Results

Unpacking this is quite straightforward–

Using our data on a prospect, we can identify if they meet all the conditions in a row, from top to bottom. If we have a large US fintech that’s recently reached out, we’d find they meet all the conditions in the second row and stop there.

We then look at the results table for that particular row– any values in the second row of the results table are our output and returned as results of this decision. The decision table above only has one column, so only the number 90 for the score is returned, but we could easily modify it to return other information along with this as well.

All the “Any” values at the bottom of the table are our catch-all, as we’ll want to return something if none of the rows match our data. In Rulebricks, you’re able to simply provide default values that help eliminate some of the need to explicitly define these rows everywhere.

What this actually looks like

Decision tables are fairly simple conceptually, and can be straightforward enough to set up on Rulebricks, but how do they interact with real world data? The decision above requires a Request Object to configure, and return a Result Object, further discussed in the next section, and previewed below.

Request Object

{
	"industry": "Financial technology",
	"company_size": 4400,
	"location": {
		"city": "San Francisco",
		"state": "California",
		"country": "United States"
	},
	"date_form_completed": "2022-11-23"
}

Result Object

{
	"score": 90
}

<aside> 🛠 If you look closely, you’ll notice some details that make this decision possible that aren’t obvious– the data is not exactly what we represented it in the decision table, and the date is just text, so it’s not immediately clear how to set up a condition for that.

Here we can start seeing a few of the logistics around defining rules that Rulebricks can make particularly easy.

</aside>