Inherited Salesforce Org | Where to Start

Candy Goll |
 Salesforce |
 Jul 27, 2022

,Part I: Where to Start | Understanding the Business | Identifying Processes

Starting a new position as a Salesforce Administrator or Consultant can be overwhelming, especially if you are relatively new to the Salesforce ecosystem. This is only exacerbated if you are logging into an org that has existed many years before you. This situation is extremely common today as Salesforce continues its major growth and the talent ecosystem is playing catchup.

When I started working on the platform, my first experience with an org was working with a brand new one. This was extremely helpful from learning the out-of-the-box functionality and how I could leverage it for my use case, keeping the avoidance of technical debt top of mind. Over the past 10 years, this has happened only a handful of times. I have been able to untangle existing orgs with complex requirements and translated that into actionable project plans.

In this series, I will detail some core fundamentals that I have used in my experience as an Administrator and Consultant that helped me stand out and continue to build my career on the Salesforce platform related to existing orgs. This post will feature some steps on how to get started!

Inherited Salesforce Org | How to Get Started

Just log in and you’re done! All right, I am just kidding. When you are new to an organization, you may feel eager to get into the backend of the system and start digging around immediately. However, you may be putting the cart before the horse. When building out systems and processes, it is critical to understand the business aspects first before providing solutions. Solutions can easily change when you have more ‘data’ around what you are trying to solve.

On my first day at a tech startup in Seattle, WA with a five-year-old org, I met with my manager asking for 2-weeks to get settled in, and outlined my own version of an onboarding plan. I had learned from a previous position that the worst thing I could do is start making changes on day one without first understanding some key context about the business in general. You could make seemingly one innocent change that has an irreversible ripple effect.

Inherited Salesforce Org | Understanding the Business

As a starting point, I recommend getting answers to the following questions. This can lay the groundwork for building rapport with your new team and users. This also helps you have the foundational knowledge to understand a more holistic picture of your organization.

  • What does your company do and how do they make money?
    • This helps indicates how your company generates revenue. Increasing revenue will always be top of mind for your stakeholders. Being able to tie back to revenue will be required as you build business use cases.
  • What are the company’s top goals?
    • These should always be top of mind as you prioritize your work. Being able to tie back to the top goals will be required as you build business use cases. If you need help getting started with identifying goals, try using these guidelines for identifying your Salesforce Goals.
  • What are the company’s top pain points?
    • These should always be top of mind as you prioritize your work. Being able to tie back to pain points solved will be helpful as you build business use cases.
  • Who are your internal stakeholders? What motivates them?
    • Building rapport with your internal leadership and gaining their support is going to be critical to your success. Each leader will have different priorities, pains, and motivators. Understand these details about all of them for each function/department in your organization.
  • Where does your company operate?
    • Understanding if your company is regional, global, etc. will impact your solutions (for example., multicurrency, territory management).
  • What teams/functions make up the company?
    • The personas of users are also critical to your success. Similar to the way Salesforce keeps its customers at the center of everything they do, Administrators and Consultants keep their users at the center.
    • Do not work in a silo or with only one team. Salesforce typically will touch many functions of a company and working in a silo can be dangerous on day one, or as you scale your system. It also can create tension which can impact your success of adoption overall.
  • Who are the customers? How do you acquire them?
    • Understanding if your customers are B2C or B2B will impact solutions. Ask your Marketing teams how you acquire customers today and how they plan to do that in the future.
  • Do you work with Contractors/Partners?
    • This will help you understand external influences in your processes. Sometimes this can impact integrations or portals that may be used or needed.
  • What is your tech stack?
    • Understanding your tech stack seems straightforward, but I urge you to dig a little deeper into the following as it directly drives your future system strategies.
      • Why were the systems selected? What is the history?
      • What is the sentiment of the tool(s)?
      • Do people think they are scalable?
      • Who owns the tool(s)?
      • Are they integrated with other tools?
      • How are they maintained?

Inherited Salesforce Org | Identifying the Main Processes

