Switching to Lightning? Warn Your Users Now

I have finally had the opportunity to take part in the planning for a Lightning switchover project! The one project I’ve wanted to do since I became engaged with Lightning two years ago. I’d love to share some advice that’s based on what’s tried and tested – hopefully it will help you as you plan your own rollout.

Prioritising Change Management

My inspiration for this post is based around behaviour and perception. There is no denying that time is running out for Salesforce Classic – it’s not a drill, as my husband says, but the emphasis I want to give here centres on the importance of managing the business change as an equal priority (if not a higher priority) to managing the technological change. The truth of the matter is, Lightning is Salesforce completely re-designed. Yes, it’s a bit of an inconvenience for some Salesforce customers who may have to put their Business-as-usual on hold for a little while and invest time in getting ready. It’s also an opportunity for the technology to get closer to the human beings that make use of it.

To get that kind of value, you need to prioritise the readiness of your workforce for the productivity changes they’ll get with Lightning. But also to take the opportunity to clean things up a bit. Show them that you’re taking an interest in their needs, discourage bad habits and get them thinking in a brand new way. Focus on customers, instead of products or services. This post aims to show you how you can go about doing that. As always, your feedback is always welcome.

 

Take The Temperature

Surveys, workshops, clinics, interviews, ride-alongs….like any new implementation, take the opportunity to look at how your users feel about Salesforce. Some typical, actionable feedback might include

  • “I hate it that I have to create a contract when the opportunity is closed won.”
  • “I love that my entire schedule of customer care calls is set up for me so all I have to do is work through them.”
  • “The reports are pretty good but there are too many variations of them – I don’t know which one is the most reliable.”
  • “Why do I need to click Edit and Save to move my opportunity along a stage?”

Whether the response to that is training, business process changes or technology changes, gathering feedback is the most important thing you can do to start the process of switching to Lightning.You can then triangulate it with other things to formulate your project backlog:

  • User feedback
  • Business requirements
  • Technology requirements (the Lightning readiness reports)

Prioritise Your Communication Plan

The way you get your people ready is EQUALLY as important as configuring/coding the technology. Get them engaged early – feature it in your team calls, newsletters, town hall meetings, events, kick-offs and conferences. If your users are based in the office, put posters up, play games or run a couple of competitions. Use Trailhead to help you. Use TopTrailblazers to encourage some competitive spirit and reward your most engaged people.

A big change like this is a great time to get imaginative and think of something different to engage your users to get them ready for the change. After all, they’ll definitely make noise about the changes when you deploy them, so if you accept that but make sure they’re prepared, the noise level will be much lower.

Clients of mine have scoffed at these ideas – “Oh, we just don’t work like that.” My challenge to that is it’s every reason to try something different. You’re switching to Lightning because you want to make the best of something new. So what if people laugh and scoff at it – over a coffee they’ll be saying how it at least shows that you care about their success – even if it’s not their personal style.

Clean Your Room

Switching to Lightning is the ultimate opportunity to take a look at what you’ve got in the system and check if it still works. Here’s a way you can do that:

Metadata

Split your metadata into four categories – Bin, Keep, Change or Introduce. If you’ve got code that could be retired and turned into Process Builder or Flow, now’s the time to do it. Have conversations about this – yes, could lead to a decision about starting a new org, depending on how complex it is. Don’t blame Salesforce for that – use it as an opportunity to keep the best parts, bin the bits that aren’t used any more, enhance existing processes and make a fresh start.

  • Go through your data model – objects and fields
    • Could you retire any of your custom fields?
    • Do you have any redundant custom objects?
    • Are you using standard objects the right way?
    • Any integrations in place that
  • Go through your automation and decide what needs to stay on as code, what could be managed by Process Builder or Flow
  • Review the packages you have installed.
    • Are they still relevant?
    • Do they work in Lightning?
    • Are there any components by Salesforce Labs on the AppExchange that could do the same/a better job in Lightning?
  • Look at your Visualforce pages
    • Do we need to re-skin them using the Lightning Design System?
    • Do we need to rebuild them as Lightning components?
    • What do the Lightning readiness reports say?
  • Definitely take stock of your reports and dashboards
    • Which ones are still relevant?
    • Are there any that could go?
    • Devise a strategy for the dashboards – is it worth showing unused ones in Lightning?
    • Could you perhaps take advantage of Einstein technology?
    • Clean up your folders
  • Profiles and Permission Sets
    • It’s worth considering moving from a model of using multiple profiles to a select few, with function-based permission sets. Tweet me if you want to know more about that.
  • Naughty buttons and links
    • Buttons exist as actions in Lightning
    • URL hacks don’t work in Lightning – you’ll be able to pre-populate fields via actions in Lightning (no more cutting corners)

Data

The next biggest thing is to look into what opportunities your metadata design decisions present for all that data you’ve collected over the years.

Typical opportunities might include:

  • Creating a backup strategy
  • Archiving old and irrelevant data
  • Moving data between fields
  • Re-parenting records to accommodate new object relationships
  • Einstein analytics

 

Plan Your Training

There are many ways to train people. In a Lightning switchover, there are interesting approaches to training, too.

  1. Business process.
    • If your business processes have changed, your users will need to know about that. Consider introducing screen flows as a way to guide users through a process, such as setting up an Opportunity.
    • Consider using Path and writing Guidance for Success.
    • Switching to Lightning gives you a fab opportunity to make the application do much of the heavy lifting when it comes to training.
  2. Productivity.
    • Lightning experience comes with many productivity features. That’s the best time to build a Trailmix
  3. Try this out: if you’re a fan of classroom training, you can share your most important decks as files or even build your own Lightning Components to ensure the key concepts are available at first glance.

Start Now

There is literally no good enough excuse not to be transparent and start training your users before you’ve made the switchover. Start nice and early – while you’re still figuring it all out. Then they can tell you about features they really think will help to increase adoption. Don’t limit it to just superusers either – include your superusers and then ask them to invite interested people to engage early too.

There are Trailmixes galore that you can use to start acquainting all types of users with the new features they can take advantage of in Lightning; what they can’t really start working on is your new processes because they’ve not been designed yet. But that will come later.

Here are a few Trailmixes you could hand out to get them started:

Share This: