Rule Chains in Rules Engine

When creating rules, it would be great to be able to put them in a Rule Chain from the rule itself instead of having to go back to the repository and create a rule chain.

Also, I'd like to be able to see from the Rules Engine that a rule is a part of a rule chain. Below is a screenshot of a rule in the Rules Engine Repository that is a part of a rule chain, but there is nothing indicating it is a part of a Rule chain:

Good feedback, Lane.  I've heard similar statements from my customers who are using rule chains.  Would be good to include a search option within the Rules UI to show rules used in a chain as well as reference the chain they're used in.
Lane - With our next release (post Pulse), Rule chain name will be shown in the rule listing screen. 

Great feedback on adding the rule to a chain as a step.

Scott - Added the search option into backlog.
Related, I'd love to be able to put a rule into multiple chains. We have several rules that need to run on different schedules and I think with chains it may be unnecessary to duplicate them for each sequence.
Jeff - Can you brief what kind of rule needs to run multiple times a day?
We have a rule that identifies opportunities that are closed and need to be onboarded, followed by rules for notification to the appropriate teams. For transactional deals we do that in the very early morning to pick up APAC and EMEA, and then twice more during the US day. You could "fix" this by allowing for more frequent scheduling as well.

I have another rule that is loading data to create user health scores and I basically have a "reset everything" rule that could be used twice if available.
Thanks Jeff. Sounds like there is long term value in allowing a rule to be in multiple chains.

reg running rules at higher frequency:

We are working towards it in multi-step. First step would be rule chains(done) and then parallel run of rule chains and as final step we would enable increasing the frequency of the rules.

Some background on why rules are not allowed to run at higher frequency:

As you know all the rules (for each customer) would run in a sequence defined by the scheduled time. This is essential and it causes the total time taken to complete all the rules anywhere from 1-8 hours. The long running rules for most customers is influenced by the SFDC API response time majorly among other reasons, and thats not within Gainsight's control. By increasing the frequency of rules this will increase to unmanageable levels (greater than 24hrs).

Why doesn't the rules run in parallel now? 

We can't have the rules read / write into the same object and if we have to support then heavy instrumentation should be done in Gainsight's platform which is the second enhancement I mentioned above. 

The roadmap would look like this

  1. Rule chains to run in parallel with inbuilt protection (No read/write on same object simultaneously)
  2. Rules can be scheduled to run at a higher frequency. 
Also, for your reset everything scenario we would have a better way of handling it in May release (Set score to X when data is not available for some accounts)
Thanks for the detailed reply. Very helpful to understand this better!
Agree with this feedback. It would be much easier to navigate the Rules Engine if the rules that are grouped via a 'Rule Chain' are able to be viewed as a rolled up group (similar to how tasks are a drop down of an objective).
Agree. With Rule chains, it also doesn't show the scheduled time/date (on the far right) that the rule should run. I feel there should be a "chain" image or something that represents rules have been linked/chained.
Hey Johnny - You should be able to see the rule chain name along with the rule name which indicates that a rule is part of a chain from July release.

I agree with the next run datetime part, it would be useful to show that.

This would be FANTASTIC. Less clicks, easy. 

@gunjanm I think rules list already shows rule chain, are you looking for any other request here?

@sai_ram it does not show the event triggered rule chain in queue. I went through an unnecessarily long support ticket only to find that it's expected behaviour and needs an enhancement request.