Skip to main content
New Idea

Cheat Sheet Reporting Enhancements

Related products:CS AI
MayurGhiya
dayn.johnson
Daniele Cmty
Johnk
Ditte
+3
  • MayurGhiya
    MayurGhiya
  • dayn.johnson
    dayn.johnson
  • Daniele Cmty
    Daniele Cmty
  • Johnk
    Johnk
  • Ditte
    Ditte
  • timcavey
    timcavey
  • revote
    revote
  • Christian_
    Christian_

bradley

This is probably more of a community FYI than a request, because it’s more of a series of needed updates that would, based on my experimenting and user feedback, make reporting on Cheat Sheet worthwhile.

 

  • Fix Orphaned Data: Data from merged or deleted Companies is orphaned. It is not included in the merge process, or expunged if the parent record is deleted so you have Cheat Sheet records that don’t actually associate to an existing customer record, even if, on inspection, they appear to relate to one.
  • Add a Standard Created Date: Created date does not correspond to when the data entered the Cheat Sheet MDA. This is rather contrary to how most Created Date fields are expected to work. Usually *Created Date* means *the date the record was created in this table*. Not so when it comes to Cheat Sheet - it very loosely corresponds to the Activity Date of one of the Timeline entries used to generate the insight. It’s also not even available for all records.
  • Add links to relevant data: There's no reference (id or otherwise) to the Timeline entry/entries used to generate the record. You have this in the UI when it is available, but you cannot report on it. So if part of the reason you want this is to make the data more widely available outside Gainsight, but still related it to Timeline entries when possible for further inspection, you’re out of luck.
  • ID Taxonomy: These next two are similar issues:
    • Key Point ID is an unintelligible mix of ID formats; No standard object GSID
    • There’s no reliable taxonomy of GSIDs in Gainsight*, and Key Point ID is Pretty meaningless, and doesn’t even have a consistent format.
  • Row Grouping: Each row is a category, so each customer will potentially have multiple rows per category - a bit of a blessing and a curse, it makes it easier to separate, but harder to relate back to what you see in the UI. I showed a report to one user and they were rather confused. They were expecting to see one row per customer, so they could see everything in one place. It’s not really intuitive for users to have to also search/filter/rank by customer AND category (hello multi-level sorting?).

*There is some appearance of consistency where the first X characters of a GSID are the same for that object, but that is only for Standard objects and those first X characters might not actually be unique to that object either, and any appearance of conformity is evidently not guaranteed at this point.

0 replies

Be the first to reply!

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings