Report Type
A report type is a Salesforce template that defines which records and fields are available to a report, based on the relationships between a primary object and its related objects.
Definition
A report type is a Salesforce template that defines which records and fields are available to a report, based on the relationships between a primary object and its related objects. When you start a new report, the report type you pick decides what data you can pull and which columns you can add.
Salesforce ships standard report types for common pairings, like Accounts with Contacts or Opportunities with Products. Admins also build custom report types to expose object combinations and lookup fields that the standard set does not cover.
How report types shape what a report can see
Standard report types versus custom report types
Every report in Salesforce sits on top of a report type, and that type is either standard or custom. Standard report types are generated automatically. When you create a custom object or enable certain features, Salesforce produces matching standard report types so users can report on that data right away. You cannot edit or delete a standard report type, and it always reflects the object's current fields. Custom report types are the ones an admin defines by hand. They let you choose a primary object, attach related objects, and decide exactly which fields show up. The big reason custom report types matter is reach. A standard report type usually covers one object or a single parent-child pairing. A custom report type can join up to four related objects and pull fields from lookup relationships, so you can report across combinations that no standard type offers. Think of an org that needs Accounts with Cases and Case Comments in one report. No standard type does that, but a custom report type can. Mature orgs keep a curated set of custom report types so report builders are not stuck waiting on whatever Salesforce generated.
Primary object and related objects
Every custom report type starts with a primary object, which is also called the A object. This is the anchor for the whole template, and every report built on the type returns rows of that object first. From there you can attach related objects, often labeled B, C, and D, to bring in child records and their fields. A custom report type can include up to four object relationships. The relationships you can use depend on how the objects connect in your schema. Master-detail and lookup relationships both qualify, which is why you can surface a parent record's lookup fields on a child-focused report. There is a generous ceiling on field sourcing as well. A report type can reference up to 60 objects total, so even at the four-relationship maximum you can still pull fields by lookup from another 56 objects. One practical limit to remember at run time: if a finished report shows columns drawn from more than 20 different objects, Salesforce throws an error. Plan the object chain before you start clicking, because the primary object you pick cannot be changed later without rebuilding.
The with-records versus with-or-without-records choice
When you add a related object to a custom report type, Salesforce asks how child records should affect the result set. This single choice changes which rows appear and trips up a lot of new admins. The first option reads roughly as "Each A record must have at least one related B record." This behaves like an inner join. Only primary records that have at least one matching child show up. An Accounts with Contacts report built this way hides any account that has no contacts. The second option reads as "A records may or may not have related B records." This behaves like an outer join. Every primary record appears, whether or not it has children, and child fields are simply blank where none exist. That same account report would then list every account, even the empty ones. Once any relationship in the chain is set to may-or-may-not, all relationships after it use that looser association too. Pick deliberately. If you are counting accounts with no open cases, you need the may-or-may-not setting, because the strict version would drop exactly the records you care about.
Deployment status: In Development versus Deployed
A custom report type carries a deployment status that controls who can see it. While you are still designing the type, you keep it In Development. In that state the report type is hidden from everyone except users with the Manage Custom Report Types permission, which usually means admins. This is your safety net. You can shape the object chain, arrange fields, and test a sample report without exposing a half-finished template to the whole company. When the design is final, you switch the status to Deployed. Only then does the report type appear in the report type list for ordinary users who otherwise have access to the underlying objects. Field-level security and object permissions still apply on top of this. A deployed report type never overrides a user's existing access, so someone who cannot see an object will not see its fields just because the report type includes them. A common rollout mistake is forgetting to flip the status. Builders sometimes report that a brand new report type is missing, when the real issue is that it was left In Development.
Designing the field layout that report builders see
A custom report type does more than join objects. It also decides which fields are even offered when someone builds a report on it, and how those fields are grouped. Inside the report type you can open the field layout and add or remove fields, drag them into named sections, and rename their column labels for clarity. This is a quiet but powerful piece of self-service design. A report type with 300 raw fields overwhelms users. A trimmed type that surfaces the 30 fields people actually use, grouped under sensible headings, makes report building fast and far less error-prone. You can also add fields through lookup. If your primary object has a lookup to another object, you can pull that object's fields into the layout so they sit alongside the native ones. By default, new fields added to an object later do not automatically join an existing custom report type's layout. You can toggle a setting so that newly created fields are checked into the layout automatically, which saves maintenance work as the object grows. Treat the field layout as part of the user experience, not an afterthought.
Where report types fit in the analytics stack
The report type is the foundation of native Salesforce reporting, and a lot of downstream value depends on getting it right. A report draws its rows and columns from the report type. A dashboard component draws from a report, so the report type quietly governs what a dashboard can ever display. If a metric is missing from your dashboards, the gap often traces back to a report type that never included the needed object or field. Good report type design is therefore an analytics enabler, not just an admin chore. By publishing a well-named library of custom report types, an admin gives business users a self-service starting point for almost any question they want to answer. Naming and categorization matter here. You assign each custom report type to a report type category, like Accounts and Contacts or Customer Support Reports, so users can find it. For analysis that outgrows native reporting, such as blending external data or large-scale dashboards, teams move to CRM Analytics, but standard reports and the report types behind them remain the everyday workhorse for most orgs.
How to create a custom report type
Build a custom report type when no standard type exposes the object combination or fields your users need. You create it in Setup, define the object chain, then set the fields and deployment status. You need the Manage Custom Report Types permission, which admins normally have.
- Open the report type setup area
In Setup, use Quick Find to open Report Types, then click New Custom Report Type. Salesforce offers a legacy builder and an enhanced builder; either one walks you through the same core choices.
- Choose the primary object and label it
Select the primary (A) object, then enter a clear label, a unique developer name, a description, and a report type category so users can find it. Leave the deployment status as In Development for now.
- Add related objects and set record inclusion
Attach related objects (B, C, D) up to a total of four relationships. For each one, choose whether every A record must have a related child, or whether A records may or may not have children, which controls inner versus outer join behavior.
- Lay out the fields
Open the field layout, add or remove fields, group them into sections, and rename column labels. Pull in lookup fields where helpful so the right columns are offered when people build reports.
- Deploy and test
Switch the deployment status to Deployed so eligible users can see it, then build a quick test report to confirm the rows and columns behave the way you intended.
The anchor (A) object every report on this type returns first; it cannot be changed after creation without rebuilding the type.
The friendly name shown to users when they pick a report type to start a new report.
The unique developer name (API name) used internally and in metadata; it must be unique across report types.
The report type category, such as Accounts and Contacts, that determines where the type is grouped in the report type list.
In Development hides the type from non-admins; Deployed exposes it to users who already have access to the underlying objects.
- A type left In Development is invisible to regular users, so a brand new report type that "won't show up" is usually just undeployed.
- The with-related-records option acts like an inner join and hides primary records that have no children; use may-or-may-not when you need every primary record.
- You cannot change the primary object after the report type is created, so plan the object chain before you start.
- A report type can join at most four objects, and a report that pulls columns from more than 20 objects throws an error at run time.
- Report types never widen access; field-level security and object permissions still filter what each user can see.
Trust & references
Cross-checked against the following references.
- Custom Report TypesSalesforce
- Add Child Objects to Your Custom Report TypeSalesforce
Straight from the source - Salesforce's reference material on Report Type.
- Custom Report TypesSalesforce
- Limits on Report TypesSalesforce
Hands-on resources to go deeper on Report Type.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Report Type?
Q2. Why build custom report types?
Q3. What's a best practice?
Discussion
Loading discussion…