User Processes

It is important that we keep our users at the center of everything we do as Administrators and Consultants. I recommend having a regular cadence of shadowing your users in the various functions. Assumptions can be dangerous, so it is critical to have multiple users walk you through their processes. Be sure to document these processes as you go and any changes to them over time.

If you can’t meet in person, do this virtually or have team members record their processes and send those to you to digest. Spending time with your users is another great way to build rapport.

Development Processes

The development lifecycle will likely vary by company. This is another critical step to understanding how your company executes system changes. If this is not a documented process or one does not exist, you should take this on quickly. At a minimum, development should be built and tested in a sandbox environment. The more complicated your initiatives and systems, the more robust your lifecycle should be.

The stages of the Software Development Lifecycle as it relates to the Salesforce Adaptive Methodology are defined below. Please keep in mind a typical software development lifecycle can consist of a variety of stages, the most common stages are the following:

  1. Prepare The preparatory stage begins with a preliminary analysis of a current system, identifying any current problems with an existing software solution (or the lack of a software solution in general) and the potential solutions, costs, budget, and a plan/recommendation of how to accomplish the goals laid out.
  2. Plan and Architect During this stage, functional requirements are established, and it is identified what the solution needs to do to become an effective tool for the organization.
  3. Construct, Validate, Deploy, and Support At this stage, a “sprint” (which is a short, defined period of time when the team works to complete specific deliverables) is outlined and the project deliverables are created. Go live support is then provided for a defined period of time at the end of the project.
  4. Stage 4: Monitor and Control During this stage, not only is the system that was developed evaluated but so is the delivery process that was used. Reports are completed to determine if the initial business requirements and objectives adequately explained the overall needs, as well as if the system that was built is functional and meets the client’s expectations.

Up Next: Now that we have the high-level information on your new company, we need to dig into the back end to evaluate! Check out Part II Back end review: Technical Debt, Integrations and Data.

About Roycon
If you need help you can always contact us. You can learn more about us, we’re an Austin-based Salesforce Consulting partner, with a passion and belief that the Salesforce platform’s capabilities can help businesses run more efficiently and effectively. Thanks for stopping by the Roycon Salesforce blog, be sure to subscribe. Thanks for reading and as always, happy building!

Candy Goll

Candy Goll

Regional Sales Manager

Unraveling challenges, overcoming obstacles, and exploring what’s possible on the Salesforce platform.

Challenges on the platform are no hurdle for Candy, she clears hurdles on the Snowboard and on the Salesforce platform, like no other. Candy is your go-to Salesforce Solution Engineer. After inadvertently falling into the Salesforce ecosystem as an administrator, spending time at several consulting partners, and even working at Salesforce as a Solutions Engineer, she excels in solving large challenges. She is most commonly known for tackling complex situations and breaking them down into bite-sized pieces, to create a path to success. Candy is a Salesforce expert who thrives on partnering with companies to build scalable solutions by leveraging the Salesforce platform.

Related Articles

Inherited Salesforce Org | Back-end Review

Inherited Salesforce Org | Back-end Review

Back End Review: Reviewing Technical Debt | Integrations | Data Now that you have high-level information on your new company, it is time to dig under the hood of your Salesforce org. What is under the hood you ask? Well, I can’t tell you – that will be up to you to...

read more
10 Salesforce AppExchange Apps You Should Know About

10 Salesforce AppExchange Apps You Should Know About

The Salesforce AppExchange While Salesforce is a highly powerful tool used to support any organization’s day-to-day functions, there are many Apps available in what is called the Salesforce AppExchange to help enhance the solution to support any organization’s needs....

read more
User Acceptance Testing Best Practices

User Acceptance Testing Best Practices

User Acceptance Testing (UAT) Best Practices, aka: “Have we produced what our customers want?” Introduction: A common misconception is: “Roycon, you’ve already built and tested this, why does the need exist for us, the customer, to also test? This is your expertise,...

read more
Tweet
Share