Skip to main content
Solved

Advice on Shifting from 1 Relationship Type to Many Relationship Types

  • August 9, 2023
  • 2 replies
  • 32 views
jessicatang
Forum|alt.badge.img+6

Looking for some advice and guidance on shifting from 1 relationship type to multiple relationship types.

Currently our instance is set up with 1 relationship type of Product with 7 relationships tied to it. However, we are considering moving those multiple relationships up to the Type level. So instead of only Product, we would also have MTG, IES, COML, PARTNER, etc. 

Has anyone done this or have any helpful guidance on how to do this successfully?

We are interested in shifting because of the the diversity of the processes among the teams that use Gainsight and would like a unique page layout for the CTAs for each of these teams.

 

Best answer by spencer_engel

Just based off your description above, I think you’ll find that creating 7 different relationship types is going to be way more work than its worth if all you really need is a different CTA layout. Consider that you will need to maintain 7 different R360s, 7 different scorecards, 7 different types of “load to relationship” rules, etc. Typically if your relationships fit into one tidy umbrella (in your case, “product”), it is much more preferable to just keep that one relationship type.

 

You can always separate the CTA types instead if that’s your main use case - e.g. perhaps have a “Lifecycle - MTG, Risk - MTG, Lifecycle - IES, Risk - IES, etc.” type of thing. That’s also quite a bit of overhead, but significantly less than if you were to separate all your relationship types.

2 replies

spencer_engel
Forum|alt.badge.img+5
  • spencer_engel
  • Expert ⭐️
  • Answer
  • August 10, 2023

Just based off your description above, I think you’ll find that creating 7 different relationship types is going to be way more work than its worth if all you really need is a different CTA layout. Consider that you will need to maintain 7 different R360s, 7 different scorecards, 7 different types of “load to relationship” rules, etc. Typically if your relationships fit into one tidy umbrella (in your case, “product”), it is much more preferable to just keep that one relationship type.

 

You can always separate the CTA types instead if that’s your main use case - e.g. perhaps have a “Lifecycle - MTG, Risk - MTG, Lifecycle - IES, Risk - IES, etc.” type of thing. That’s also quite a bit of overhead, but significantly less than if you were to separate all your relationship types.

jessicatang
jessicatang
Forum|alt.badge.img+6
  • jessicatang
  • Author
  • Contributor ⭐️⭐️⭐️⭐️
  • August 10, 2023

Just based off your description above, I think you’ll find that creating 7 different relationship types is going to be way more work than its worth if all you really need is a different CTA layout. Consider that you will need to maintain 7 different R360s, 7 different scorecards, 7 different types of “load to relationship” rules, etc. Typically if your relationships fit into one tidy umbrella (in your case, “product”), it is much more preferable to just keep that one relationship type.

 

You can always separate the CTA types instead if that’s your main use case - e.g. perhaps have a “Lifecycle - MTG, Risk - MTG, Lifecycle - IES, Risk - IES, etc.” type of thing. That’s also quite a bit of overhead, but significantly less than if you were to separate all your relationship types.

Thank you so much for your insight. I will definitely keep this in mind as we discuss the path forward. 

Terms & ConditionsCookie settingsAccessibility statement