Talk Summary

In this quick tutorial, partner engagement manager Zach Behrman describes how to push data into Salesforce from an external platform. This is part 2 of Behrman's instructional talk on how to keep your Salesforce data and internal platform data in sync. He leads viewers step-by-step through the process of creating a package in that you can run on an automated schedule. Like part 1, Behrman bases this case study on an client.

This talk will interest anyone who wants a single, reliable source of information for their organization. The video clearly demonstrates the steps one must take to harmonize data sources, using's intuitive interface. This can serve as a refresher course on building packages in, or as an introduction to's functionality. Viewers will learn exactly what they need to know in a few short minutes after watching this brief, practical video.

What You Will Learn

  • Create a new package [00:00:38]
  • Push information on users from an external database into Salesforce [00:00:49]
  • Choose data source from external database [00:01:53]
  • Choose data fields from the external database [00:02:15]
  • Choose Salesforce as the data destination [00:03:47]
  • Create an upsert process to push data into Salesforce [00:04:01]
  • Bring in additional data fields [00:04:46]
  • Save and validate the package [00:06:18]
  • Push in additional packages using Salesforce ID [00:07:22]
  • Schedule packages and workflows to run on an automated basis [00:08:09]

Full Transcript

[00:00:00] Hi there. My name is Zach Behrman. I'm the partner engagement manager at This is part two of a series looking at bi-directional sync of data to Salesforce and an external database. So in part one, we looked at bringing data down from Salesforce, into a database, in part two, we're going to focus here on going from that same database back up into Salesforce.

[00:00:38] Let's get started. So we're going to jump back to the package creator here. And create a new package.

[00:00:49] I call this Users Salesforce Contacts. What we're going to do is we're going to push some information on users, into the context fields in Salesforce, and potentially create new contacts. For Trent's purposes, this is going to give them a view in Salesforce of, you know, what users, each account that he has in their platform.

[00:01:17] Further than that, we'll push some usage information on how often they're logging in when they're running reports and especially sending their user types. So maybe they moved from being a basic user to admin, or maybe over the course of the contract a different person than initially has now become the owner.

[00:01:37] And maybe Trent has a different point of contact in the company and was never notified about it. So he's got a better path of who he should start reaching out to when he's going to contact these customers and find out how they're doing and see if there's further opportunity there. So we will create a new package here, and this is going to be very similar to the last package.

[00:01:57] We're actually going to leverage the table that we were updating on the last package as well. so first we're going to go through, grab a database source and we have a users table. So we'll go through, select that user table.

[00:02:15] And then in looking at it, most of these fields look important. So we're going to go through and we're just going to grab all of these. The one thing we don't have here, when you look at it, is when we're pushing back a contact, especially a new one, we should be associating it to an existing account.

[00:02:36] So we don't have that account ID that we need here. But what we do have is a plan ID. And in the last step, we just pushed an account ID to match up with a given plan. So we'll click save here. And then we're going to go back and do another join.

[00:02:56] And then we will grab another database source, quickly get that connected. Then we can go through and select the company plans table that we're working with in the last step.

[00:03:25] We'll go through, and there's only a few items that we're going to need here. So we need the plan ID to join on. And then account C is our account ID that we'll want to use to sync in the contact to the right account. It's now a click save, go back into our join again, enter, join, and very quickly, we'll go over for our plan ID.

[00:03:51] Now from here, we're going to go through and select Salesforce as the destination. So with, you can actually push data back into Salesforce.

[00:04:05] All right. So where we want to send this is to our contacts object. So we've got our contact here. And instead of insert only, we're actually going to do an upsert. Because as I just mentioned, we can have changes in the users, there's their user status. Maybe they updated their email address for contact information, anything like that.

[00:04:28] We've got an upsert key to use here. So our key is going to be our Salesforce ID. Now you might say, if we're going and doing this, or what if as a new user, they don't have a Salesforce ID. This upsert process we'll actually go through, push the record into Salesforce. Salesforce will generate an ID for that.

[00:04:51] And then we can add an additional path later to query Salesforce and bring that Salesforce ID back down. And then we've got a few other fields that we'll bring in here. We'll just have them go. Got last name, the first name. I want some contact information from them with their email address. We definitely want to associate an account.

[00:05:25] And I think we're good with these that are here.

[00:05:34] Alright, so I've just got to go back through and quickly associate the right fields here.

[00:05:44] Got our email address. Got our counter ID. There's a few more I should grab here. We do want our user type.

[00:06:04] And I think we'll push the plan ID in here as well, just so we can pull back and reference that in reports, if we need to.

[00:06:22] All right, we can quickly click save here. And now just as we did in the last step, we can go through and save and validate this. That's checking to make sure all the connections still work. The pathways are correct. Validated, no errors found. So we're good to go with this package and we could run it right now if we wanted to.

[00:06:45] All right now, I've just jumped back out to the package menu here. We have a new package here. It's called users and usage workflow. So outside of the data flow packages that we've been building that have a kind of one source, multiple sources, multiple destinations, you can build workflows in and make jobs dependent on each other.

[00:07:04] So, as I pointed out the beginning, we had a few other packages here. SFID to users, reports to Salesforce, logins to Salesforce. So this is linking in our Salesforce ID to users and then reports and logins to Salesforce is to bring back that usage information that Trent was looking for. So we've got some aggregate components that can give you max state for the last login count the number of unique logins, count the number of unique reports for each users.

[00:07:32] We want to push those in. But we can't push those in, unless we know that we have their Salesforce ID populated in our database. So that's where we use a workflow. So how we would do this is we would run our users to Salesforce job that will then populate any new users or any changes to users up to Salesforce.

[00:07:52] And then with this on success. We'll then push down the Salesforce ID to users from Salesforce, into our database and map that. And then these next two jobs can successfully run with no errors where it can look at those users. It has their Salesforce ID. You can get their counter number of reports they've run, and then it can count the two items we have here, which is the number of total logins they have, as well as their most recent login date.

[00:08:17] And push that back up to Salesforce as well. So just one last step here, I hopped over to the scheduling model. Now that we have all our packages and our workflows set up, we can go and schedule those to run on an automated basis on a basic increment for chronic session. If you want to set it to run during business hours at certain times or anything like that.

[00:08:35] And keep that data fresh, on both sides in Salesforce and in the production database. So, you know, I hope this presentation has been helpful. Trent's use case seemed very apropos to me because in looking at how he had gone through and helped get this setup, they really didn't have to have too many fields pushed from Salesforce down to their platform or from their platform up to Salesforce. It only involved one custom object, a couple of new custom fields, and one or two extra columns in some existing platform tables.

[00:09:13] So they really worked around their existing platform database schema and didn't burden their dev team with much work around having this enhancement. And, you know, at the end of the day got themselves closer to a single source of truth out of Salesforce, and also, got a lot more tracking and visibility around, you know, who is making changes to plans, using roles within Salesforce and, and approvals to go through and restrict who could do that.

[00:09:43] At the end of the day, you cut down on disparate systems by customer success. So Trent himself, he had more time to contact customers because that's what his role was intended to do. Thanks again for taking the time to watch. And, if this has your wheels turning about what benefits you might be able to obtain by getting some more shared data between some external systems you have and your Salesforce instance, please feel free to reach out to

[00:10:12] I'd love to have a chat with you about what you're looking to do and see if we might be able to have some shared success.

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