About six months into my first job out of college — a marketing gig at a tiny research center housed within a large public university — my team decided to give Salesforce a try. We needed a way to store contact information for thousands of researchers, educators, business leaders and students, and settled on the leading CRM as our solution.
I honestly can’t recall if we worked with a consulting firm or Salesforce directly, but I remember waiting weeks while our platform was being “built” for us. At the time, I thought, “What’s taking so long? Don’t they just have to upload a few spreadsheets?”
Now that I work for a Salesforce consulting firm, I’m a little embarrassed to have had such a thought.
{{cta('082c66b0-c7e8-4a26-98ae-e7535c910537')}}
Building declaratively in Salesforce — that is, building without custom code — is an involved process, one that requires patience, experimentation and expertise. Unfortunately, it can also be a relatively hidden process. If your company is thinking about Salesforce, there might come a time when, like me, you find yourself wondering what a Salesforce analyst actually does.
To help raise the curtain on some of that mystery, I asked one of our analysts to show me around the back end of Salesforce — to offer me a glimpse of how he spends his days. With a pinky promise to relay his wisdom as accurately as possible, here are a few things I learned about what goes into a custom Salesforce configuration.
Object Manager: Easy to use, hard to use well.
As a platform, Salesforce is built around the idea of objects: Leads, contacts, opportunities, etc. Each object represents a type of thing, while a record represents a specific instance of that thing. Some objects — like the three mentioned above — come standard with Salesforce. Others can be custom created.
An object can also be thought of as a collection of fields: Name, address, phone number. Again, some fields come standard with Salesforce, while others can be made from scratch.
To configure both standard and custom objects, an analyst will use an aptly named tool called Object Manager. Object Manager’s interface is slick, and features user-friendly functionality (think dragging and dropping, click boxes, etc.). Figuring out how to use it isn’t the hard part. Using it effectively is the hard part.
In the case of my earlier job, we had to wait on our Salesforce build because someone was meticulously configuring a number of objects to fit our unique needs.
Many of our contacts, for instance, maintained multiple websites (personal and academic) and were associated with a number of different institutions and scholarly journals. In order for all this information to display appropriately, an analyst (or their consulting lead) had to decide how the contact object in our Salesforce instance should be custom configured: What fields to use, what form they should take, what order. You get the idea.
And our build was a relatively simple one. For more complicated use cases, an analyst might have to write logic-based formulas, or map fields to an integrated ERP platform — both of which would amp up the complexity of the project.
A metaphor comes to mind: It’s easy to type, much harder to write. Though Object Manager as a tool is simple enough to pick up, knowing how to use it to achieve a particular goal takes a lot more time and energy.
Automation: Essential, but more complicated.
Of course, configuring the fields for every object is only half the battle. Salesforce, after all, isn’t only designed as an easy-to-use database. It’s meant to help your team save time and empower them with better data. And, in many cases, the best way to achieve such efficiency and data visibility is via automation.
From a configuration standpoint, automation can take a number of different forms. Validation rules, for instance, can be used to create conditional requirements. Let’s say a user, a salesperson, loses out on a deal. When this user logs in to Salesforce to close out the opportunity, the object record requires them to choose a reason for the loss from a picklist. If none of the standard options apply, the user might select “other.” But “other” isn’t exactly valuable information for a sales manager. With the right validation rule in place, selecting “other” will automatically require another field to be filled out — one that asks the user to type in a specific reason for the loss.
Other options include workflows, Process Builder and flows, a trio of tools that power if/then automations of increasing complexity. You might use a workflow rule to format all phone numbers the same way, for example, while a flow could be used to create a totally custom way for users to add information to a particular record.
In each instance of automation, an analyst (or, again, their consultant) must think through the particular logic required to make it work. And if their first try doesn’t work, they have to iterate until it does. While not actually programming — formulas demand a certain formatting, but they aren’t really code — the time-consuming process of trial and error is similar.
So what does a Salesforce analyst do? To sum it up, they use a series of tools to transform an out-of-the-box product into a custom solution that helps your company tackle business challenges. Part tinkerer and part logician, they make sure Salesforce functions exactly as you need it to.
For some quick info about other key roles on a Salesforce implementation team, check out our blog: “Building the Ultimate Salesforce Implementation Team: 7 Key Roles.”
