DecisionTable
Last updated
Last updated
Decision Table is apt when you have different outcome for different combo of conditions and want to create all outcomes in excel or table like view to edit / manage easily. In case of multiple matching rows, you can choose a policy to control how you want to run the rule.
In DecisionTable, you can determine when your rule should exit or continue, and how it presents the results. This documentation provides a step-by-step guide to help you understand and use DecisionTable effectively. Let's dive in and explore how to make the most of this powerful tool within Nected.
Creating a DecisionTable rule in Nected allows you to establish multiple conditions for your dataset. To get started, log in to Nected using your Email ID and password. Then follow these straightforward steps to create a DecisionTable rule:
After logging in, click on the "Rules" option in the left navigation panel. This will take you to the Rules page, where you can manage and create your rules.
Click the + Create Rule button, which will display a popup with two options:
Build your own
Start from template
Select Build your own to create a Decision Table from scratch:
Enter the Rule Name: Provide a concise, descriptive name that reflects the purpose of the Decision Table.
Provide a Rule Description (Optional): Add a brief description for context, useful for others or for future reference.
Select the Rule Type: Click on the Decision Table option. A Decision Table allows for the grouping of AND conditions and actions in a tabular format, suitable for handling complex scenarios where different actions are required for different conditions.
By choosing the right rule type, you can ensure that your decision-making process aligns with your specific use case. For more detailed information about each rule type and additional use cases they can address, please refer to the respective documentation links provided above.
In this step, you need to provide essential information for your DecisionTable rule, including:
Rule Name: Choose a unique and descriptive name for your DecisionTable rule. Ensure that the name is distinct throughout the Nected platform and does not contain spaces.
Rule Description: Write a meaningful description that clearly conveys the purpose and function of your DecisionTable rule.
Environment: Select either "Staging" or "Production" to determine the environment in which your DecisionTable rule will operate. Staging is a test environment where you can evaluate your rules before deploying them to production. Production is the live environment where your rules will be executed for your customers. By default, all new rules are created in staging.
Rule Policy: Your rule's policy defines how it will execute. Choose from four policy options:
First – The rule will exit after the first true value. For example, if you check for a BMW car of 2005 model in New York city in a table of cars, this policy will show only the first result even if the table has 5 entries that meet this condition.
Unique – The rule will exit after finding the first unique true value. For example, if you check for a BMW car of 2005 model in New York city in a table of cars, this policy will not show any result because the table has multiple entries that meet this condition, thus it does not have a unique entry.
Collect – The rule will collect all the true values. For example, if you check for a BMW car of 2005 model in New York city in a table of cars, this policy will show all 5 results in the exact same order as they are listed in the table.
Order – The rule will display all the true values in the ascending order. For example, if you check for a BMW car of 2005 model in New York city in a table of cars, this policy will show all 5 results in the ascending order.
Evaluate All - The rule will be executed anyhow even if the rules are not satisfied. The decision table result contains the output entries of all satisfied, unsatisfied and the rules with error in the order of the rule specified in the decision table.
These policies allow you to control the behavior of your DecisionTable rule and tailor it to your specific needs.
Before configuring a rule in Nected, determine the data source that the rule will utilize. Nected offers versatility in data source definition:
Direct Input Attributes: With Nected, you can designate custom attributes tailored to your rule. These act as dynamic values supplied alongside API parameters during rule execution. For example, for a discount rule, you might use parameters like "customer type" and "purchase amount." Such parameters offer on-the-fly adjustments when invoking the rule via an API.
Fetch from your Database via DataSet: If you have an existing database, Nected lets you extract parameters directly from it through a dataset. By choosing a dataset, you can refer to its attributes within your rule conditions. For instance, for a rule assessing discounts from a customer's purchase history, you might use a sales dataset to access attributes such as "customer ID" or "total amount".
Fetch from any internal/external API: Over Nected, you can integrate with any 3rd party API to fetch input attributes & data directly to be used in the Rule. For instance, you can fetch customer's KYC, credit history or purchase data with your vendor, and you want to use those data points as well as in your business logic.
Combination of All: Merging custom input parameters with a dataset as well as API is the optimal method. It harnesses your dataset's structured data, let you combine 3rd party data but then also allows for specific parameter overrides when executing the rule. In the discount rule context, this means leveraging dataset information for general trends, while also accommodating unique discounts or promotions via custom parameters.
The right data source setup empowers your rules to span diverse scenarios, from utilizing historical data to making real-time adjustments based on distinct parameters.
Should you need attributes absent from your dataset, or if you prefer a dataset-independent rule relying solely on custom attributes, you can define these as per your rule's needs.
Just click on the "Add Input Attributes" Button and don't choose any dataset.
Click on +Add Field and type in Key Name and choose Primitive Data Type from the dropdown. You won't need any Data Mapping as this is not from any dataset. You can choose the configuration if the field can be null, should be compared in a case-sensitive manner, and/or if it is optional. Eg - For the loan approval example, you might create attributes like customer_id, customer_location and product_name.These attributes will be used in evaluating rule conditions.
You can add the below datatypes as input:
String: To add string value click on the dropdown list and select "String" from the given option. Then add the test value like this:
Numeric, Boolean: Similarly click on the dropdown button to select the respective datatype and then in the test value.
Date & DateTime: To add Date or DateTime, you can select the datatype from the dropdown list and then you can just add the test value like this:
JSON: To add JSON as input follow the guides here.
List: To add LIST as input follow the guides here.
Click on Save
To add a dataset as an input attribute you can follow the steps given below:
After opening the Input Attribute window, you need to add a new blank custom property from the first tab. For example: "DB_Data".
Then you need to click the second tab i.e. “Map with data source”. to map the new input attribute with your dataset.
Inside that tab, you can see a dropdown list called “Select Dataset”. To map your attribute with the dataset you can either select a prebuilt dataset from that dropdown list, or can create a new one.
To create a new dataset for your rule, you just need to click on + Create Data Source Button.
After Clicking this you will see lot of database connections options. Choose a database that you want to integrate it with the rule from the available dataset list i.e. MongoDB, MySql, PostgreSQL, Oracle, Redshift and so on.
Now, after selecting the database for your rule it will be redirected to the connector page, where you need to fill all the connector details. After filling all the connector details click on the Test Connection. and check if the connector is working properly or not i.e. credentials are correct for your connectors. And after that publish the connection in production by clicking on Publish in Production.
Now once you've successfully established connection, in order to fetch your data from database for the rule go to the Data sources page and then write query for the data you want to be fetched for your rule. Once you're done with writing the query, click on "Test Query" and test it thoroughly. After that publish the dataset and it is now ready to be fetched to your rule.
Now, to use it over your rule, just come back to your rule's “Map with Data Source” tab and press the refresh ↻ icon just below of Select Dataset. And you’ll be able to see the new dataset that you’ve created.
Now your dataset is available in the rule. To map click on +Add field and select the attribute(i.e. "DbData") that you’ve created in the “Input Attributes” tab and map it with the respective key from the dataset as the primary key.
Depending on what datatype you've selected for the custom attribute, you can only map those types of data of the dataset.
If you would type multiple data fields mapped, then the combo of all would be treated as the primary identifier.
If your dataset contains multiple versions and you want to map with a specific version, then select that version from the dropdown list as shown below:
You can also add REST API as an input attribute. To do so, you can follow the steps given below:
Then just click on the "+Add Input Attribute" and create a new input attribute, like "SampleAPI".
Inside the modal, fill up all your rest api connector details and then test the connection by clicking on 'Test Connection" button.
After testing the connection, click on "Publish in Staging" and then do the same thing in production. And then test the api connector in production as well and then publish it over production by clicking the "Publish in Production" button. And your API will now be ready for using inside the rule.
Once done, just simply click the "Fetch Input Attribute via API" button to fetch the API data. And now you're ready to use the API data inside your rule condition as well as in rule result.
In this step, you will need to define a decision condition. The decision condition is a set of rules that you can use to make decisions.
In this step, you can configure the following rule properties:
Custom Functions: This is a JavaScript editor where you can write a JavaScript formula that includes attribute-based tokens to define conditions in the rule. Custom functions provide flexibility in specifying complex logic.
Input Attributes: Input attributes are the local attributes created for use within this rule. These attributes can be used in conditions and actions within the rule.
System Attributes: System attributes are provided by the system and are related to time and other system-related information.
NULL token: If you want to pass a NULL value in your rule condition, then you can select the NULL token inside the System Attribute.
{Dataset}: If you've selected a dataset as the source, you can use attributes from the dataset to form conditions within the rule. This allows you to leverage the data in your dataset for decision-making.
Conditions are the criteria that determine when the rule should take action. You can create conditions using a variety of operators. Nected supports the following types of operators:
Common/Generic: Any, Exists, Does Not Exist, Is Null, Not Null
Numeric Ops: Between, Not Between, Equals, Not Equals, Greater than, Less than etc.
String Ops: Equals, Not Equals, Contains, Does Not Contain, Starts With etc.
For more detail info about the operators, read this page Operators.
You can combine conditions using logical operators to form complex conditions. These logical operators include AND, OR, and NOT.
Now after defining the operators for each properies, you need to define the values for them. Values can mostly be constants or tokens of the same datatype as property.
To create a condition, you will need to specify the field that you want to evaluate, the operator, and the value. To create a group, you will need to click on the “+” button.
Unlike the SimpleRule, in the Decision Table you have only one logical operator i.e. “AND”.
To enable or disable any piece of condition, you just need to click the toggle button on the left side of a condition. Similarly, at the left side just beside the toggle button, there is a three dot drop down button. By clicking the drop down button you can
Add a new row above or below of that exact row.
Duplicate a condition
Delete the condition
Just below the condition table, there is a button “+Add additional Data”. Clicking this button will give you two options:
Formula: So, in the Formula editor you can run a custom formula and then you can use the output of the formula as additional data.
JS Code: In the Javascript editor, you can add custom javascript code and use the output as additional data as well.
You can add more information( static and tokenized) to customize your rule.
In this step, you need to define the results and actions of your DecisionTable rule. These results and actions are critical aspects of configuring your rule to make data-driven decisions. Here's how to do it:
When you add results, you specify the type of data you expect from the rule. DecisionTable rules support various result data types, including:
To add Rule Result follow these steps:
Go to the rule editor, and click + button on Result tab, and a dropdown will appear. From there choose the type of result you want to return when a specific condition met. Here are the types of data you can add: [Boolean, Numeric, String, Date, JSON, Custom JavaScript Formula]. The result will be denoted as key_name. Read Rule result, to know more about it.
After configuring the Rule result, test it and check if they're working properly or not.
Adding actions allows you to specify what your rule should do when its conditions are met. Nected provides a wide array of action options, each tailored to serve different purposes. These actions can include sending notifications, updating a database, triggering external processes, and more. You can
Database Operations: As a rule action, you can perform operations on a database, such as inserting, updating, or deleting records. This is valuable for keeping your data up-to-date.
Triggering REST API: Rules can trigger REST API calls, enabling interactions with external systems. This action can be customized to send specific payloads and parameters as needed.
Slack: You can add Slack as well as a rule action, to trigger some functions like sending notification or something else.
Google Sheet: Same as database, you can also trigger a google sheet, to do CRUD operations in the sheet or some other operations.
To add actions in rule, follow these steps:
In the rule editor, click on +Add Action button.
Then from the dropdown, select the specific type of action. And then configure your action. For more detailed guide follow the steps shown in Rule Action.
After configuring the Rule action, test it and check if they're working properly or not.
The choice of data type and action depends on the objectives of your rule. Consider your use case and desired outcomes to select the most appropriate options. For detailed information on adding actions, you can refer to the rule actions.
Nected allows you to test rules in a staging environment before deploying them to production. This helps to ensure that your rules are working as expected. Also, testing your DecisionTable rule is a crucial step as without this, you wouldn't be able to publish / re-publish your rules.
To test a rule, click the Test button.
Testing scenarios
Nected supports a variety of testing scenarios, including:
Testing with different values for the input parameters.
Testing with null values for the input parameters.
Testing with optional input parameters.
Now, If a rule has nullable input parameters, you can test the rule with null values for those parameters. If a rule has optional input parameters, you can test the rule with and without those parameters.
Testing example
To test a rule with different values for the input parameters:
Click the Test in Staging button.
In the Test Rule dialog box, enter different values for the input parameters.
Click the Test Now button.
After the test is completed, it generates a JSON code as the output.
If you see the success message (which you've given while adding data) in the code, that means your rule is ready to publish. If you see the failure message, that means your rule is not ready to publish.
Significance of testing
Testing is important to ensure that your rules are working as expected. By testing your rules in a staging environment before deploying them to production, you can prevent errors and ensure that your rules are not causing any unintended consequences.
Testing is mandatory to do on each edit before publishing to make sure that rule is behaving as expected and without errors.
But, before making your rule live, make sure you change the version of the data source to live. Else you'll get an error like this:
To avoid this, change the version of the data source into a published version (it can be the latest live version or any other live version according to your requirements).
Once you've configured your rule condition, result, and actions, you will see two options on the screen:
Publish to Production: You can publish the rule directly to production and use it over the API.
Request for Review: You can assign an approver to validate your rule.
If you select the "Request for Review" button, it will follow the approval flow, which you can read about in detail here.
However, if you choose to publish the rule, there are a few things you should know about the publish flow.
The rule starts in a draft state. You can make any necessary edits to ensure it meets your requirements. Once you've done with the editing, you now can do two things:
Submit it for Review: If you're working in a team, and there is a reviewer, then you can assign the reviewer and submit the rule in review. Then it will go into the review flow, which you can read from Approval Flow.
Publish your DecisionTable: If you don't want to review your rule by an approver, then you can also directly publish your rule in production. Here is how you can do that:
When you are ready to publish, click the "Publish" button.
Title and Description: A prompt will appear asking for a title and description of the changes. This information helps maintain a clear version history.
Confirm Publishing: After providing the title and description, click the publish button to move the rule to production. The DT is now published and it will create a new published version that you can access from the Publish tab of the Version Control section. This version is live in the production environment.
If you edit a published DecisionTable and re-publish the updated DecisionTable, then it creates a new version of it. Now for any reason, if you want to check or roll back to a specific previous version, you can do that using the version Control tab. You can do this in two different ways:
At the top bar, you can see the Environment tabs with numbers written alongside. These numbers show how many versions you have for that environment. Like in the image, you can see that I've 1 Published versions and 1 Draft version of that. Now, you can click on the respective environment to access the Version Control section like this:
The second option is, you click on the just next icon of the settings icon, and it will open the Version Control section and from there you can access it.
To rollback to a previous version just click on the Rollback button on that version.
So, as discussed in the previous section, if you're editing the DecisionTable and then publishing it, then it creates a new version. But if you're using this decision table in any workflow, and you want to check which version of this decision table that workflow is using, then you can do that using the "Dependency Map" section. To do this follow this:
Click on the icon just below the Version Control icon, and it will open the Dependency Map section.
Inside the Dependency Map section, you'll have two tabs:
Using: In this tab, you can check which integration and data sources, this DT is using.
Used by: In this tab, you can check which workflow is using this Decision table along with the version, as shown in the GIF.
Nected offers a powerful API that allows you to access and execute your rules programmatically. This means that you can integrate your rules with other systems and automate your decision-making process.
Now, for SimpleRules, DecisionTable and RuleSet the process of Rule Access via API is exactly the same. Read here to know how to trigger Rule via API in different environments.
Scheduling is an independent step that allows you to schedule the corn job for your rule. If you’re testing the rule, i.e. if your rule is currently in staging, then you can click on test the scheduler by simply clicking the “Test Schedule” button. And it will run the cron job, for the first 10 rows of the database and return the result for them. After testing, you can also create a scheduler for your published rule from the “Create Schedule” button at the same place in the production environment. You can read more about it from the doc Scheduler.
In Nected, rules can go through three distinct statuses (Draft, Tested, Published/Live), each serving a specific purpose in the rule creation and deployment process.
These three statuses - Draft, Tested, and Live - provide a clear and organized framework for managing your rules within Nected, allowing you to seamlessly develop, test, and deploy rule-based decisions for your applications while maintaining a structured workflow.
As you continue to work with Nected, you may also explore additional features like the Simple Rule Table and Rule Set. Simple Rule is ideal when you have. complex, nested if/else rules to set single outcome based on matching result. Rule Set provides a way to organize and execute multiple rules at once under a single umbrella.
On the "Input Attribute" tab, click on the 3rd tab i.e. Fetch from API
Once the attribute is created, now you can either select from the prebuild API from the REST API list or can simply create a new one for your rule.
To create a new API, just click on the "+Create Rest API" button inside the dropdown list, and it will redirect you to the Connectors page, along with the Rest API modal.
So, now go back to the "Fetch from API" tab and click on "refresh↻" button. And you'll be able to see the new created API connector.
Once selected, now the configuration modal will be opened, where you need to further configure the API with URL path, methods and other important imformations to filter your API data.
