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