Last year at London’s Calling, the BrightGen stand was buzzing with activity. Our very own Salesforce MVP, Keir Bowden (a.k.a. @bob_buzzard) answered any questions tweeted to him throughout the day with #askbob. Everything from starting out in Salesforce Lightning Experience, to whether dogs get excited about Lightning web components. No question too big or small for Bob!

This year, London’s Calling will be very different. There’ll be no physical presence at our stand. But we are excited to host a virtual room (here) and to sponsor the event’s first ever caricaturist. So you can join our virtual BrightGen meeting room to get their caricature done on the day. To bring a sense of humour to the situation, we’re running a competition for best caricature to those who tweet @brightgen #BrightME

What hasn’t changed is #askbob. Tweet @brightgen @ldnscall #askbob to get Bob to answer any of your burning Salesforce-related questions. In this post, we delve into one of our top rated questions from last year about inheriting a bad Salesforce org. Bob has expanded on this with his top tips for starting to fix some common issues, and then why this is so important to get right. We finish by anticipating some of the questions Bob might be asked this year, and to give you some ideas for questions you could raise.

Inheriting a bad Salesforce org

It’s a familiar scenario: you acquire a new company, or you join a new company. They use Salesforce. You dig deeper… it’s evolved over years, with lots of people building applications and code all over the place. What do you do if you inherit a bad Salesforce org?

Bob says: “Get help”! If you’re not an experienced developer, you’ll likely end up putting plaster on the cracks but not fixing the overarching structural problem. You need a partner (like BrightGen, for example) or to hire an architect. They can do health checks and will be experienced enough to look at your code and configuration holistically to identify major issues. When you target those issues, with a few weeks of work you can fix most of them and you’ll have set up your infrastructure for success.

If you’re wondering whether or not you need to get help with your Salesforce org, here are a few of the more obvious warning signs:

  1. Hundreds of profiles
  2. People can’t see data they need to access
  3. The opposite of the point above: inability to restrict access to data
  4. Frequently breaking governor limits

Some suggestions from Bob to get you started

  1. Hundreds of profiles
    Historically, if your Salesforce users had multiple responsibilities, you would have to create additional profiles for one person to fit their needs. Now you can choose the option of creating permission sets instead of profiles. Permission sets are more flexible than profiles. Now you can use permission set groups too, which allows you to associate multiple permission sets for a specific business purpose. Setting this up will save you a ton of time in the long run - and you can delete all those obsolete Salesforce profiles. 
     
  2. People can’t access data they need
    Usually a sign that your sharing model is too complex. It’s common in older orgs where the sharing model has grown organically. This really requires an overarching point of view. You need to take a step back from the problem and work out who needs to see what to do their job. This can’t even be assessed at an individual or team level - you need to think about each function of the company.
     
  3. Inability to restrict access to data
    The opposite problem to your Salesforce users not being able to access data they need: people can access too much. This is caused by the sharing model being too wide open. You won’t be able to put enough restrictions on sensitive data. With privacy becoming ever more important, you should follow the principle of least privilege. Only let people see what they need to see to do their jobs. Again, this means you’ll have to take a step back and look at this at a company-wide level.
     
  4. Frequently breaking governor limits
    This is usually caused by mixed automation, such as process builders, workflows or triggers, being added to solve problems without considering automation already in place. Automation in one area can also interfere with the needs of other teams. Another area to take a step back. You need to get governance in place so that requested changes are considered in the light of the entire organisation and existing solution. You might need to rework existing processes to help ensure changes are tested holistically. 

"Thanks for the advice but i’ll paper over the cracks, it’s quicker and easier..."

It’s not! If you don't solve the problem of an org that is hard to change, you will forever be coping with the symptoms. Over time, people will become increasingly scared of change because of unforeseen side effects and you could fall foul of a few regulatory rules on data too. Ultimately, you won’t get the ROI that you could out of your Salesforce implementation.

Companies that fail to take action to holistically fix a bad Salesforce org will see knock on effects to the entire business. Firstly, admins and devs will be blamed. Admins and devs will keep change to a minimum to avoid unexpected breaks - and because changes will be hard to make. That means they’ll be seen as blockers to business transformation. 

Secondly, it will be hard to hire new permanent staff who will want to deal with a big problem like this. No one wants to be firefighting all the time. Existing hires won’t hang around, as they will want to progress and use the latest features of the platform. If the system can’t be changed because it keeps breaking, your existing employees will quickly become frustrated with the lack of progression and learning. 

Thirdly, most crucially, the business will be frustrated with being stuck in a static system. Forever on the back foot it will affect the business’s ability to grow,  compete and progress.

What to expect for London’s Calling 2020

This year, we expect a fair few questions around the Spring 20 updates. Especially as before record save flows were introduced - this is something Bob has already written a couple of popular posts about.

Migration to Lightning Experience was a popular question last year and we anticipate it being a question again. But Salesforce has produced a lot of information about this in the last year, so it might already be covered. 

One set of questions Bob hopes to answer is about the new BrightMEDIA Lightning Bolt, which went live last week. It’s a second generation managed package on the App Exchange. Bob is happy to talk about second generation unlocked packages in general, as well as the BrightMEDIA Bolt.

Finally, as the entire audience will be working remotely, Bob will be ready to answer questions about how to operate in this new world of work for many. He expects to discuss tips for up-front organisation and rules of engagement (for example, how to best manage meetings online and other practical advice). We’ve already seen that  for many, working remotely has exaggerated the issues of a bad Salesforce org with those simple tasks being anything but simple.

Tweet your question to @bob_buzzard and @brightgen on Friday; include @LDNsCall and #askbob. Remember to visit the BrightGen virtual meeting room as well to get your caricature done live on the day. Tweet #BrightME to @brightgen and @LDNsCall to enter a competition for best caricature!