What does your Salesforce team look like? If it’s anything like most of our customers, it’s not always easy to answer. Where does your Salesforce team begin and end? There are so many people who can be involved in a Salesforce implementation. A “typical” team might look something like this:
1 Product Manager: responsible for the total health of the project, specing and prioritizing features. Makes minimal changes to Salesforce metadata but has an interest in just about every aspect of the team. Still, they may occasionally roll up their sleeves and make changes to Salesforce on an ad-hoc basis.
1 Salesforce Developer: responsible for all complex customization with Apex and Lightning. Codes with MavensMate but occasionally makes changes to declarative metadata. Makes changes to Salesforce hourly. Very comfortable with the command line and Git.
2 Admins: responsible for customizing Salesforce through the Salesforce UI and managing AppExchange add-ons. Making changes to various metadata types every day. Many of their changes directly affect the work of others on the team including the developer. However, they don’t necessarily know Git or command line tools.
1 Marketing Automation Lead: manages Marketo or other marketing apps. Rarely touches metadata but drives requirements and does update Email Templates regularly. Frequently involved in drafting feature requirements. Definitely does not need not work in the command line for day job.
2 Sales Ops or Business Analysts: responsible for high level reporting and sales strategy. Works with Dashboards and Reports daily, but rarely with any other metadata. Creates tickets and requirements for the admins and developer.
Consulting team: brought in twice a year for larger projects and includes 2 more developers and another admin, plus a consultant who acts as project manager. During busy periods, coding and making declarative changes hourly but not doing much outside of those periods.
There are myriad other possible combinations and arrangements. So it’s not surprising that teams are struggling to put together a development and release management process that works for everyone. Different people have different levels of interested in the process. People have different technical training. People have different deadlines and contribution frequencies. Nonetheless everyone on the team has overlapping work and have frequently create dependencies on each other.
Over the last 2 years, we’ve thought a lot about how to make a Salesforce process that works for everyone. Here is what we’ve learned about what works.
Automate Everything You Can
The best way to solve the challenges of working with a diverse team is to create as much automation as possible. If you can, make Git commits automatic. Make deployments as automated as possible. Remove the manual steps that are easily forgotten or error prone. Everyone benefits from this. Devs and admins making frequent changes are able to avoid tedious and annoying manual steps. And consultants, business analysts and other less frequent contributors benefit from not having to memorize complicated steps that they only use occasionally.
Automation is also helpful because it helps manage dependencies. When you keep the process automated you find that you are less likely to have a missing Email Template from a deployment package. When you go to deploy a feature you’re more likely to see it “just work.”
Build for Visibility
Of course, you can’t automate everything, so it makes sense to create as much visibility into the process as possible.
Salesforce teams are often multi-department. A marketing manager and Salesforce developer may need to work together, but they may have radically different schedules. They may not be in the sam building. Consultants may fly in for a project and be gone for two months before coming back. Given all this in and out activity, it’s useful to have as much visibility into what’s going on at all times. Who is changing what, when and how? And why?
Visibility into differences between orgs is also useful. This allows you to quickly establish context between multiple developer and admin environments.
Because of the varied commitment levels from varied stakeholders, it’s smart to set up a good asynchronous collaboration process. We prefer tools like Trello or Jira to tools like Slack for this because it’s helpful to have sources of record for different things. If someone changes and Apex Class for a feature, and then a declarative change is made for the same feature two weeks later, it’s helpful to have a central repository for that knowledge. You want to make it easy for people to pick up something that they haven’t looked at in weeks or months and quickly get up to speed.
(This is one reason we’ve built Deployment Request with commenting and information about validations over time. It’s meant to serve as a single units of work where teams can quickly grab all the context they need for a request).
Radically Avoid Process
The final suggestion we have is to create as little process as possible. Every step you add makes it less likely that people will stick to your process. Automation can help with this. And so can choosing the right bits of process and the right tools to keep steps to a minimum. It doesn’t make sense for Marketing folks to learn to
git commit before every change or for Salesforce Admins to be in Jenkins or messing around with Ant scripts.
Fortunately, there are tons of great tools in the ecosystem for promoting this kind of cross-team collaboration. And it’s only getting better as more companies invest in Salesforce and the ecosystem grows. The Salesforce ecosystem is predicted to create 3.3M jobs by 2022. With all of that you can rest assured that more and more companies will be investing in tooling for Salesforce teams.