Many-to-One Distribution

Many-to-One Distribution scans a lookup field (for example, AccountId on Opportunity or OwnerId on Case) and counts how many child records reference each parent. Results are grouped into usage buckets so you can see at a glance whether the relationship is mostly one-to-one, evenly spread, or dominated by a few "hot" parents. For polymorphic lookups (lookups that can reference more than one object type), each parent object type is analyzed and displayed separately.

Detailed Job Results

In this analysis, the job is run on the object that has the child records. For each field is analyzed how many of these child records belong to how many parent records, which can be distributed over several parent objects.

For each field, a Child-Parent Distribution doughnut chart shows how parent records fall into usage buckets: how many parent records have 1, 2–10, 11–100, 101–1,000, or 1,000+ child records from the analyzed object. Hover over a chart section to see its details.

The Field Details table lists for each field the Parent Record object, the number of records with the lookup field populated ( # Records with Value), the average number of child records per parent (Average # Children per Parent), the maximum number of child records found on a single parent record (Max # Children), and the number and percentage parents with exactly one child ( # One-to-One Relations, and % One-to-One Relations). For polymorphic lookups, these results are broken out separately for each referenced object type.

Key Insights

• Relationship shape: The bucket distribution shows whether the relationships are mostly one-to-one, evenly spread across many parents, or concentrated on a small number of parent records.
• Overloaded parents: Parents in the 101–1,000 or 1,000+ buckets are the ones most likely to cause slow queries, slow reports, or long, unusable related lists.
• One-to-one prevalence: A high percentage of One-to-One relations can confirm an intended 1:1 design, or it can suggest the lookup could be simplified into a direct field instead.
• Generic parent overuse: An unusually high child count on a single parent often points to a catch-all record (for example, a default "Unknown Account") absorbing links that should point elsewhere.
• Data model fit: Persistent skew across related lookup fields can indicate the current hierarchy needs an additional layer, such as splitting one parent by region or segment.

Recommended Actions

Scenario	Actions
A small number of parents fall in the 101–1,000 or 1,000+ buckets	- Review whether the parent represents a single logical entity or should be split. - Check whether users or integrations are consistently linking to the wrong parent. - Consider an additional intermediate object, or a different lookup/master-detail design.
High child counts are slowing down queries, reports, or related lists	- Add filters so UI components don't load the full related list. - Optimize SOQL queries and roll-ups that scan all children. - Evaluate archiving or splitting strategies for the largest parent families.
A generic or default parent is absorbing most child records	- Define clearer assignment and linking rules. - Use Plauti Manipulate to re-distribute children to more accurate parents. - Clean up or retire the generic parent record.
Preparing for AI model training or aggregate reporting	- Treat extremely high-child-count parents as special cases. - Apply sampling or capping before using the data in AI training sets. - Review whether dashboards and KPIs are being skewed by a few dominant parents.