No Status

SQL Interface to build datasets for rules

  • 14 September 2020
  • 5 replies

Userlevel 3


I wonder how many of you Gainsight admins would vote for a sql interface to be able to create datasets for rules. As a heavy sql writer/user in my previous role I’m quite disappointed that what used to take me 30 min or less to pull a data set with sql now takes 10 times longer to build with rules. No matter how many new functions are added in the rules engine, there always seem to be the one that is missing when a more complex data manipulation is needed; ie regex, substr with instr; case statements with dates data types, sum(case) etc. 





5 replies

Userlevel 7
Badge +2

I can definitely see this being a good option for people who are very familiar with SQL.  I myself am a beginner at best, so it would definitely take me longer to figure out how to get at the data I wanted if the interface was just SQL.  Wondering if it would be possible to have an option?  So, either use the Rule Builder or use SQL?

Userlevel 3

Yes, I agree Heather - this should be available as an option and not as the only way for sure. 

Userlevel 4

@jivanova I think this is a great idea! I would even suggest we add this option for reporting/data designer as well.

I agree that sometimes I think it would be much easier to build a temp table, use subqueries, use variables, join on multiple tables at once, or build out case statements in SQL rather than create individual tasks for each step. I think this would be great so long as you can still run your query (or preview your results) as you go.

I’m not an expert in SQL, but I like how it’s easy to troubleshoot & see your query results all in one consolidated interface. I think this speeds the process up considerably and makes it easy to validate your query results.



Userlevel 5

This would be a great idea! I can see this heavily utilized in my organization. 

Userlevel 5

Great idea - hope to see this in rules, reports and data designer!


More importantly, we’d need the flexibility to use display names from objects instead of internal names, and all the functions in the underlying database should be exposed to the end-users.