Talk Summary

In this quick tutorial, partner engagement manager Zach Behrman describes how to push data from Salesforce into an external platform. Based on the use case of an client, this demo describes how to identify data fields to link from Salesforce to an organization's database. Behrman creates a sample package, saves and validates the package, and makes it available to run on a regularly scheduled basis. To learn how to push data into Salesforce as a part two to this talk, view Zach's talk here

This talk will interest anyone who wants a single source of information for their organization and wants to develop an automated, regularly scheduled sync of Salesforce and an internal data source. The process is easy to follow and accessible to anyone who has to ensure data consistency. This is achieved through the platform, without investing in developer resources. The video serves as a simple introduction to the platform and acts as a go-to reference for experienced users.

What You Will Learn

  • Case study of a user who wanted consistency between Salesforce and internal platform [00:00:44]
  • Using to push data from Salesforce to the internal platform [00:02:03]
  • Choose data source properties from Salesforce [00:03:04]
  • Choose database destination on internal platform [00:05:34]
  • Merge data with platform table [00:06:00]
  • Populate the database fields [00:06:29]
  • Save and validate the package [00:07:44]

Full Transcript

[00:00:15] Hi there. My name's Zach Behrman, I'm the partner engagement manager at Today I'm here to talk to you about bi-directional sync to Salesforce from an external platform. We often see use cases where companies have adopted Salesforce and want to drive further and further to it being their single source of truth for the organization. That can bring about some challenges with multiple disparate systems holding data, and very often with a software as a service company, some of the most valuable data about their customers can be within their own platform.

[00:00:44] I had a recent experience similar to this with an user that, for privacy's sake, we'll call Trent. Trent had recently taken a new position as a head of customer success. As expected, he was tasked with increasing revenue growth from the current accounts and looking for ways to decrease churn.

[00:00:58] After getting acclimated to the new company, he was finding it very onerous to navigate these disparate systems to modify customer plans, to get usage data on their users, and he was even finding some inconsistencies between Salesforce and their platform on what plans the customers were supposed to have.

[00:01:15] He found himself spending more time wrangling data than he was actually interacting with customers. The company's development team was in the midst of several sprints, focused on new customer-facing features. So there weren't resources available to help alleviate this current time cycle.

[00:01:30] Trent's ultimate desire was for Salesforce to serve as a single source of truth and manage as much of his daily process as he could within it. He made some efforts to ingest data into Salesforce on a one-off basis, but often by the time he got everything organized that he needed from different reports and different places, the data was stale.

[00:01:48] He needed data from their platform coming into Salesforce in a timely manner, and he also wanted consistency on the plans the customer-provisioned in Salesforce versus what they were actually getting on the platform. And he was going to need to do it with minimal access to development resources.

[00:02:03] Let's hop into and take a look at an example of how he could accomplish that. All right. So here we're on the platform. There are a few packages here related to this use case, but I'm going to walk you through the build as a package. So bring data out of Salesforce and into the platform database.

[00:02:22] So what they wanted here is to bring their plan information, after they've closed a contract, to push that plan information down into their platform. How many users do they have? What's the company name? When does the contract end under their subscription? All of that. So we have a custom plan object that we can pull that from.

[00:02:40] So what I'm going to do is name this Salesforce Plans and then create a new package. Our Salesforce instance and our database are already authenticated and connected to So after that, it's as simple as adding components and building a path between them. So, first thing we'll do, we'll set up a Salesforce source and we're going to grab information from that plan object.

[00:03:04] So we've got our source properties here. We'll do a quick refresh and you'll see a list of all available objects that you can pull from. This includes custom objects. So we've got our plan custom object here, and there is a where clause here. So if you want to do incremental load and only look at, say the SIS mod timestamp, you know, from the last time this job ran or from a specific date, you can do that or look at it, you know, the user modification, timestamp, or anything like that to do incremental load, but for time's sake, we're just going to jump through and go to the schema.

[00:03:34] So we've got 17 different fields available here from this object, but we don't need all of them, for what we're going to push into our platform database. There's only a few that we're going to care about. So one of them is the plan type, what plan are they on, pro, enterprise, free trial, et cetera. The other one is account seat.

[00:03:57] This is the account ID that the plan is tied to within Salesforce, and I'm gonna use this in just a moment to bring in the company name as well. We do want to bring in the Salesforce ID for this plan so that we can go through and do merges on this later. If they update the number of users, extend their contract, et cetera.

[00:04:19] The other items we want to look at here are, how many paid users do they have in the platform? So how many users can they allot? And then also what's the renewal date. When is this plan supposed to end? Alright, so we'll click save. Now we've got that data flowing through. Next thing we're going to do is join some additional data.

[00:04:43] So while we have the account ID, we don't have the account name. So we don't have the company name flowing in and we do want that in our platform, so it displays. So we're going to add an additional Salesforce source and quickly grab the info to join it on. So we can go through, grab our account object. And then here, we're only going to need a couple of fields. We need what the ID is from Salesforce.

[00:05:12] And we want to know what the name is. So we grab both of those. Click Save. And then it's as quick as dragging a connection into the joint. Now, we can choose our type of join. For this purpose, we're going to want to inner. So they match. And then we're going to go here and identify that our account CID is matching up with the account ID.

[00:05:36] Then we click save. So our next step after this is going to be putting this data into our platform database. So we go and choose the database destination. We open this up. Platform database is connected. Now I know from existing, from the schema itself, we have a table called company plans that we want to populate this into.

[00:06:04] We're going to want to go through and merge this data into the table so that not only will new plans populate, but also updates of users, updates, you know, extensions on their contract renewals, et cetera. So we can go through. Now we'll click autofill. What we're going to want to merge on here is our Salesforce ID, because that's going to be populated with every plan.

[00:06:34] And simply here, I just clicked autofill. It gives all our input fields that are flowing through the pipeline, and then we can map it to destination columns that are in our database table. So the custom tags here are not currently in our table schema in our database. And this is representative of Trent's use case.

[00:06:57] It was trying to have the least impact on their existing database, but certainly you can go through and generate new tables and have this match. So it's a little easier to understand between. Renewal date here is actually called end date in this database and name is company name.

[00:07:21] And here you have SFID. I actually made a mistake here. There should be account C. So now we're going to populate the plan type, the number of users when the subscription should end, what the company name is and what the Salesforce ID is. And then this will also populate a plan ID when it pushes into the database for any new contract.

[00:07:42] So we're going to key off of that Salesforce ID for future updates.

[00:07:49] And that's it. We can save and validate. And this is going to go through and check, know if you're doing any custom transformations, any syntax, anything like that. Package validation completed, no errors found. We'd be all set. We can run this at the outset. And because this didn't have that where clause, it would pull down all of the plan information that's currently in Salesforce.

[00:08:09] But certainly you can go through and use those where clauses to do any sort of limitation you want and run this package on a daily basis twice a day, every hour, even every 10 minutes if you need it on this platform. All right now, just a quick jump over here to look at the database table itself for the company plans.

[00:08:30] We've run our job and we've got everything passed through and synced, and we can run this on a repeated basis and make sure that any changes to these plans are passed down to the platform as well as new clients themselves can be pushed into this table as well and started up. If you want to, look at the use case of pushing data back up into Salesforce, hop over to part two. Thanks for watching.

About Xforce

The Xforce Data Summit is a virtual event that features companies and experts from around the world sharing their knowledge and best practices surrounding Salesforce data and integrations. Learn more at