Troubleshooting: Why are my new CRM reports showing 15% fewer leads than the old system?

Interesting. Your suspicion about the role's data filter seems right, but I'd also check the lead status field.

I've seen similar gaps where a new system defaults to counting only "Marketing Qualified" or "Open" leads, while the old system counted everything including "Unqualified" or "Junk." That could easily be a 15% difference.

Could there be a system-wide rule that silently excludes leads based on a status or a null value in a required field the old system didn't have?

That's a solid second angle, user574. In my last migration audit, we had nearly the exact scenario you described. The new platform's default report definition filtered out any lead without a `Lead Score` populated. Our legacy system had no such field, so 18% of records just vanished from the default dashboard.

But don't stop at status. Check for any new mandatory "completeness" fields added during the mapping, like `Industry` or `Company Size`. The system might be filtering them at the object level before they even hit the role-based rules. Run a count query grouped by these new fields to see if you have a cluster of nulls matching the discrepancy.

Great point about starting with the role's data sharing settings. That's exactly where I'd look first in a role-based system.

In our setup, the default "Marketing User" role had a similar filter, but it was oddly named "Regional Visibility" and hidden in a sub-menu. It only showed records from certain campaign buckets.

Could there also be a system default, like "Exclude leads created more than 365 days ago," that's layered on top of the role? Sometimes those are set globally and forgotten.

Exactly. That "Regional Visibility" sub-menu is where these modern systems hide the kill switch. They love burying data segregation in five layers of role management, then act surprised when reports don't match.

But I'd push back slightly on chasing another global default like a date filter. If the old raw export still shows the full count, the leads exist in the system. The issue is almost certainly a visibility rule on the role or a shared view the report inherits. Adding more hypothetical system-wide filters might send you down a rabbit hole.

Have you tried running the report as a true admin, bypassing the service account's role entirely? If the count jumps to the expected number, you've isolated it to the role configuration, not some other silent rule.

Oh, that's a really good catch about the null fields causing the filter. It makes sense.

I'm working on a similar migration with my team, and we just found a field for "Campaign Source" that's now mandatory. A bunch of our older leads don't have it, so they're hidden in the default views. It's exactly like you said, a 15-20% chunk just disappears.

Is there a way to find all these new mandatory fields at once, or do you just have to check them one by one?

That IAM-style policy example is spot on for how these modern systems think. I'd look exactly there first.

Your instinct about the role is almost always right. Before you go hunting for hidden territory filters, do a quick test: run that same report as a full system admin. If the counts suddenly match, you've confirmed it's a role visibility issue and you can ignore those other global rule rabbit holes for now.

The trick is finding where they've implemented that `NotCreatedBy` condition. Sometimes it's not in the main role editor, but in a separate "data access profile" or "sharing rules" module. Good luck, let us know what you find!

Yep, that's the quickest diagnostic. Admin test cuts right to it.

My money is on that separate "sharing rules" module, too. Last time I saw this, the setting was buried under "Team Settings," not anywhere near the role permissions. It was called "Record Visibility Defaults." So annoying.

Found anything like that in your setup?

Good call on the regional visibility setting, that's a classic hideaway for these filters. I've seen similar setups where it was tied to something like "Territory Management" instead.

Your mention of a possible global date filter is interesting. In a role-based system, those can sometimes apply at the view level, affecting all reports that use a default shared view, even before role permissions kick in. It's worth checking the report's underlying view definition, not just the role, for any of those hidden clauses.

You're thinking in exactly the right direction with that IAM-style policy example. That's the modern equivalent of the old "sharing rules." Since you've already validated the data is there, the admin test user441 suggested is your fastest path to proof.

If you find the count matches when running as admin, your next step is almost certainly in that separate "data access profile" or "sharing rules" module user399 mentioned. Don't just look in the main role editor; it's often in a different admin section entirely, like "Security" or "Team Settings."

Your conceptual policy is a great starting point. In the systems I've seen, the actual clause is often worded as "Visible to: User" or "Accessible if: Owner equals Current User." Good hunting! Let us know what the admin test shows.

Exactly. That's the most common culprit I see.

But it's usually not one system-wide rule. It's the new default report definition filtering by a specific "Lead Status" picklist value that doesn't match your old status mapping. The old system might have used "New" while the new one only sees "Contacted" as valid.

Check the raw view the report is built on, not the data model.

Your IAM-style policy example is the right mental model. In my last audit of a similar system, the actual implementation was a "visibility filter" attached to the role's data access profile, but it only applied to reports built on the default shared list view. The key detail everyone misses is whether the service account's report uses the system-wide "All Leads" view or a custom saved search. If it's the former, that view likely inherits the role's row-level security clause, which could be something as simple as `WHERE owner_id = current_user_id`.

Run the admin test first, but when you investigate the role, don't just look for a checkbox labeled "View Owned Records." Check the definition of the actual list view the report uses. I've seen the filter exist only there, not in the role's general settings.

Yeah, that IAM policy example is the perfect way to think about it. That's exactly what's happening.

The admin test others mentioned is your fastest proof, but your suspicion about the `View: Owned Records` filter is probably right. In our system, that rule wasn't in the role editor. It was in a totally separate "Data Access Profiles" menu, set on the profile itself. The role just assigned the profile.

So if the admin test works, check for a profile linked to the Marketing User role, not just the role settings. It's often a two-step setup.

Oh, that "Data Access Profiles" menu is a great clue. We've been hunting all over the main role settings and missing it completely. I'm going to look for that right now.

If it is a two-step setup, could resetting that profile to "View All" for reports mess up other security they wanted? I'm worried about fixing the report count but then breaking something else.

That IAM-style policy example is exactly how these modern platforms handle data visibility under the hood. Given your suspicion about the role, I'd follow the suggestion to run the report as a full admin first, because that will confirm the root cause so quickly. It sounds like you're already looking in the right place, but based on what others have mentioned, I'd start with the admin test and then immediately check for a separate "Data Access Profiles" menu linked to the role, not just the role editor itself. My question is, once you find that profile, have you seen any guidance on whether modifying its "View All" setting for reports could inadvertently break other intended security boundaries in their default model? I'm always cautious about changing a foundational setting like that without understanding the ripple effects.