Salesforce Administrators are in the unique position of wearing numerous hats to maintain their instance. Depending on the number of licenses and integrations, people can find themselves in more of a business analyst or project manager position instead of working in just Salesforce. Quite a few admins are the sole system experts for their company so this can be very complicated when enhancements pop-up. The main problem is that just because someone understands how to configure Salesforce; it doesn’t mean they comprehend change management or how to successfully work with teams to implement those changes. Unfortunately, that could potentially mean an admin would be duplicating work if the results weren’t up to their clients standards.

A business analyst’s job is to work between departments, identify requirements and the project scope, create the solution design, implement the design, test the design and make sure the solution is maintained.

They may not do every single step but they are involved in the process from beginning to the end. When working with a tool like Salesforce it is important to implement changes via a software development lifecycle, which is what BA’s do.

Below I’ve compiled the top 5 skills I think every admin can apply to collaborate more effectively with their clients and reduce the amount of time spent on redoing projects.

1. Documentation

A good business analyst and Salesforce Admin knows how to collect and keep information organized. This means there should be a method to the madness. It doesn’t mean it’s necessary to write down every word said, but be sure to keep track of the main requests and any business processes that aren’t familiar. Even if a process is something that sounds simple, if there is any doubt about what it consists of make a note so that there aren’t any doubts.

Misunderstanding a process or assuming can lead to lots of problems when user acceptance testing is being conducted.

A tip that someone once gave me was to utilize excel when taking notes. Write each part of the request on a separate line so that exactly what is asked for and asked of the team is apparent and so that the information can be repeated back or additional questions can be addressed. With this document, when the time comes to create business requirements it doesn’t take much to see what has been done and what needs to be done. It’s a simple method but can save an admin a lot of time digging through handwritten notes in a spiral. In the example below, there are three columns; request, requested and urgency. Creating a template to be filled out during the meeting can save a person time and energy. It could also prevent information from being forgotten or left out.

Another tip is to upload excel documents to Google Sheets to encourage collaboration with other team members so that they can add notes in real-time. Utilizing Google Sheets or another collaboration platform is a way to share updates with the requester without them needing to request a status report. Something to note is avoid putting anything in the documentation that would offend the requester. It’s important to maintain a strong working relationship with internal customers.

2. Analysis

Working within Salesforce gives the user insight into company processes and how change could affect other business units.

This is where the analysis skill comes into play. Applying the knowledge that a person has regarding these processes when working on a project is crucial.

If a request will clash with a different process or team then it needs to be addressed during planning meetings. The best way to identify these issues is to create use cases from the documentation collected. A simple way to think of a use case is how the users will be utilizing this change and why. They need to be able to identify exactly how they will be utilizing the change, what they expect the change to do and all of the ways they will work with the change. This will prevent any unnecessary scope creep from jamming up a project during user acceptance testing.

When the use cases have been compiled and there is a firm understanding of the initial request, the analysis can begin. Analyzing how the change will affect the tool, the other users and if there is a better solution for the requester will help to avoid any long-term tool clean-ups in the future. Admins are the expert in the tool; the client has a problem they are trying to solve. It’s up to the expert to provide a proper answer.

3. Requirements Gathering

Requirements’ gathering is one of the most important things if not the most important thing that a business analyst does. The requirements are used by the Salesforce team to identify what is being done, the requester can see what exactly their request translated into on the IT side, the developers are able to follow a strict set of guidelines of what needs to be built and testing is simple because it follows what the requirements asked for.

The complication with requirements is getting them correct. If something is off or miscommunicated then the result could be something completely out of left field and the internal customer will be very dissatisfied. 

The first step after a client has asked for a change or project is to schedule a discovery meeting. This meeting is where the documentation portion is put into action. Document all of the following:

• What do they want
• Why do they want it
• Who will it benefit
• What is the problem they are trying to solve

Once all of the baseline information is compiled, the analysis will begin. Review all of the information they have provided and create use cases for each of the parts of the request. Having use cases helps to discover holes in the processes and others who might not be as technical can read them and add or adjust requirements if needed.

Using the documentation that was compiled during the discovery meeting create an “if-then” list. This is a simple way for the developers or the implementation team to see how the request should function. Similar to the use case it will point out how the system will work for the client and the ways they will use it.

Having an excel document that has the initial documentation, the if-then list and an actual requirements breakdown is very beneficial when working with teams that just need the information to complete their portion of the project. They can see all of the information in one place and they can see what portion they need to complete. The requirements breakdown will have the list of which department does what along with what the request is, what system it is in and what the change is.

Here’s an example of a requirements tab:

4. Methodology

Larger companies have methodologies that the IT departments are required to use such as Agile, Six Sigma and Waterfall. Working for these companies gives those admins a leg up when it comes to BA skills. They know how beneficial it can be to have everyone on the same page and working toward the same goal. Admins who don’t work for a company that has put one of these into place then it is a good time to do some research and impress leadership. 

These different software development lifecycle methods will benefit the admin in not only their current role but in future roles as well.

Many companies seek out individuals who have experience working within the parameters of Agile and Six Sigma because they are so effective.

The Waterfall method is considered one of the easier methods and consists of:

1. Gathering requirements
2. Designing the solution/change
3. Implementing the solution/change
4. Verifying that the solution/change is working
5. Maintaining the solution/change

Using this process, an admin would meet with the requestor and perform a requirements gathering session outlined in the above section. They would then design a solution by analyzing the current processes, business rules and changes taking into consideration all of the documented needs. Then they would implement the change/solution whether that be working with a developer team or completing the request themselves. Then they would do verification, which is mainly in the form of testing in a sandbox and then smoke testing in production to verify everything is working the way it should. Finally, they would maintain the change by updating it when the system updates or the requestor has an additional change request.

5. Problem-Solving

Although this skill seems generic, it can be something many admins wouldn’t think about. The ability to see a problem and make quick decisions based on limited information can be intimidating. Problem solving isn’t always being the first person to jump in with an answer. Sometimes there will be issues during testing, a requirement will change last minute, and something is missed in the discovery meeting.

The solution the customer is asking for isn’t always the best or most efficient way to solve the problem. The client isn’t the Salesforce expert so they won’t know if there is an easier way to answer their need.

Even combining the 4 skills above it is still important to make sure to ask the hard questions, suggest alternatives and make changes if need be. When working on projects there are always last minute problems. An important user could be out for a week in the middle of the requirements gathering, a team could be on a moratorium, leaders could disagree on what the best solution is. Remember to go with the flow and make decisions based on the best way to resolve the issue and not just “the way your business has always done it”.

With these five business analyst skills and admin can work alongside their business partners to create new features, resolve issues and complete large projects.

Understanding the needs of clients is the first step to creating clear and concise solutions. An effective Salesforce admin who can apply business analyst principles to their position will prevent costly mistakes, create lasting changes and become more involved in the processes of their clients. Combining organized documentation, thorough analysis, extensive requirements gathering, implementing a methodology and using problem-solving skills will elevate an admins role in the business.