When SamurAI builds a report with filters, the CRM now checks the filter values before it saves the report. A report can no longer be saved with a picklist value that does not exist, or with a date that is not a real date. Before, such a report was saved anyway and then quietly showed the wrong records.
Contents
1. Before You Start
2. Picklist Filters
3. Date Filters
4. Custom Date Ranges
5. A Filter and a Date Range Together
6. Updating a Report
7. Frequently Asked Questions
1. Before You Start
You will need: a session for the SamurAI service account (the sessionName from the login call), as today.
Access requirements: none beyond today's. The checks apply to every caller of createreport and updatereport .
There is nothing to switch on. The checks start working when the new CRM release reaches the instance. Filters that were already valid behave exactly as before.
What is checked:
Field type | What is checked |
Picklist and multi-select picklist | With "equals" or "not equal", the value must be one of the picklist's values |
Date and date-time | The value must be a real date, and the right number of dates for the comparator |
Text and numbers | Not checked, as before |
2. Picklist Filters
A filter on a picklist field, such as Lead Source or Lead Status, with the comparator e (equals) or n (not equal), only accepts values that exist in that picklist. Take the values from getmodulefieldschema , which lists every value the CRM accepts.
Example request: Leads where Lead Source is "Web Site"
POST {instance}/crm/restapi.php/createreport?sessionName=<sessionName>
{
"name": "Web Site Leads",
"primary_module": "Leads",
"columns": ["Leads.First Name", "Leads.Lead Source"],
"advanced_filter": {
"groups": [{ "group_condition": "and", "columns": [
{ "field": "Leads.Lead Source", "comparator": "e", "value": "Web Site" }
] }]
},
"chart": { "type": "pieChart", "group_by_field": "Leads.Lead Source", "data_fields": ["count(*)"] }
}
The report is saved. Upper or lower case and extra spaces do not matter: "web site" is also accepted, and it is saved as "Web Site" .
Example: a value that is not in the picklist
Sending "value": "Billboard" returns an error, and nothing is saved:
{ "success": false,
"error": { "code": "INVALID_PICKLIST_VALUE",
"message": "Value 'Billboard' is not a valid option for this picklist field (advanced_filter group 0 column 0). Allowed values: Web Site, Campaign, ... . Use comparator y / ny to filter on an empty value." } }
Value sent | Result |
"Web Site" | Accepted |
"web site" | Accepted, saved as "Web Site" |
"Web Site,Campaign" | Accepted: each value is checked |
"Web Site,Nope" | Error INVALID_PICKLIST_VALUE , because one value is not in the picklist |
"" (empty) | Error INVALID_PICKLIST_VALUE : to find empty values, use comparator y (is empty) or ny (is not empty) |
Tip: other comparators on a picklist, such as c (contains) or s (starts with), are free text and are not checked.
3. Date Filters
A filter on a date or date-time field must use real dates. Send dates in the session user's own date format (for example MM-DD-YYYY ) or as YYYY-MM-DD , which is always accepted and is the recommended form. A date-time field also accepts a time, for example "2026-09-01 08:30" .
Example request: Leads created during 2026
"advanced_filter": {
"groups": [{ "group_condition": "and", "columns": [
{ "field": "Leads.Created Time", "comparator": "bw", "value": "2026-01-01,2026-12- 31" }
] }]
}
Comparator | Value to send |
e, n, b, a (equals, not equal, before, after) | Exactly one real date |
bw (between), custom | Exactly two real dates: start,end |
Days and hours comparators (for example daysago ) | A whole number, for example "30" |
Named ranges ( today , last30days , ...) and y / ny | Nothing to check; send "" |
Example: an impossible date
Sending "31-12-2026" for a user whose date format is MM-DD-YYYY (there is no month 31) returns an error, and nothing is saved:
{ "success": false,
"error": { "code": "INVALID_DATE_VALUE",
"message": "Invalid date filter value (advanced_filter group 0 column 0): '31-12-2026' is not a valid date. Send dates as MM-DD-YYYY (this user's date format) or YYYY-MM-DD, optionally followed by HH:MM." } }
Sending only one date with bw returns the same error code with the reason expected two dates, start,end .
4. Custom Date Ranges
The report's standard date filter ( standard_filter ) with type: "custom" needs a real start and end date, with the start on or before the end.
Example request
"standard_filter": { "field": "Leads.Created Time", "type": "custom",
"start": "2026-01-01", "end": "2026-12-31" }
The range is saved as real dates, and the report shows the records created inside it.
Example: an invalid start date
{ "success": false,
"error": { "code": "INVALID_DATE_VALUE",
"message": "standard_filter.start '13-45-2026' is not a valid date. Send MM-DD-YYYY (this user's date format) or YYYY-MM-DD." } }
If the start is after the end, the message is standard_filter.start must not be after standard_filter.end.
Important: before this release, a custom range sent as MM-DD-YYYY was saved as an empty date ( 0000-00-00 ), which broke that report's date filter. Reports created that way should have their standard_filter sent again with updatereport to repair them.
5. A Filter and a Date Range Together
A report can now combine an advanced filter (for example, Lead Source is "Web Site") with a custom date range. Before this release, such a report failed to load its chart and data, and its conversion rates silently showed instance-wide numbers. There is nothing to change on the SamurAI side; the CRM now joins the two correctly.
6. Updating a Report
The same checks apply to updatereport , but only to the filter sections that are sent. If an update is rejected, the report keeps its old filter. If an update does not send a filter section, the saved filter is kept as it is and is not checked again.
7. Frequently Asked Questions
Q: Where does SamurAI get the valid picklist values? From getmodulefieldschema . Every value it lists is accepted.
Q: Which date format should SamurAI use? YYYY-MM-DD . It is always accepted and does not depend on any user's preferences.
Q: Are number and text filters checked now? No. As agreed in the grooming, only picklists and dates are checked. The comparators are still checked by field type, as before.
Q: Will existing reports start failing? No. Saved reports are not re-checked. The checks only apply to values sent in a createreport or updatereport call.
Q: Does the release order matter? No. Valid values work the same before and after the CRM release.
Need Help?
If you run into issues:
1. Read the error message: it names the filter position, the bad value and, for picklists, the allowed values.
2. Compare the value with what getmodulefieldschema returns for that field, or send the date as YYYY-MM-DD .
3. Contact Dazos support with the request, the response, and a reference to CRM-3794.