Report filter should allow Field comparison beyond simple equality checking

How is this still not a thing?

In Data Designer, I can make field comparisons based on more than simple equivalency:
 

But in Report Builder, I can’t:
 

This makes our reporting capabilities more difficult as we have to jump through transformation hoops in Data Designer in order to get to the desired result. 

​@revathimenon may you please request the Report Builder PM to have a look at this? Thanks!

#featureparity

#productparity!

Why should we need to create a Data Design just to build a report? We should have the full list of operators everywhere. This brilliant post by ​@romihache covers operator parity beautifully.

That, or maybe let us create a query inside report builder for those one-off reports that rely on multiple objects to get the necessary information.

Please bring this to reports! It’s so needed and would greatly simplify workflows.

This isn’t even limited to reporting. The entire platform offers a variety different experiences depending on where you are ranging from the above, where field comparison filter leaves something to be desired, to the not even possible like cockpit filters:

Whenever a PM has a look at this, I implore them to confer with their colleagues to ensure that:

1. Field comparison filtering is supported consistently throughout the platform
2. Field comparison filtering has the same capabilities throughout the platform

We don’t need to re-invent the wheel by adding new features to get around this - just fix the existing and obvious problem.

I have a wish that the Gainsight CS platform become more intuitive. That is, we are surprised less often by a behavior that’s in one section of the platform that’s absent, or differently-behaving, than in another section of the platform.

Filters come to mind immediately….what would happen if Filters always had the same design language, and look-and-feel, and behavior? Filters would be a library-like feature set, that all areas of the CS product (or hey….even the non-CS products, if we’re dreaming big) then call upon. In this way, the platform becomes more predictable in how it behaves, and our designs become more readily deliverable.

As an admin, having to catalog which feature sets support which operators within which field types, and how many CASE statements, and which are case-sensitive, and the like, is a burden that we could be freed from to focus on the impact of the final deliverables rather than on the construction duties required to deliver them.

This is the path to scale, and CS certainly has spent many a Pulse presentation and many a LinkedIn post emphasizing scalability.

When Gainsight CS is intuitive, it’s also

• More readily adopted
• More quickly onboarded
• More extensively supported, because admins and end users compose and deliver their work more reliably

Thank you for attending my TED talk.

Totally agree ​@matthew_lind! I made a Community post about this about a year ago