Admin Training Corner Series - Rules Engine

  • 26 January 2023
  • 8 replies
  • 121 views

Userlevel 6
Badge +7

Hello Gainsight Admins!

As we continue to dive deeper into our Level 1 topics, let’s talk about Rules Engine.  Rules are considered the brains of Gainsight because they manage activity.  But to take action, you must first identify a data set (set of records) to take action on.  

When selecting records for action, there are many ways and tools to utilize.  We are able to select records from various sources, utilize transforms and pivots to aggregate the data, and merges to join datasets together. Once you have a record set, there are numerous actions that can be taken.

This group was created as a safe space to learn from each other.  Tell me:

  • How did you solve a challenge you had designing a rule?
  • Is there a tip you have to share with our group?

Here’s my tip:  When designing a rule, always map it out first starting at the end and work backwards.  Identify the fields you need to take the action desired and work backward to develop a recordset with the needed data.

Also, did you know there’s an Admin Office Hours that is hosted by some of Gainsight’s most experienced technical resources?  Bring your configuration or best practice question to the Office Hours to chat with an expert.  Don't have a question yet, join to learn more about questions other admins bring to the session.  It’s a great learning opportunity!

If you’re just getting started learning about Rules Engine, check out this online training in Gainsight University,

 


8 replies

Userlevel 7
Badge +6

My tip is that I need an explicit reason not to do a Left Join. On the ‘left’, I have my primary list of the records that matter, where I want all of them to make it all the way to the end of the Bionic query. In the case of a Rule (instead of Data Designer or Journey Orchestrator), what matters is basically a list of Companies. Then I’m hanging additional information about those companies off the ‘right’ side of that table, like every new column I’m tacking on is a new Christmas tree ornament.

That way, I know that I’ll make it to the end with all the company records, even if there are some that don’t have any of that ornamental data. My data set will cover our entire customer base, guaranteed.

One caveat:

Sometimes I know that I won’t need all the company records, like if I want to trigger a CTA for people with a certain NPS response. (If a customer has no NPS response, I couldn’t care less about that customer for creating these CTAs.) That’s when an inner join lets me instantly throw away all those extra company records in the data. Less data makes the Rule run faster.

Userlevel 7
Badge +9

My pro tip involves labeling parts of the Setup Rule by letter, so I can keep the tasks organized.

I prefix each of my tasks with a letter, because

  • When I want to merge or transform, it’s much easier for me to think “Merge A and B with a left join” than using the full names. (It triggers childhood model-building memories of inserting Tab A into Slot B.)
  • It’s much easier for me to find the task in the “left listing” of tasks. I look for a leading letter instead of parsing the entire task name.
  • If I have to troubleshoot, or if I need others to troubleshoot with me, I can share, “I’m having trouble with Task D” and it’s really clear where to look.
  • When I get to Actions, it’s easier to find the desired dataset in the dropdown.

Folks who have administered with me, or after me, will find these “fingerprints” I’ve left behind.

 

 

Userlevel 6
Badge +7

@matthew_lind and @seth you guys are killing it here with strong tips on merging.  I 💙💙💙 it!  Thank you.  cc: @vgaurav @bholmes 

Badge +4

My pro tip involves labeling parts of the Setup Rule by letter, so I can keep the tasks organized.

I prefix each of my tasks with a letter, because

  • When I want to merge or transform, it’s much easier for me to think “Merge A and B with a left join” than using the full names. (It triggers childhood model-building memories of inserting Tab A into Slot B.)
  • It’s much easier for me to find the task in the “left listing” of tasks. I look for a leading letter instead of parsing the entire task name.
  • If I have to troubleshoot, or if I need others to troubleshoot with me, I can share, “I’m having trouble with Task D” and it’s really clear where to look.
  • When I get to Actions, it’s easier to find the desired dataset in the dropdown.

Folks who have administered with me, or after me, will find these “fingerprints” I’ve left behind.

 

 

THIS is an AMAZING tip!!! LOVE it. Thank you

Userlevel 7
Badge +9

Thank you for the kind words, @ahollen. There’s always so much knowledge to pick up from our fellow admins and experts.

Userlevel 5
Badge +3

@matthew_lind -- Love this! (just discovered today)

I’ll absolutely be using this in new programs moving forward.

I don’t have a screenshot to share, but as I’m thinking about the possibilities in the Advanced JO Program tool (as we start using it), I’m thinking back to what our consultants (Tegrita) advised us when I was using Oracle Eloqua years ago when we were building programs with multiple paths based on conditional waits:

  • Audience bucket = 000
  • Second level of steps (if sending two or three emails) = 101, 102, 103…
  • Third level of steps = 201, 202, 203
  • and so on…
  • Exit = 999

Hopefully there’s no need to ever go past 9 emails in a single journey… 🤣

Userlevel 7
Badge +9

@dayn.johnson I’m so encouraged to read this.

Naming conventions in Gainsight are a great best practice that keeps the long-term health and maintenance of your instance in-mind. And...inevitably someone else will join your team, and an intuitive instance advances them to productivity so much faster.

I love that Eloqua naming schema as well. Thanks for sharing!

Userlevel 5
Badge +3

@matthew_lind Thanks for the response, and absolutely on sharing the Eloqua naming schema. After playing around a bit with the new Beta Advanced JO Builder, it looks like the perfect place to start dropping those numbers in, as it’ll be really easy to build out expansive canvases for programs with multiple paths running in parallel. I don’t have an example yet, but I’ll be sure to share a screenshot (shots) here.

My other Eloqua-era tip for building those canvases is to take the additional time to organize your canvas so it flows naturally (and orderly). The canvas seems to be able to expand out (not sure how big yet), but it doesn’t hurt to give yourself some space so you can see the paths easily.

And… I went ahead and put your advice in place on the one semi-complex merge I’ve got in an active program that I could think of off-hand. 😀

Definitely makes it easier to read the logic flow for the company employees who receive our newsletter:

  • A - pull employee contact records
  • B - match them to the company record
  • C - merge the company data with the employee records
  • D - grab an AB testing value (only needed because other queries pull it for external users)
  • E - merge the AB testing value with the employee records

 

Reply