Salesforce teams can be complex and diverse, with varying levels of technical expertise and involvement. Automation and visibility are key to success.
With this article, learn about the challenges of managing a diverse Salesforce team and how to create a development and release management process that works for everyone. You will also learn about the importance of automation, visibility, asynchronous collaboration, and avoiding excessive process.
Here are our 5 Key Takeaways:
1. Automate as much as possible to avoid tedious and error-prone manual steps and manage dependencies.
2. Create visibility into the process to keep track of who is changing what, when, and why, and establish context between multiple environments.
3. Set up a good asynchronous collaboration process to make it easy for people to quickly get up to speed on a project.
4. Radically avoid excessive process and choose the right tools to keep steps to a minimum.
5. The Salesforce ecosystem is growing, and more companies are investing in tooling for Salesforce teams.
FREE TOOL
Profiles & Permissions Deployer
Easily compare and deploy Profiles, Permission Sets, and Field-Level Security (FLS) between any two Salesforce organizations.
Get Started
Made with love by the Blue Canvas team ❤️
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.
Collaborate Asynchronously 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.
