Plan requirement
| Subscription | Suite Professional or higher, Explore Professional or higher |
| Access | Admin |
Explore can report on custom object data, with limits that shape what you can design around them.
What works
Reporting on tickets, broken down by attributes of the object they point at. Tickets per contract type, or per product, where the ticket carries a lookup to the record.
What is harder
- Reporting on the records themselves, independently of tickets. Explore is built around tickets, and object data is reached through them.
- Deep relationships. A ticket pointing at a contract that points at a product is a chain, and chains do not report simply.
- Historical values. Explore sees the record as it is now, not as it was when the ticket was raised. A contract upgraded last month changes what your old tickets appear to say.
Roll-up fields do part of this natively
Where a custom object is the parent in a parent-child relationship, a roll-up summary field calculates a value from its child records and holds it on the parent: a count of items, the sum of the line prices, the most recent transaction date. That is the same idea as copying a value onto the ticket, but native, and it turns the aggregate into a real field you can report on. It needs Suite Professional or higher, or Support Enterprise.
Three limits decide whether it fits. One field summarises at most 10,000 child records, and above that the summary is not calculated at all. Under a thousand records it recalculates in near real time; between one thousand and ten thousand, hourly. And a child object cannot itself be a parent, so the chain of three above still cannot be built this way.
The one to settle first: a parent-child relationship field cannot be added once either object already holds records. It is a decision you make on an empty object or not at all. Deleting a parent record also deletes all its child records, permanently.
The pattern that solves most of it
Copy the value you need onto the ticket with a trigger, at the moment the ticket is created.
Slightly redundant, and it fixes both problems: reporting becomes straightforward ticket-field reporting, and the value is frozen at the time of the ticket rather than following later changes.
Worth deciding before you have two years of tickets you cannot report on the way you wanted.
Check before you commit
If a particular breakdown is the reason you are building the object, build a small version and try the report before importing everything. Finding the limit after a full migration is an expensive way to learn it.
Comments
0 comments
Article is closed for comments.