Skip to main content

We need the ability to orchestrate different processes like we do in rule chains, but inclusive of all the elements that could be dependencies in Gainsight. For example, I’d like to fetch the latest data into an MDA object from GCP using a connector, then fire off a series of rules, then run adoption explorer for that project, and trigger a data designer to run on that data, and so on.

 

coordinating the timing for all of these events so that they are all running off of the ‘right’ data, which can be dependent on rules running after receiving the newest data is a guessing game right now, and we cross our fingers hoping that the rule timing works as planned. If there are delays in rules running or upload issues with our connectors we run into problems.

 

Since we can’t make AE dependent on the connector running, we currently have about a week of no data because the data came in after the AE job ran, and our DD that allows us to report on AE in R360 (which is also irritating, yes we are on SFDC still) doesn’t have anything after the last date when we received data at the right time.

@rakesh FYI

100% supportive of this.

Amazing idea!
Coordinating scheduled times to pipeline different processes is a hassle. As Jason exposed, when one thing falls behind, there's no way to quickly realize that it affected something else downstream because they aren't actually connected. 

Just ran into this again today Our use case is that we have quite a few reports on a dashboard built off Data Designs. But in order for that Data Design to be useful, a certain rule needs to run first. I’d love to be able to just chain the two together for two reasons:

  1. To make sure the rule always runs before the Data Design when I schedule it
  2. So I can run it manually when needed with the click of just one button (rule runs first, then the DD)

YES!  My use case is even more complicated. :)

I kick off a program on Monday, and once that program kicks off, I want a rule to fire to change the status of a Success Plan. 

Then, on Thursday, I have a Data Designer that runs to grab those Success Plans and combine them with data from another object, and then, a program runs that sends that data in report.

Finally, on Friday, I have another Data Designer that runs to again merge in another object, a rule that fires following that to change the SP status again, and a program that sends that data in a report.

Any delay in any of these processes will cause downstream effects with the others, so it would be great to be able to tie them together so that they don’t run until the step before has been completed.

On a less complicated side, I could see this being hugely helpful even considering just JOs. (ex: new user communications, for both new companies who have just purchased, and mid-cycle users who gain access after the company is out of onboarding)

We have several programs that are launched in very short order after a user is provisioned. Some of those programs are based on events, while others are run off of a query (and still others are sent from systems outside our team’s control). Having these emails send in the wrong order (or on top of each other) doesn’t look good, but unfortunately they can’t all be part of one program -- nor would I want them to be. Having multiple programs allows us to be far more agile/swift if something needs to be updated.

It would be great to be able to string these programs together so we could better control how participants flow through their onboarding journey (and first year) -- essentially a JO journey builder.

Iirc this is on the product roadmap, hopefully someone from GS can confirm.

No Status→Acknowledged

My use case is similar to Spencer’s.  We have 2 Data Designers that need to run in sequence but after 4 different rules.  This is in support of a Digital Outreach Program.  We have several disqualifiers to the program sourcing data to the JO from Salesforce Opportunities and MDA Objects (Relationships, Relationship Persons).  Right now we have to run manually or trust predictable timing on the runs - which is hard to do during the morning hours with many rules\chains competing for rules-engine processing time.

Terms & ConditionsCookie settingsAccessibility statement