SimpleRule
Last updated
Last updated
This documentation provides a technical guide for creating a simple rule within Nected, a platform designed for rule creation and management. Nected enables users to connect to various database systems, including PostgreSQL, MySQL, and MongoDB, and define rules to trigger specific actions based on data conditions.
This documentation is intended to assist users in creating simple rules without focusing on the specifics of any particular database system, as Nected is adaptable to different database technologies. It outlines the steps required to set up and configure a simple rule within the Nected platform, emphasizing the flexibility to integrate and work with a wide range of database options.
Creating a simple rule in Nected allows you to define specific conditions and actions based on your connected database's data. This section provides a step-by-step guide to creating a simple rule, emphasizing the flexibility to use various types of databases like PostgreSQL, MySQL, or MongoDB within the Nected platform.
To create a new rule in Nected,
Log into your Nected account and navigate to the Rules section available in the left sidebar.
Click the + Create Rule button to open a popup with two configuration options:
Build your own
Start from template
Choose Build your own to set up a Simple Rule from scratch:
Enter a Rule Name: Specify a name for your rule which clearly identifies its purpose.
Provide a Rule Description (Optional): Give a brief description of what the rule is intended to accomplish. This is helpful for future reference or for other users.
Select the Rule Type: Click on the Simple Rule option. A Simple Rule consists of if/else conditions processed all at once, typically used for customer segmentations, simple plan allocations, or referral bonus payouts.
This action will initiate the rule-creation process. However, before proceeding, it's important to choose the appropriate rule type for your specific use case.
Nected offers a total 3 rule types, each designed to address particular scenarios. You can read about each one of those here.
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'll define essential rule information, including:
Configure your rule by setting the necessary conditions and actions:
Define the if/else logic that will dictate how the rule behaves based on certain conditions.
Specify the actions to be taken when conditions are met or not met.
Connect to a Data Source if needed (this is optional):
You can either use custom input parameters to pass data directly into the rule or connect to a database to retrieve data automatically, depending on your specific requirements.
Rule Environment: The rule environment determines whether the rule will be executed in staging or production. Staging is a test environment where you can test 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.
To deploy a rule into the production environment it must be published. There is no need to switch to the production environment unless you wish to make changes to the rule settings. However, any changes to the rule settings will require republishing.
Rules can be executed in three different environments: a published rule in production, a published rule in staging, and a non-published rule in staging.
Read more on Triggering Rules via API.
Currently, there is no provision for testing non-published rules in the production environment.
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 case case-sensitive manner, and/or if it is optional. Eg - For the loan approval example, you might create attributes like light_intensity, soil_moisture, temperature and humidity.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 & Next
For String, Date & Date&Time attributes,
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 prebuild 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 staging first by clicking "Publish in Staging" and then repeat the same thing in production. Then finally publish it in production by clicking on Publish in Production button.
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.
Now you're ready to use the dataset values inside your rule condition as well as in the rule result.
Depending on what datatype you've selected for the custom attribute, you can only map those types of data of the dataset.
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.
The rule condition section is where you define the criteria that must be met for the rule to fire. You can use a variety of operators and conditions to create complex rules.
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, Greater than or equals, Less than or equals, Is Even, Is Odd
For more detailed 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.
After defining conditions, you can organize them into groups. Groups help manage the logical flow of your rule. You can set the group type as "AND" or "OR," and conditions within a group are evaluated accordingly.
To create a group follow these steps:
Click on the 3 dot button at the right of any row, and you'll see the below options:
Convert in a Group: This works on a single row. If you click on this button then it will convert that row into a group, like this:
Leave a Group: This also works on a single row. If you click on this button then that row will leave that group and will go to the parent group, like this:
Wrap: Wrap is similar to "Convert in Group" but for groups. To wrap into a group, you need to click on the 3 dot button at the right side of a group. And then click on "Wrap into Group" from the list. Then it will wrap that group into another group, like this:
Unwrap: Unwrap is just the opposite of wrapping and it is similar to leaving a group. To unwrap a group from another group, you need to click on the 3 dot button at the right side of a group. And then click on "Unwrap Group" from the list. Then it will unwrap that group from the parent group, like this:
Defining the results and actions of your rule is a critical aspect of its configuration. In Nected, both results and actions have distinct functionalities:
When you add results, you specify the type of result you expect from the rule. Nected offers various result data types, including boolean, numeric, string, date, JSON, and custom JavaScript formulas. The choice of data type depends on the nature of the rule and the desired outcome.
The Rule Result works like below:
To add Rule Result, follow these steps:
In the rule editor, you can find the Result just below of the If part.
In the result section, there are two options, Then & Else. You can add results for both of them.
Inside Then, click +Add Result button, and a dropdown will appear. From there choose the type of result you want to return if the rule satisfies the true condition. 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.
NULL token: If you want to pass a NULL value in your rule result, then you can select the NULL token from the System Attribute.
Similarly, if you want to return a rule result if the conditions are not met i.e. the rule returns false, then just go to the Else part, and similarly click +Add Result button. Then similarly you can choose and add the result you want to show.
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. There are different types of action:
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 Result section, click on +Add Action button inside Then or Else part, according to when you want to trigger the Action.
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. To test a rule, click the Test button.
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.
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).
Finally, you can publish the rule. Now, while publishing, 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 SimpleRule: 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 rule 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 SimpleRule and re-publish the updated rule, 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 10 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 ruleset and then publishing it, then it creates a new version. But if you're using this simplerule in any workflow or ruleset, and you want to check which version of this simplerule that workflow or ruleset 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 or data source, this simplerule is using.
Used by: In this tab, you can check which ruleset or workflow is using this simplerule 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.
Example:
This example triggers the rule with the rule ID {652a0574438f52XXXXX} using curl.
You can see the exact steps to trigger rule via API here and utilizing Nected's API, you can seamlessly call your internal/external flows from within your rules based on its outcome, allowing you to make data-driven decisions effortlessly.
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 Decision Table and Rule Set. The Decision Table allows you to define and manage decision logic in a structured tabular format and is helpful when you want to set up different outcomes for different combos in excel like view. 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.
