Ability to duplicate queries in Journey Orchestrator

This would be extremely helpful, especially with elaborate queries that have multiple merge and transformations.

This would be great, and if queries could be persistent throughout Gainsight as well and not just within JO, so that if you are for example querying on a set of users or companies you can simply import a named query and/or filter set and be on your way.

We have plans to give the option to save queries in a query library, which you can then reuse and modify anytime. This query library will be applicable in all Gainsight product areas like JO, rules, data designer. ETA not yet decided.

Happy Friday news!

Since Query Builder is essentially an extension of the rules engine, we need the ability to save JO queries as rules for later use. Also, why isn’t there the ability to designate a “default” query for all programs to start from?  How heavy of a lift would it be to add in two implied starting points based off of SFDC Contact and Company Person (*the company person query variant would be invoked when you selected “Use Gainsight standard fields”)

I have suggested to some of my customers that they create a survey and an email chain program that already has a starter query in it, and then clone that ad infinitum. It seems to work and it saves some time.

The query I use to start off any program is essentially the same whether it be from contact or company person, but it uses the following fields/filters:

First/Last/Full Name, SFDC Account/Contact id & name (if you have sfdc), Email, Title, CSM Name, CSM Email. -- filters for Email, full name, first name != null

*for company person sub in Person id, Company Name/ GSID

So my asks are - would it be possible to save query builder rules for later use, and would it be possible to designate a set of Base/starter queries that could be used in all programs if a saved rule was not useful?

Adding onto @dan_wiegert’s post, and dreaming a bit…

I would love to see Queries de-coupled from the Rules Engine or Journey Orchestrator and become their own Object. Then one could manage the Query as its own “record”, and pull it into service in a Rule or a Journey or as a Data Designer starting-point. Because Queries currently are tightly coupled with their originating functionality (Rules Engine, JO, etc.), it’s a lot of work to re-build them when moving between Gainsight features.

This is a big dream, I realize, but it sure would be cool.

Hey @matthew_lind,

What I envision is something more like how Email Templates currently work with email assist -- JO Participant rules would automatically be saved to a rules folder that is shared between the rules engine and JO. You would only be able to run a JO rule in test if using the rules engine (only to model how that rule would perform in your program, or to compare results - I do this a lot), and in the rules engine JO sourced participant rules would have a second toggle switch associated with them to make them available in the active selection list for your programs. 

That having been said, when the ability to save JO queries is productized, I really think that using descriptive, use case oriented naming conventions will become VERY important. if done right, this could be a MASSIVE timesaver for JO and would greatly empower users. 

This would be extremely helpful for us to implement

Decoupled query builder would be huge as others have said! Much much required. 

I need this! Similar use case, that I always have 3 regions that I build a query for. This is to be able to have a different scheduled time that each query runs, for different time zones. Typically there’s just 1 filter that needs to be different for all queries. 

To replicate this query x2, for example, it took me around an hour to re-build the query. In could have taken 5 minutes instead, to clone, and change 1 filter!