ETA on Data Spaces that include/join MDA data?

Great question and lots to unpack here.   First, let's observe that Data Spaces (as we have them today) has power from two directions: first, it gives a way to combine ('join') data across multiple objects and second it let's you create a kind of virtual object with just the fields that you want.  Of course, today it does these two things only for data in Salesforce.    

When we talk about extending Data Spaces to MDA we could be talking about two different things -- either (1) creating a Data Space where all of the underlying data is in MDA or (2) Data Spaces that combine data from MDA and Salesforce.  (Actually, it is even slightly more subtle than that, as I will mention below.)  

When all of the data is in MDA, we today have a feature called 'MDA Joins' that does let us combine data from multiple objects.  So the recommended path for what you want to accomplish today would be to create a new object in MDA and populate it with the customer level information that you care about using the Rules Engine.  By using MDA Joins you can join this new object with your usage object.  That will let you create the report you want. 

Going forward, there are two roadmap items that will help.  First, we are working on 'Standard objects in MDA' that basically automates the step of creating the object and populating it with Rules Engine as described above.  So reports on MDA objects that you want joined with Customer or Relationship fields should be available more or less out of the box.  Second, we are looking to extend the Data Space concept even across MDA and Salesforce.  The thing is, joining across two separate data stores can't be done in real time.  So we will introduce the concept of a Materialized Data Space (this is a database tech term....may have a different name when we actually do it 🙂.  This would pre-compute the joins to make them available for reporting.  Details aside, the end result will be that you will be able to do what you can today with Data Spaces with objects across MDA and Salesforce but things will not be totally real time.  In terms of timing, the standard objects project is well underway so that is coming pretty soon (though the roll out will be slow since it is a big project).  Materialized Data Spaces won't come until after Bionic Rules is out and stable (Materialized Data Spaces will use the same tech as Bionic Rules). 

Finally (if I haven't confused things too much yet!), let me return to the comment about things being 'more subtle' than I suggested in my earlier comments.  (Note that some of this is under the covers stuff that you shouldn't need to worry about but I am sharing for interest.)  The thing is, MDA is actually not just one data store.  We use multiple data bases like Redshift, MongoDB, Postgres and more.  'MDA Joins' actually only works today when both objects are in Redshift.  Going forward we are going to need to continue to leverage many databases (we have a very broad product and different parts need different infrastructure to make them work) so the need to combine objects that reside in different databases is not just an MDA vs Salesforce thing but actually comes up [i]within MDA itself.  So the need for Materialized Data Spaces will be all over the place.  My vision is that Data Spaces will become effectively a virtual object layer that sits on top of the polyglot infrastructure so you can use data without worrying very much about where it is.  We can also offer things like summary fields and drill through.  Lots of work to get there but I am excited (REALLY EXCITED) about where this can go. 

Hope that helps.

-Karl

Karl,

I have a few follow up questions. 

• Is the plan that Standard Objects in the MDA are only going to include GS objects, Customer Info, and Account (similar to how they look up in SFDC)?
• Any rough ETA on when this functionality will become available (std objects)?

Thanks,
Steve 

Initially, standard objects will be Company and Relationship.  Early access expected next month.  Full release target for Winter. 

Hi - I want to see if our use case applies back to the original question as I think there is still a need to include MDA tables in the data space functionality. For us, it's not just a simple matter of joining one table to another. We bring in a lot of data for multiple sources. I am working on a project now where we want to include information from 5 or 6 MDA tables and SFDC objects in a single email to our clients to provide some insight into their utilization of their project. Data spaces would help to consolidate that data without having to create yet another MDA to pull it all together. I don't think in this case, a join will really work. Is there any plan to revisit making the MDAs available in data spaces?

Let me separate a couple things.  First, we are currently working to figure out how much value there would be in offering Data Spaces within MDA itself.  This itself would not include data from both MDA and Salesforce in one Data Space but could make it simpler to work with MDA data as you add a layer on top of MDA joins and select exactly the columns that you want.    Any opinions on that?  Regarding a Data Space that is *across* Salesforce data and MDA data, this isn't ready but the main technology is -- Bionic Rules.  You can combine data across data stores in a Bionic Rule and then take actions.  To generate a report, you do need to write the data out and then build the report on the new table, so there are still multiple steps.  Note that a Bionic Rule can take a while to run so it wouldn't be feasible to do the calculations on the fly when rendering a report, which is why the intermediate table is required.  The vision for Data Spaces described above is to basically hide the Bionic Rule and intermediate table from you and just do it all in the background and make it accessible as a 'materialized' (that is, pre-computed) Data Space. 

Thanks for clarifying, Karl. I think what I struggle with even with the Bionic rules and the intermediary table is the need to continually replicate data we already have for the purposes of making it work together. We end up having to create MDA tables upon MDA tables, etc. so that we can use the data for reports, email campaigns and so forth. Each new manipulation / iteration makes me uneasy about the loss of data integrity as we feed data into table after table. We also have to run rules continuously to keep the data current. What I would rather see is something that serves more like an Access Join table where we only need to have the IDs mapped across tables to connect them and have them work together. I hope that makes sense.

To your question about MDA-only data spaces, I can't see any uses cases, personally, for our data with creating data spaces across MDA unless we are also including the native SFDC.

This does make sense.  Thanks.   For small-ish volumes of data the approach you suggest is feasible.  As usual with reporting, once data volumes get really big, it is necessary to prepare the data somehow since it takes too long to make all of the calculations on the fly. The approach we have in mind is doing the data preparation for you, essentially, so you aren't writing a ton of rules.  But have a mode where it happens on the fly when that makes sense is also totally sensible.  We still have plenty of work to do here 🙂.  But hopefully the steps so far, such as Bionic Rules, are proving helpful. 

I would love an update on this one. I am trying to draw a correlation between Customer Health, NPS submission, and CSAT (tech support) submission. Health is MDA only and the latter two are in Salesforce. Thus, I cannot compare across those parameters.

Given that Bionic Rules are pretty well set, is the "Materialized Data Space" concept anywhere close?

Thanks for asking.  This is a a very hot topic for us but unfortunately I don't have an ETA on delivery.  While not as slick, you can of course build an MDA object and then populate via the bionic rule every few hours or day or whatever.  Basically, build out the materialization yourself. 

Thanks Karl. I am fine with that alternative, but have never done it myself. Is there a workflow page for that process?