As a Salesforce Administrator, the Org is your domain. You have studied the dark arts of Apex, User Management, Sharing Rules, Flows, and much more to make your clients Salesforce instance not just functional, but a beacon of ingenuity, efficiency, and usability. As far as you know, there is nothing you can’t handle.

 

But what if Salesforce isn’t enough? What if you need to step outside or the Org and use new technologies to find the solutions you need?

The Problem

One of our clients is a company that works closely with the Canadian Government, and in that capacity they need up-to-date records created for each current Canadian Parliament Member as well as each Canadian Constituency. This task on its own comes out 772 unique records! But that’s not all. The client also wants a way for records to be automatically Upserted EVERY time a new Parliament member gets replaced, reelected, or elected to a new constituency. When you consider the amount of time it takes to check the records and relationships against the government data, this quickly becomes a logistical nightmare!

 

Thankfully, we have a solution, thanks to automation!

Make.com Logo

Creating Automations Using Make

Make (formerly know as Integromat) is an online platform that allows you to create automated processes across different apps. For this project, we will make use of Make’s automation capabilities, along with some of Salesforce’s native features, to complete this task.

Preparing The Org

Our First Step is to Collect the data we need. Thankfully, Canadian Parliament has this Data easily accessible on their website.

Open Government XML formatted file containing Canadian Member of Parliament and Constituency data

Looking at the Data, we see that it’s structured with several text fields: Honorific, First Name, Last Name, Constituency Name, Province/Territory Name, Caucus, ‘From’ Date, and an empty ‘To’ Date.

 

Before we start building our automation, we first need to prepare our Org by creating new Record Types with Custom fields, one for Accounts Called ‘Constituency’, and one for Contacts called ‘Member of Parliament’.

 

We will begin with creating a ‘Constituencies’ Record Type, and add the custom text fields ‘Constituency Name’, ‘Province’, a lookup field to the ‘Member of Parliament’ Record called ‘Current Member of Parliament’, and a Formula field, named ‘Current Political Party’, that grabs the Caucus name from the ‘Member’ Record. 

 

Next, we will tackle the ‘Member of Parliament’ Record Type. Just like the ‘Constituency’ Record, this page will have a name field, two custom text fields, named ‘Honorific’ and ‘Political Party’, a Lookup to ‘Constituency’, and a Formula field that will grab data from the ‘Province’ field. In addition, we will add a Date field, called ‘Elected’.

 

Now that our Org is prepared, it’s time to put our automation to work.

Screenshot of the newly created Salesforce Account record for a Federal riding
Screenshot of a newly created Salesforce Contact record for a Member of Parliament

Checking Against Salesforce

Make.com uses modules to perform several different tasks on dozens of apps. For this scenario, all we need is a simple web hook to grab the data, followed by a parsing and Iterator tool to organize the data into readable bundles.

Make.com Iterator tool organizes data into bundles for individual processing

Next, we will reformat the Date fields to a format that Salesforce can read.

Reformatting the Date from the XML data into a Salesforce-friendly format

Now that our data is properly structured and organized, we can bring Salesforce into the mix! For this task, we will use two ‘Search Record’ Modules, one for Accounts and one for Contacts. We will search for The Account Name and the Contact first and last name to see if the Org has any records that match the Data from our xml file. If there is a match, the module will return the information that we set as the output.

Adding a step to search Salesforce for an existing Account record
Adding a step to search Salesforce for an existing Contact record

Once the automation has finished its search, it’s time for the final step.

The Great Upsert

Before we go creating records for every Member and every Constituency, there are a number of things to consider. What if these records already exist? What if one exists but not the other? What if they exist as different record types? How can we be sure we’re not overwriting any existing data or creating duplicate records?

 

It’s important to consider every possibility when planning an automation like this. If precautions aren’t taken, with the automation running in the background, you can very quickly find yourself flooded with bad data and a whole mess of problems!

 

For this particular case, we landed on four possible scenarios and created unique filter-based routs for each:

Create four seperate routes to accommodate the possible outcomes in the scenario

Path 1. If neither record Exists, We have two ‘Create Record’ Modules, one for the Account record and one for the Contact record. In each module we will map the xml data to the custom fields we’ve created, as well as hard code the record type ID from Salesforce. Finally we will use an ‘Update Record’ Module to create the Relationship between the two records.

Path 1: Create both records if they don't exist

Path 2. If the Constituency exists, but the Member does not, we will simply use a ‘Create Record’ module for the Contact, and an ‘Update Record’ module to create the relationship.

Path 2: Create the Contact record and update the Account record

Path 3. If the Member exists, but the Constituency does not, we will ‘Create’ the Constituency, and use two ‘Update Record’ modules for the Contact and the Account, ensuring the relationship is established and the lookup fields are populated.

Path 3: Create the Account record, then update the Contact

Path 4. If both records exist, we will only need the two ‘Update Record’ modules to establish the relationship and populate the Lookup fields.

Path 4: Only update the relationships

Testing... Testing...

Great! Job well done! Let’s pop the champagne and toast to our continued excellence!

 

…Not so fast.

 

As all pro Salesforce Admins know, you should ALWAYS test your design before activating. The simplest way to do this is by using filters, which Make allows you to create within the connections between modules. by filtering the data down to one or a small hand-full of bundles, we are able to make sure the search results and record upserts are running the way we want.

Once everything is tested, we are ready for the automation to do its job!

Success!!!

Testing the automation with a single datapoint to ensure it is working as expected

And just like that, we have reached our goal! Using Make and our new Record Types, we have successfully created all the new Member and Constituency Records, and established relationships for each one. Not bad for one automation!

Up Next...

The completed Make.com automation

We’ve done a lot, but we’re not out of the woods yet! In my next post, we will use Flow to keep the AccountContact Relationships up to date through the next election process!

Connect and Automate Apps to Salesforce with make.com

Ready to automate your own external Salesforce tasks?
Discover make.com's capabilities and revolutionize the way you manage connectivity to thrid-party application data. Your path to seamless Salesforce automation starts here.
Facebook
Twitter
LinkedIn
Skip to content