The Test Console is designed to help you test your business rules before deployment. It is also useful to better understand issues that might occur once your rules are live.
The Test Console applies a business policy to actual records in your org, but does not apply the actions -- so you can see in detail how a business policy would behave, without actually modifying your data.
Follow the steps below to test your rules, and interpret the results of the tests.
Open the Test Console
To open the Test Console, click the Test button on the policy detail page:
Note: the Test Console is also available on page 2 of the Policy Editor Wizard.
Select records to test
In the Test Console, select a List View, then select the record(s) you want to test:
If you do not see checkboxes, please consult this article
Run the test
Click the Run Test button below the list to run the test. When the test is complete, you will see a record showing the results for each selected record:
Interpret the results
The Status and Actions columns give a high level view of the test results for each selected records. If these match the expected outcome, congratulations!
If the results are not what you expected, you can click the Details link in the Execution Record column to get a more detailed view of the rules that were applied:
The Detail Messages contain the following sections:
- Input data
Shows the name of the main record, as well as names or counts of related records that were loaded.
Use this to validate whether the data required by the rules engine was actually found.
If you are not seeing the records you expect, please open a support ticket.
Summarizes the actions applied
- Execution record
Shows a detailed list of all the rules applied and other relevant actions during rules processing
Reviewing the Execution Record
The Execution Record will contain one entry per action for each row that is applied (i.e. the conditions for that row are satisfied). The detailed text of the entry varies based on the type of record and the action. Some examples are:
-- LeadProfiles row 6 applied: Lead Midsize West matched profile Assignment Eligible
-- Assignment row 13 applied: [Action section: AssignOwner] Lead [Midsize West] will be assigned using rules in table Territories
-- Territories row 279 applied: [Action section: AssignOwner] Lead [Midsize West] will be assigned to user firstname.lastname@example.org
If the rules are not generating the results you expect, you should start by determining which row(s) you would expect to see. There are three main scenarios:
- A row with higher priority (i.e. a lower row number) is pre-empting the row you expect to see
In a single match table, this will stop processing before your expected row is applied.
You should check to see whether the higher priority row needs additional conditions to prevent it from being applied to your test record
- The expected row is not applied
In this case, you may see a lower priority row (with a higher number) being applied, or no action at all (if no rows in the table match).
To correct this, perhaps the conditions on the target row are too strict, or the test data is missing certain required field values.
- The expected row is applied, but the action is not what you expect
Check the action to see it is correctly configured. For assignment actions to groups, make sure the group exists and has eligible members
Generating more detailed logs
If you are expecting a row to be applied but it isn't, you can generate a more detailed log that explains the reason why. Set the Execution log level to Debug:
Then re-run the test.
You will now see statements for each row explaining why it did not match. For instance:
-- Assignment row 12 not matched: checkSetValueContainsAll((Assignment Eligible, SMB), [LeadProfiles]Midsize)
There are four relevant values here:
- checkSetValueContainsAll: the match operator
- (Assignment Eligible, SMB): the actual values
- LeadProfiles: the column name
- Midsize: the value found in the policy table
Generating detailed logs by line
Note: This functionality is available with Decisions on Demand v1.23 or higher.
If you are expecting a row to be applied but it isn't, or vice versa, you can generate a more detailed log for that specific row by selecting it in the Decisions Table section below the Run Test button.
In the above example row 3 will display Trace level detail in the log while the other rows will display Production level, default, details. You can also chose rows on multiple tabs such as the Lead Profiles tab as well as the Master Assignment tab above.
This is particularly useful if you have a large policy with a large number of tabs or rows within the tabs where Trace level debug for the whole policy might overwhelm the size of the log and require it to be truncated.
In this example only assignment row 3 displays this level of detail, specific to the criteria for the row, for the record that is being tested:
-- Assignment row 3 MATCH: New is included in (New) [Column: Lead_Status1]
-- Assignment row 3 MATCH: US: United States is included in (<empty set>) [Column: Countries]
-- Assignment row 3 MATCH: CT: Connecticut is included in (<empty set>) [Column: States]
-- Assignment row 3 NO MATCH: no LeadProfiles matches found. One of (Mid-size) is required
-- Assignment row 3 NO MATCH: ((Weekday, After Hours, Small)) does not contain all values from (Mid-size) [Column: LeadProfiles]