How to Sync Data from Your Database into Salesforce in Under Two Weeks
Every company with a digital product wants product data flowing in their CRM. I’ll show you the absolute fastest and most sustainable way to get this done (using Salesforce as an example CRM). First, some common questions:
“What is the best way to get this data into Salesforce?”
“How long will it take to get it all syncing?"
Like many things, it’s a bit like asking “How long is a rope?”
Want a benchmark? Two weeks.
Impossible? I’ve done it before. Twice. Here’s how:
1) CREATE A STRATEGY FOR EACH KIND OF NEED
Take stock of the jobs to be done in Salesforce: the processes people are using the tool to accomplish. You absolutely need to know where these processes are growing in the next 6 months and the difference between nice to have and need to have during that time span.
THEN, for each process, ask “if something happened in my product, and the user didn’t see it in Salesforce, would this process fundamentally break?” If a process is fragile, try to figure out the minimum information a Salesforce user would need to know to prevent it from breaking. Next, referring to your list of fragile processes; categorize every data point on your wishlist to be synced. Mark each as one of the following:
Process Breaking // Helpful to a Salesforce Process // Used mainly outside of Salesforce
Process Breaking data points, per above, could be things like knowing a customer has Churned, or that a Default Contact information has changed. If Salesforce doesn't know that this happened in-product, your team will likely make flat out mistakes.
Helpful data points are things like an Account's billing status, number of users, tier, etc. They might help your team adapt the work they are doing in Salesforce to be more effective, but they don’t always need this information. They can use Salesforce to do their work without looking for it.
Outside of Salesforce data points are things like Account configuration, Settings, etc. You need to know this about your customer, but not for a process/event handled primarily in Salesforce.
2) SET THE FOUNDATION & PREVENT BROKEN PROCESSES
First, set up your MVP object model. Ask your engineers to build a one direction, real-time sync from their database to the core objects in Salesforce (Accounts, Contacts, maybe Opportunities or any custom objects you’ve made). Don’t outsource this code. This is your slowest step, so you want to get it going as soon as you can. You’re aiming to make this something they could deliver in two batches, in under two weeks.
For now (Batch One), each object just needs to sync a name and their own object ID (in an ‘External ID’ field). They should consider this a very small ask. Don’t sync everything the database knows, tell them you’ll add the most important fields in Batch Two.
As they are working on Batch One, start to define Batch Two. Take all the process breaking stuff, and nothing more, and add it to a list to be synced as it is updated. Make sure fields exist in Salesforce for it all to live in. Convey the severity of this data in your requirements: it is all vital to avoiding treacherous operational mistakes in Salesforce.
The better job you have done in making the Process Breaking list as small as possible, the faster your Engineering team will take it on, and the faster they’ll ultimately have it done.
Once they’re done, in Salesforce, mark any synced field (particularly your database IDs) as ‘Read Only’. The Single Source of Truth for these fields is now your Product, not what your team has entered. *note - single source of truth is a term that gets frequently misused. It should always be data-point specific and not platform-wide. You should never say “Salesforce is our single source of truth for everything”.
Next up, what to do with everything else?
3) EMBED HELPFUL & FREQUENTLY NEEDED INFORMATION
Process is better when it doesn’t require forensics, so do what you can to avoid making people go look for stuff to get something done. But let’s assume people will still need to go find frequently useful information. We need to make it easy & efficient to find.
To do this, first set up a BI tool like Looker or Periscope, and build a dashboard for all the data you marked Helpful. Set up your dashboard to accept an object's Internal ID via the dashboard URL, or a filter. Verify that you can see the data about one object, be it one Account, Contact, Deal, whatever.
Then, on the object in Salesforce, and add an Iframe to hold your dashboard. Pass into that Iframe the dashboard, and specify the ID that your Engineering team synced down onto the object. If you can’t embed, build a clickable link with the ID. Here is the embed documentation for common BI Tools:
Voila! You’ve got all the helpful data you need, directly in that Object’s page in Salesforce. You can see some example/screenshots above. If you get lost, reach out to me for help.
4) MAKE WORKFLOWS OUTSIDE OF SALESFORCE WORK WELL
When you’re a hammer, everything looks like a nail. Don’t insist on “Salesforce-ing” everything just because data is syncing there. Use whatever tool makes sense for the job to be done. For example - Asana or Trello might be your best bet for managing projects, and Zendesk or Intercom might be your best bet for supporting customers. Think outside of the box about how to get the right information syncing to the right places at the right time, for example:
Use Zapier to sync data from Salesforce into Asana tasks or anywhere else
Use Zendesk’s Salesforce integration to make sure customer service agents with shared inboxes have access to synced data
Schedule an exception report: a report of problems your BI Tool or Salesforce can look out for, and email you when it finds them
Use Troops to update other teams in Slack when important outcomes or milestones they should know about are reached
Create plenty of small, fast loading dashboards, with quick links to them in the places people might need them. Remind the team to bookmark the ones they refer to frequently