3 minute read
Decision Tables
The first feature in Madrid I am going to highlight is Decision Tables. These decision tables are a place to store the decision logic for variable situations. Each decision table record (sys_decision) handles a single decision. Related lists are the decision inputs (sys_decision_input) and decision (sys_decision_question) records. Each decision record contains an answer.
Our example will be for routing after hours service calls. We take multiple inputs in the form of location, time of submission, and the service. Each of these inputs can have conditions placed on them, to limit when and how the decision table record is invoked. Additionally, these records contain an order which is essential when trying to reduce the possible matches. Pick the input with conditions that will limit the possible matches the quickest to keep your system responsive.
The decision input record can be of any base system type. Reference, string, true/false and much more! These records do not contain a lot of fields. A type, label, column name, and active are the fields you mostly need to be concerned with.
You may need to define choices for some record types in the choice related list.
The Decision record is also quite light on required fields. Here is where you define the condition logic to denote if the combination of inputs will match this decision, and which answer will be returned. Order on these records is significant when using the first decision that matches logic option. Decisions can share answer records (decision_answer). These answer records contain nothing more than a string field for the answer output.
Now we will look at how to use the decision table records we have built. In Madrid Flow Designer is the only place that takes advantage of the decision table. Let us dive right in an show how these work in flows. Once you are ready, you pick new action. Then, you can see the new flow logic available in Madrid which includes ‘Make a decision’.
Once you select that option, you pick which decision table record. The execution choice here is where order becomes very important.
Under each decision, I can now execute different logic. This separation of how to make the decision and the business process allows for more flexibility in adjusting to changing scenarios. I don’t have to change my flow and business logic if I need to decide to change the after-hours support from 8 am to 7 am, I edit the conditions in the decision. The business logic and process in flow designer does not have to be adjusted.
These decision tables are going to allow more customers the ability to separate and adjust decisions from the business logic that is acting upon those decisions. We will see more on decision tables and their uses in further Madrid flow designer blog entries. Have fun deciding!
Share this post
Twitter
Facebook
Reddit
LinkedIn
Email