The Report That Disagrees With the List
An operations lead builds a report: 'Open incidents by assignment group, last 30 days.' The report shows 812 incidents. When she opens the Incident list with what she believes are the same filters (active = true, created in last 30 days), the list shows 1,046. She is convinced the report is broken. The instance uses domain separation for two business units, and she has roles in both. The report was built by a colleague in the other business unit and shared to her. Additionally, the report groups by assignment_group but several incidents have no assignment group and appear under a blank label that she didn't notice.
1. Give at least three concrete reasons the report and the list can legitimately disagree, and how to isolate the cause.
Read the worked answer
Legitimate divergence sources:
- Domain separation: a report runs in the domain of the user who owns/executes it, and shared reports can carry domain context. If the colleague is in the other BU, the report may be scoped to that domain, while the list she opens runs in her current domain. This alone can explain hundreds of rows.
- Different filter semantics: 'active = true' on a list vs. a report condition can differ if the report uses a grouped/aggregate query or a different date field (e.g.,
opened_atvscreated). 'Last 30 days' oncreatedvsopened_atyields different counts. - Blank group bucket: the report's grouped output includes a blank
assignment_groupbucket that she overlooked; the list shows those rows inline, so totals differ if she mentally excluded them. - Record access / ACLs: list views apply row-level ACLs; some report types may render aggregate counts that don't map 1:1 to visible rows.
Isolation method: rebuild the report as a plain list with identical conditions, confirm counts match, then add grouping. Check the report's domain and owner. Compare opened_at vs created explicitly. Export both to CSV and diff the sys_ids - the delta set tells you exactly which condition differs.
2. She wants a single trustworthy number. What should she change about the report design?
Read the worked answer
Make the report self-describing and domain-explicit:
- Pin the report's domain to the intended scope (or run it as a user whose domain matches the audience).
- Use the same date field the business defines as 'open date' and state it in the report description.
- Add an explicit '(empty)' group or a calculated 'Unassigned' bucket so blank assignment groups are visible, not hidden.
- Add a record count total and a note of the filter conditions in the report footer.
- Where possible, base the report on the same query the list uses, and validate by exporting both to CSV and comparing sys_ids once.
Then document the definition so future disagreements are resolved by checking domain and date field first, not by assuming the report is broken.