Data Designer should dynamically honor lookups between tables

When I merge objects in SF with objects in MDA, and those objects in MDA have lookups to other tables, it would be great if the Data Designer set would honor those lookups natively, without me having to add all the fields I need into the dataset - especially since DD is creating MDA tables for you.

For example:  I have merged Opportunity Product with Company which contains a mapping of Account::Account ID to Company::SFDC Account ID.  

Instead of pulling in Company Name, ARR, etc. from the Company table, why can’t the DD table honor the lookup to the Company table via the SFDC ID natively?


Oi - this would be extremely helpful functionality to have. +1

+1 agreed!

@minh_phan  @sai_ram may we get some detail on why this isn’t planned?  

One of the most difficult aspects of Data Designer is the fact that you have to manually add every single field you may need to use into the set, so if you want to be able to lookup to the Company table, for example, you have to select every Company field and pull it into your DD set - which can take up a lot of  the the 50-default limit field slots and results in duplicative data being stored in MDA.

It would be far more effective and efficient to provide the abiilty automatically establish lookups.

Would it really be that difficult to have a checkbox on GSID fields or SFDC ID fields that says “establish lookup?” and select and MDA table/field, and then inherits that capability?  You’re creating an MDA table - and MDA has the ability to perform lookups to other tables.  There has to be a way to do this.

Please reconsider this - it’s an administrative pain otherwise. 

@travis_floyd @heather_hansen  @keith_mattes your thoughts?

Likewise, I would like the ability to edit the DD table and add lookups manually if needed.  I basically have to build a giant flat table and merge in ANY data that I am going to need because I cannot configure lookups in a DD table.

One additional detail - when you have to manually select fields to which you need to lookup, and the designer set runs, it pulls the value of those fields at the run time.  This forces you to schedule all DD sets that require those fields to run at the minimum every 2 hours so that you have the most up to date information in that data set.   You still run the risk of having stale data, though, since it is not real time.

That is a side effect of the main issue though - the need to do dynamic lookups via DD sets would improve administrative overhead, data management and reliability.

+1 to this and any enhancements to DD 🙂 Standard Lookups as well as JOINS to DD Dataspaces would be the coolest!!!!


Um, yes!  I can’t tell you how many times I’ve built a DD, and then, had to go back and add more fields or add another object into the set because I didn’t get everything with the first pass.  Honestly, I thought it was just me.  :wink:

@heather_hansen  you are definitely not alone!!  :blush:


@heather_hansen not at ALL alone.  Happens to me regularly.  Spread the word to your other GS admin contacts and lets get this upvoted! :grinning:

@keith_mattes  @heather_hansen @travis_floyd Here’s the response I got from GS product.  I don’t quite buy it - but it is what it is:


“DD is architected and built to create flat sets that are very easy to understand and very fast to report on. It's not possible to have lookups again after the final dataset. It wouldn't work both at a data store level or at a reporting level. 

Doing that would require either a complete re-building DD from grounds up (very hard given the adoption) or a lot of effort to have a very limited ability to only have a lookup to Company with eventual consistency sync. The latter can cause a lot more confusion since it might take a lot of time to sync Company values to the new data store. I'd call this using a screwdriver as a hammer - we might be able to do it, we would need a lot of time to inefficiently solve this. It's not recommended and would distract us from the core mission of lowering the barrier to work with data - making data prep even easier and consistent across Gainsight.”

I can understand the potential complexity, but allowing JOINS in the resulting dataset AFTER a merge is created would be INCREDIBLY powerful.. and save Admins a TON of time … this would essentially be creating a Dynamic Data Designer Dataset (DDDD) and I’m trademarking that… 

Definitely +1 for us as well! @keith_mattes yass DDDD would be epic :joy:

Due to so many requests on this one, we will exolore technical viability on this. Do note that its not very straight forward and its very easy to introduce suboptimal solutions. Hence we might take some time on this one. 

Very happy to see this posted this morning!!!  While it may “disrupt” the traditional hub-spoke data model used in the MDA (all roads lead to the Company Object), the power behind this is immense.  And yes, also a bit “tangly” in the backend… should Gainsight ever want to review/consult with the Global Admin group, we can raise this as a topic and drive some feedback and ideas if you wish to partner. 


Allow data designer MDA to add lookup configuration with respective GSIDs to Company, Relationship, Success Plans and CTA objects. As we know DD are limited to 50 fields MDA, we could not build a solution having company or relationship MDAs all data. If Data designer MDA fields could allow edit to lookup additions will bring in more scalability of using it more than rules. 



Just adding a +1 to this!

This would be incredibly helpful to keep DD more simple and more powerful reporting!


+1000 running into this issue now. Would love not to add every field into my current DD or even have to create a new DD with ALL the additional fields that already exist in a related table.

 @rakesh we need a solution as this is one of the most frustrating aspects of Gainsight.

Today I ran into a situation (that I’ve run into many times before, but I didn’t create this DD set, so I wasn’t aware) where I needed to map a Global Dashboard Filter to the CSM Manager GSID.  The field wasn’t showing up in a couple of instances and I discovered that the CSM Manager GSID in one of our DD sets was being rendered as a Text field.


This was because of the apparently limitation where you cannot traverse lookups more than 3 layers deep… so in the DD set, CSM Manager GSID was being sourced from Call to Action → Company → CSM → Manager (lookup) - which by the way IS an ID field in the source:


This is going to force me to add yet another dataset task to a DD set already made up of 13 tasks, just so I can pull in Manager GSIDs… this is just such a cumbersome feature to use.

Adding another vote for this, would great increase the utility of DD for using in reports and dashboards!

Here’s that the Data Designer Templates isn’t the “solution” to this challenge, because all that does is potentially expedite building a DD set… it does nothing to solve that fact that DD is still creating duplicate copies of data fields that have to be regularly refreshed and have a high risk of being out of sync across DD sets.