In this movie, I’ll walk you through the basics of setting up your Fusion account, adding connectors in the Fusion portal, mapping your systems, and how Fusion builds your unified data warehouse. By the end of this video, you’ll be an expert in everything from schemas to custom fields.
Which will look a lot like this. And right now, my dashboard is empty. But you can see that from the dashboard you would be able to see quick stats about your warehouse, the connectors you’ve installed, and a link for fetching your warehouse credentials in the bottom left-corner.
So all I need to do here is click Manage Connectors, right here, and that will bring me to a screen that lets me choose my connectors.
And so from this left-hand side I can filter based on the category.
On the right, I can select a connector.
And keep in mind that Fusion is always adding new connectors, so in case you don’t see one of your systems there, it’ll likely be there soon.
And let’s just say I click on Salesforce.
Fusion’s going to want me to authenticate my system. So all I have to do here is sign in.
And assuming you have your credentials, just login as you would normally, and doing so will add that connector to Fusion by authenticating your system.
Now in this example I’ve chosen Salesforce. But the same process would apply for a HubSpot or Marketo, or a Quickbooks or Zendesk connector. So what this step accomplishes is to give Fusion the basic ingredients for ingesting all the data via your systems’ APIs before going ahead and building your cloud data warehouse.
So in this example, I’ve authenticated both Salesforce and HubSpot here. And if I want, I could add multiple instances of either, as well. Which is great if you have a sandbox or dev account you want to play around with first. And if I ever want to get rid of that connector, I can just remove it, like so. And that’ll remove the connector from my account.
But that’s not the only thing you can (or should) do before Fusion builds your cloud data warehouse.
Fusion also maps objects for every connector. Meaning if you have a system with a Contact object and a system with a Lead object, the two are linked together according to specific field names, depending on the schemas of each system. And whenever a cloud application changes its schema or updates its API, Fusion is right there with it. So you don’t have to re-write code or troubleshoot.
Now the value in having objects mapped and a unified schema built for you is that every system has its own schema. My CRM might call contacts a “lead” or “person”, and tether its schema to other objects like company, opportunity, or interesting moment. Meanwhile, my marketing automation system could use “Lead”, “Contact” or “Account” and tie those objects to campaigns or tasks. While still others could call these objects “Users” and map them to organizations and tickets.
And because this quickly becomes a huge, huge mess, Fusion creates a default universal mapping, which is a lot simpler and makes doing analysis far quicker because you no longer need to figure out which fields to join or read API documentation on what they’re called.
And that’s because Fusion’s universal mappings make Contacts and Companies the two big objects, common to every system, and matches the like objects together into categories like Opportunities, Activities, Tickets, Orders, and so on. We’ll delve into why this is so helpful a little more in the next movie, but I just want you to see how Fusion collapses this complexity so you don’t have to worry about data prep or having to get in touch with IT.
As an example, you could have a field named hubspot_contact_first_name and netsuite_lead_first_name. Well Fusion knows how these two are mapped together and fuses the two fields into one table in your fused warehouse called fused_contact, under the field first_name.
Such mappings make storage more efficient and give you a much simpler blueprint of all your data, so that querying and visualizing customer information is much easier to find and experiment with in your BI tool of choice.
Now while Fusion boils many schemas down to one for me, let’s say I want more control over how my fields are mapped. Well Fusion also gives me the ability to customize my mappings from right inside its UI.
All I would need to do is go to my Schema tab create a custom field by selecting an object type — like Contact — as shown on the left here — although I could also choose Opportunity, Activity, or any other object.
Then I want to type what the custom field that the two systems share is, which in my case would be Lead Source, which again, I typed in since this is a custom field.
And now I’ll specify what my first system is. Here I’m going to mark Salesforce, which I already know has a field called Lead Source,which has a dependent field called Lead Source Detail. And since all those lead source details aren't by default in Fusion’s universal mappings, they make ideal candidates for custom mappings.
The final step, then, is to add the system to which I want to map the Salesforce Lead equals Lead Source field. And in my world that’ll be HubSpot, which I’m going to tie to the Contact field, which has its own custom field of SFDC Lead Source.
So what I’ve done is mark Salesforce with Lead and Lead Source, defined how my instance of HubSpot records the contact field as a lead source, so that the two systems can be neatly tied together for my reports.
And now when I click save on these preferences, Fusion is going to ask me whether I want to rebuild my warehouse to reflect that I’ve either changed or added a new mapping. If I click “yes”, Fusion will simply rebuild my warehouse for me and I’ll get an email telling me when it’s ready.
Now important to note here is that I can refresh my schema at anytime, with or without having altered my custom mappings. And after Fusion’s rebuilt my warehouse, I don’t have to do anything. When I go into my BI tool, I’ll be able to see those updates to my data and analysis in real-time. So any queries or visualizations I’ve done I can save and just refresh in whatever analytics tool I’m using.
So just to reiterate: Fusion maps all your objects and fields by default. But if I want, I can pick any pair of systems and fields, establish a connection between them, depending on what they’re named, and just save those settings if I’m happy with it, and let Fusion rebuild my warehouse tables and schemas.
So the beauty of creating a Custom Mapping is I now have infinite, boundless flexibility to personalize my data the way I want, and ensure that it fits my own team’s or organization’s needs.
OK so what else does Fusion do when building my cloud data warehouse?
Well, Fusion also translates the data in my fields and tweaks them so they’re all in a uniform, standard format.
What this means is Fusion automatically matches the data type for each field in my application, which could be a Unix date format in numeric form, or a Deal Stage Value as an alphanumeric hash. It doesn’t really matter what the field’s data type is. What does matter is that when I go to run my reports, I’ll never have to mess around with having to convert Unix date formats into UTC myself. Or editing the alphanumeric hash into plain English. Fusion does all this for me automatically by the translating the data.
And there are a lot of examples of this. You could have phone numbers that use dots or dashes. Numbers might use 0.5 vs. .5. States and countries use different abbreviations like U.S. and U.S.A. or United States vs. United States of America. Fusion takes care of boolean fields, capitalization issues, duplicates, and conflicts.
But, as the name implies, Fusion does more than ingest data, clean data, and customize my mappings. It actually fuses the records as shown here.
So if I had two records for the same thing, like a person or company, Fusion will match on a particular key. In this example, we have an email, email@example.com, that Fusion recognizes.
But I don’t want a null value, so Fusion fills in the Lead Source as webinar. I also want to know what company he’s associated with, so that’s included as well. And if there were any duplicates or conflicts, Fusion would purge those also.
By the end, I’m given a single identity of Joe Shmo -- his name, email, company, and lead source. Which means I don’t have worry about which of my Joe Shmo records is more accurate, complete, or up-to-date, because Fusion uses the last modified record for populating my warehouse.
In the next movie, I’ll go over how this quick and easy setup will accelerate your analytics by looking at how to connect your warehouse to any BI tool of choice, then run a few SQL queries and visualizations using my very own fused data.