Reporting, Calculated Fields, and Analytics
Report shapes
Custom report types each solve a different problem. Advanced reports use one primary data source and can pull fields from related business objects. Composite reports stitch together multiple data sources or sub-reports when no single data source spans the needed fields. Matrix reports pivot on groupings with aggregations. Always check delivered reports first: a question phrased as without building anything new points to a standard report or a report-as-field.
Calculated fields
A calculated field is itself a business object with a primary business object and a field type. The type drives the answer:
- Arithmetic for formulas across numeric fields.
- True/false for boolean flags.
- Evaluate expression for conditional if/then logic.
- Lookup value and extract single instance when the related object can have many instances.
- Aggregation when you need one rolled-up number from many related instances.
- Date difference for tenure and elapsed-time calculations.
Traps: placing a field that returns multiple instances directly on a report row (the report duplicates rows or errors - wrap it in an aggregation or single-instance extraction); assuming a custom calculated field is visible to everyone (access still follows the domain of the underlying object); forgetting that a lookup on a many-to-one relationship returns the first related instance by sort order unless you filter.
Rule of thumb: one-to-many needs aggregation, many-to-one needs lookup value, conditional logic needs evaluate expression. Build one prompted report rather than many hard-coded copies, and remember that sharing a report and having View on its data source are both required.