header
Not Planned

Data Designer should dynamically honor lookups between tables


Userlevel 7
Badge +2

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?

 


13 replies

Userlevel 5
Badge +1

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

Userlevel 4
Badge

+1 agreed!

Userlevel 7
Badge +2

@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. 

Userlevel 7
Badge +2

@travis_floyd @heather_hansen  @keith_mattes your thoughts?

Userlevel 2
Badge

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.

Userlevel 7
Badge +2

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.

Userlevel 6
Badge +1

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

 

Userlevel 7
Badge +2

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:

Userlevel 6
Badge +1

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

 

Userlevel 7
Badge +2

@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:

Userlevel 7
Badge +2

@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.”

Userlevel 6
Badge +1

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… 

Userlevel 6
Badge

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

Reply