Hi James, Hope this articles will help you to resolve your use-case. 





If this din't work please let us know.always ready to help!

---

Hi Jim.  I believe that you are talking about having multiple Relationships, one for each product, show up in the Relationship Card View on C360.  (The word "Relationships" can be substituted for another term so in your case you might very well have a Product Card View.) The short answer is that if you create one Relationship per product (or product instance*) then they will all appear there.  The Card View is a kind of mini-R360; you can choose which fields show up.  The configuration is per Relationship Type.  





On the second part of your question, about filtering out certain Relationships based on a field -- so you only see things that aren't expired or whatever -- this is, candidly, something we should support but isn't there at this point.  It is absolutely coming. 





(*) One quick comment about Product vs Product Instance: I suggest that you think this through if you haven't already. While having multiple products for sale is often a reason to model thins with Relationships but the potential for a single company to buy the same product more than once is another good reason to have multiple Relationship records. Whether two deployments of a product should constitute one relationship or two depends on the business -- do the two deployments succeed or fail together or are they separate?


 

---

Sai-





Thanks for the article.  Unfortunately it wasn't detailed enough for my use case.





We have Relationships set up, and data flowing in from SFDC.  Right now we have a singular Products Card on the C360 that populates data for all three of our Products.  





Is it feasible to have three unique Product Cards, with product-specific data in each?  Or is it only possible to have one Product Card in the C360 for all different products?





If it's feasible to have three unique product cards, is there documentation on how this is accomplished?





Thanks





-Jim

---

Hi Karl-





Question 1: Absolutely nailed it.  We would like to only show appropriate data for Product 1 in Product 1's C360 Product Card View, etc.  Thanks for clarifying that this parsing is feasible.  Time for me to try and decipher how the Relationships are configured so I can create multiple Relationships and limit the relationships to the appropriate product.





Is there any good documentation for this use case?





Question 2: Thanks for clearing that up.  My manager has been asking me if that's possible, and now I have the answer.  As a follow-up, is there an ETA with your product roadmap for this functionality?





Thanks again





-Jim

---

I will point you to some docs but as a first step, please be sure to reflect on the notion of Relationship Type.  With the Relationship Type you specify what data you hold about the Relationship (in the form of fields on the Relationship and associated objects) as well as things like R360 and 'card' layouts.  You can also define different CTA types and Rules per Type.  In your case, if your products are very different from each other -- e.g. one is subscription and so you need to track renewal dates but another is perpetual and so has a different set of things going on -- then you may want to have multiple types . Based on what you have said so far, my hunch is that you are fine with having just one Type and use it for all products.  This does not mean that you only have one 'Card' per customer.  It means that each Card has the same fields on it. 





Of course, you already have a Relationship Type, since you already have Relationships!  This may need some modification since going forward you will want to capture which product it is for (since it will be for only one at a time, not all products at once) and, most likely, an instance ID or something like that.  





Once you have the Type, creating multiple Relationships is actually the easy part.  You can even just click the +Relationship button on the C360 and fill in the info and, bingo, another Relationship. Doing this at scale means creating or modifying the Rule that creates Relationship records.  Most likely, you want to create one Relationship for each Instance of one of your products. 





Regarding the filter capability timing: I will try to get a good answer and get back to you.





Here is a good doc on Relationship Types





https://support.gainsight.com/Product_Documentation/Customers_and_Relationships/Admin_Configuration/...





Here is an article about creating Relationship records


https://support.gainsight.com/Product_Documentation/Customers_and_Relationships/Admin_Configuration/...





Let us know how it goes and if you need additional help.

---

Thanks Karl.  I'll continue thinking and working with this.





Management (in an ideal world) would like to have one card for Product 1 [with P1 specific data], one card for P2 [with P2 specific data], and one card for P3 [with P3 specific data].





It sounds like our current setup is the standard use case (one product type in Admin/Relationship Configuration that applies to all products), but because of management's request we may need to create individual Relationships for each product to satisfy the P1/P2/P3 card request.





-Jim

---

Important point here:  to have three Relationships, you don't need to have three Types.  You can have a single Type with a field called "Product" and just fill in which product the Relationship is for.  You may have a reason to have separate Types but nothing about what you have said so far implies that.  I strongly urge you not to go ahead with multiple types until you have experience building multiple Relationships on one customer of the same type.  If you have that all under control and find that you want very different things for the different products, then you can consider additional types.  But *don't* start there.

---

Here is an example from our demo org of two Relationships of the same Type on the same client.  In this case, they are related to the same product being bought twice by the same customer.  But it could also be that you model deployments of two different products using the same Type. 

---