Building a Custom Report Type takes deliberate design. The object combinations, join semantics, and field selection all need to match what analysts will actually need from the reports. Build in sandbox, test with realistic data, deploy thoughtfully, and review periodically as the data model evolves.
- Identify the report use case and required data path
List the questions analysts need to answer. Sketch the object path that connects the data: primary object, then related objects in order. If standard Report Types already cover the path, skip the Custom Report Type and use the standard one.
- Create the Custom Report Type
Setup > Report Types > New Custom Report Type. Pick the primary object, enter a label, plural label, description, and category (Sales, Service, Custom). Save and proceed to the detail page.
- Add related objects via the A-B-C relationship picker
From the Custom Report Type detail page, add up to three levels of related objects. Pick the relationship field that connects each level. Configure the join semantics: inner join (each primary must have a related) or left outer (primary records included regardless).
- Configure Fields Available for Reports
Click Edit Layout or the Field Layout link. Pick fields from each object, drag them into logical sections, and set defaults for column display. Exclude fields that do not help analysts; cleaner field lists produce better reports.
- Set the status to Deployed
Edit the Custom Report Type and change status from In Development to Deployed. This is the step that makes the type visible to analysts in the report builder. Forgetting it is the most common Custom Report Type bug.
- Build a sample report to validate
Open Reports > New Report > pick the new Custom Report Type. Add filters, groupings, and columns. Verify the row count matches expectation against a known reference. Confirm joins behave as configured.
- Document the type for analysts
Add a clear description, useful example use cases, and any quirks. Analysts who do not know the field exists or what it means will skip it. Documentation pays off through more adoption and less support load.
- Deploy through change set or metadata API
Custom Report Types deploy like other metadata. Include them in your deployment package. Test in the target org by building a sample report after deployment to confirm everything came through.
The root of the Custom Report Type. Every related object joins through a relationship field on the primary or a downstream relationship.
Up to three related objects, each joining through a specific relationship. Configure join semantics: inner or left outer.
Which fields are exposed for reporting and how they are grouped. Excluded fields cannot be added to reports built from the type.
- Custom Report Types default to In Development status. Forgetting to flip them to Deployed is the most common bug; analysts report that the type does not appear in the picker.
- Inner join versus left outer changes the row count significantly. Picking the wrong join semantics produces reports that exclude records analysts expected to see (or include records that should not appear).
- Field renames or deletions on the underlying objects can break reports built on the Custom Report Type. Maintain an inventory and review during quarterly schema cleanups.
- Up to three levels of related objects per type. Deeper relationships need to be modeled through a different primary object or through multiple Custom Report Types.
- Field-level security still applies. Users without read access to a field see it as blank in reports built from the Custom Report Type, even if the type exposes the field.