Salesforce serves as the defacto CRM for many large and mid-sized businesses. This means Salesforce is often the defacto system for customer success.
For many CS teams Salesforce won’t do. They turn to platforms like Trustfuel to make them more efficient. Easy decision, right?
Unfortunately, Trustfuel had a problem. Teams that were using Salesforce couldn’t abandon the product—the rest of the company still needed it. They also couldn’t afford to waste time re-entering data in two systems—they’d be creating even more work.
If we wanted to sell to bigger businesses, we couldn’t just import or export data. We needed to build a two-way sync with Salesforce.
Planning and Scope
I worked with Trustfuel’s two engineers, Jaron and David, to build this feature. I created all the concepts, and built the UI. Our CEO, Nick, has significant experience with Salesforce and provided a ton of input.
There was a fair amount of scope creep during this feature. The plan originally was to only import data, but we ended up building a two-way sync.
Mapping opportunities to orders was a difficult problem to tackle. It was going to be left out of this sprint. However, we had to submit the integration to the Salesforce AppExchange, and didn’t know if we’d have an opportunity to add it later. For that reason, we implemented it.
Early Concepts
Trustfuel started as a Net Promoter Score product (If you’re unfamiliar, checkout my NPS guide). For the NPS product we built a simple mapping tool, which allowed customers to import contacts from CSVs.
We used many parts from the NPS product to build a mapping tool for our customer success platform. There was some slight complexity added. The user would now have to determine if the information belonged at the account-level or the contact-level. There was also an extra step needed to verify the type of data the user was trying to import.
Originally, I had expected the integration process for Salesforce to be similar. Instead of using a CSV, the user would choose what fields from a list of fields in Salesforce. Later I would discover that was not an option.
There were a few problems with this mapping technique:
- Salesforce has a gigantic number of fields—often with obscure names. A traditional dropdown was out of the question.
- The user would have to determine a direction for data to sync. Teams often did not want to overwrite Salesforce information.
- Different sets of data did not map one-to-one. Salesforce opportunities were particularly troublesome because every company uses the fields differently.
We needed to take a hard look at each object in Salesforce and figure out how we would map a solution.
Mapping Accounts
I had planned on the account type field being an attribute associated with accounts. However, we had several customers that had non-customer partners as accounts in Salesforce. It wouldn’t make sense to import those accounts into Trustfuel.
To prevent this from happening, we would have to use the account type section as a filter. Had I known this from the outset, I probably would have stuck with our original wizard design pattern. For now, all other mapping sections are disabled until you choose account types.
The first thing the user must do is select what type of accounts they would like to sync. There are six default relationships provided by Salesforce. We found several customers had added custom types as well.
Once a user selects what account types they want to sync, the user will map Salesforce fields to Trustfuel profile fields. For accounts we only require a name. Website URLs are optional.
When a user selects a field to map, it only shows fields related to that Salesforce object (that account, contact or opportunity). This was a major improvement over early iterations that would show all fields in Salesforce.
What’s with the master record radio buttons?
You’ll notice the user must choose a master record in these concepts. This has to do with the direction data is imported. We wanted to have a last updated option. Unfortunately, that turned out to be a huge engineering challenge. We decided to punt on that feature.
What are those green checks?
The checks show that Salesforce sync is operational and Trustfuel is receiving the data it expects. I designed a warning concept should there be issues with a specific Salesforce object. Due to time, we punted on both the check and warning feature
Mapping Contacts
Contact mapping is very similar to accounts. However, the profile has many more fields. First Name, Last Name and email are the only required fields.
You’ll notice a contact preview to the right. As the user maps fields the profile is asynchronously updated. This should give the user an idea how their information will appear in Trustfuel.
Custom field mapping gives users a chance to bring in important data, but is not directly associated with a profile. This comes in as a normal custom column if Trustfuel is set to be the master record. If Salesforce is set as the master record, the data comes in as a smart column (view only).
We walked through a the mapping process with a few different customers. There was some confusion about the relationship between native profile fields and custom fields. Customers didn’t realize that the both belonged to the same object. Because of that we combined the profile and custom field mapping panels (for both accounts and contacts) into a single panel.
Mapping Opportunities to Orders
Opportunities in Salesforce are terrible to work with. Anyone that has worked on an integration will tell you that.
Revenue is an important number for Trustfuel and the customer success managers we serve. CSMs know they need to spend more time on accounts that provide more revenue to the business.
The main problem is with the amount field. Is that it accepts any number you put into it and every company uses it differently. Some companies use it for MRR, while others use it for ARR or TCV.
Even more infuriating—some customers will put a negative number into the field to show a downgrade. Others will simply create a new order with the updated revenue amount. There are several different patterns for how people use this same field.
To solve this issue, we ended up putting two questions in the opportunity section.
- How do you use the Opportunity Amount field in Salesforce—MRR, ARR, TCV or ACV?
- Do you use negative numbers in the Opportunity Amount field for downgrades—Yes or no?
These two questions seem to give us enough information to cover each case for the time being. I’m certain we’ll come across other issues in the future.
Another issue was missing information related to orders. Trustfuel uses the start date and term (or end date) to keep track of renewals. These fields don’t exist by default in Salesforce. While many customers had added custom fields, we needed to cover the possibility that we only knew about the final order amount.
I designed a concept that made incomplete orders coming in from Salesforce requiring review. If an order requires review they will have a warning message in the order section of an account profile and by default appear at the top of the orders index.
Above are a few iterations on how to show these incomplete orders. Our alert scheme had yellow text on a light yellow background. It was completely illegible. I considered changing it to an info alert, but that didn’t seem right since there was a problem the user needed to address. In the end I went with the darker orange-gold color pictured middle-right.
Mapping Cases, Notes and Tasks
We wanted to make it as easy as possible for customer success teams to leave Salesforce entirely. This means giving customers the option to import more than just accounts, contacts and opportunities. We would need to support cases, notes and tasks.
Most of these objects would not have an equivalent in Trustfuel. Salesforce cases, for example, often represent support issues a customer has. If the customer uses Zendesk for support, that integration throws support tickets into cases.
We needed to import this information, but how do we do that without creating new objects in Trustfuel?
I decided the simplest way to do this was to import these items as a note. Titles would be in all caps and field values would be represented in a note with a colon between them. Text area fields, like case descriptions, would have a line break before them. This pattern would work well for Salesforce cases, notes and tasks.
Upon connection, we would automatically import these items into Trustfuel. The user could choose if they wanted to continue importing them after the original connection.
Results
We had hoped that this would allow connecting Salesforce to be a self-serve process. Trustfuel’s not quite there yet. Getting an account connected to Salesforce used to be an engineering task, now it’s something that sales or customer success can do.
Final Thoughts
There are a lot of things I suspect can be improved. After going through this exercise, I understand relationships within Salesforce better. Given time, I would revisit the account types section—visually it should look more like a filter than a step.
We haven’t had enough customers to determine, but giving customers the option not to import cases, notes or activity is an update that will be needed at some point.
Time will tell if the feature is successful, but it was an incredibly valuable learning experience for me.
I often create notes, short videos or prototypes for the engineering team to review before sprint planning. It gives a good starting point for discussion. If you’re interested, you can find my feature notes below.