Plan requirement
| Subscription | Suite Professional or higher, Support Professional or higher |
| Access | Admin |
Explore can report on custom object data, with limits that are worth knowing before you 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.
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.