Rolling out Salesforce Lightning is something most of us have or will shortly experience. If you are an Admin, there is fewer and fewer reasons to not take the plunge and migrate over to Salesforce Lightning.
I have long been pushing our various Salesforce instances towards being able to migrate to Lightning Experience.
We had focused so much time and energy trying to reduce the technical debt to a point we could possibly make the jump. Until we made the decision to shift gears, and actually move into a shiny new org.
But moving to Lightning, has taught me a few things as an admin/dev, and it is time to share! So here are some musings/lessons/thoughts about rolling out Salesforce Lightning…
Learn Lightning, inside and out!
I got to say, there was plenty of things that stumped me about the move across to Lightning.
One that ALWAYS got me, was the difference between the Lightning Page Builder, the ‘normal’ page layout builder and what controls what on the actual overall layout in Lightning.
Simplest way to learn this, is imagine the Lightning Page as the top layer, or shell, which allows you to organise the overall feel of a specific page in Lightning.
- This is where you define how many columns you want to display, how where the columns/rows go.
- It is also where you control what displays where. And groups together things like record pages (ie the ‘normal page layout’), any widgets or components you want.
- This is where you can control the sub-tabs which display in Lightning. Like the Related sub-tab or Chatter/Activities
The thing that got me, the most when starting out?
This is NOT where you control the buttons, quick actions, etc visible on the page. For that you still need to go and edit the Record Page.
I don’t know why, but this is one thing that really irritated me the most until it finally just ‘clicked’ and made sense in my head.
The section on the Record Page Layout for ‘Salesforce Mobile and Lightning Experience Actions’ is where you control this.
But remember, you may have a Lightning page for all users. But if you have a Record Page Layout for different profiles/record types, then you will have multiple places to manage this and make sure it is correct for everyone.
Lightning is about speed and efficiency, so use it!
So use the opportunity of moving to Lightning as a way to change how your processes work. If you are migrating to Lightning, you will have to review most (if not all) processes anyway. So use this as an opportunity to work with your internal stakeholders and improve the workflow for the end-users!
Going through our transformation to Lightning, there was a ‘hit list’ of things we wanted to change.
Depending on your scope re: the project and time allowed, you won’t hit everything. But by identifying and prioritising the ‘top speed boosters’ for your end-users, helps get them engaged in the overall project. And by even improving their workflow by reducing 3 or 4 clicks, you would be surprised how quickly this all adds up to measurable improvement for your users.
Even reworking your page layouts, to display the information the end-user needs can add to the overall benefit of Lightning.
Why is this important?
Rolling out Salesforce Lightning, as a new User Interface, gives you a lot of flexibility. So the more you can do in this area, helps when it comes time to rolling out the new system and getting your users to buy-in and actually use Lightning!
It all ties back into driving engagement and adoption. Which is the reason you are doing this change in the first place, isn’t it?
It is a bigger jump for your dev team than you may realise…
Through this project, I had the benefit of working with a number of top notch dev teams, but specifically the Salesforce dev team.
But changing from Classic to Lightning, had a massive up-skilling implication for us as a company. And we ensured we gave the development team time to learn the ropes with Lightning Pages/Components/etc.
To help out, we also tried to go as ‘out of the box’ as possible. But no matter how hard you push for this, there are likely to be business rules which need customisations.
So don’t underestimate this!
Allow your dev team time before the migration to up-skill and learn about how the new Lightning framework fits together.
I would always loved to give our dev team more time for this, but keep in mind that you do have to try and balance this with likely delivery ‘windows’ within your organisation.
We had a lot of other projects happening, both before and after this porject. So we had a specific time frame we had to aim for to release in. But we made it, and I think we managed to get a decent amount of time for our devs to learn the new world.
Think about the data!
As previously mentioned, we made a decision that it would be easier for the teams involved to deliver Lightning to the business as part of a new CRM. This was instead of the option to try and update/upgrade things in a Salesforce org that was around 12-14years old!
For us, though this meant we also had to plan in a CRM Data Migration… YAY!
Now, you might not have the need to go this route. But data is still very important in the project.
What data is visible, can in some circumstances be controlled by Lightning. Do you use Customisable Forecasts? Nope not Lightning compatible, instead you will need Collaborative Forecasts. Salesforce have done a massive job in trying to plug all the gaps between classic and Lightning, but some still exist. (Like Close Date showing in US Date format, regardless of locale settings – very confusing everywhere that isn’t US/Canada!)
So, remember the data.
Remember what you need your users to do in Lightning, and make sure they still can do it.
It could be simple tweaks to page layouts (as per my first point). But you need to make sure everything that is needed, is visible to those who need it.
And where there are system or feature differences, weigh up does the Lightning alternative work for you? And if yes, what training/coaching do users need to get used to the new way of working? Then this should feed into your overall training plan, as remember, Lightning is very different for end-users!
Remember your Users (aka avoid the Bambi effect!)
Any change of this nature is going to be big! As admins and developers, we have now been conditioned re ‘all things Lightning’. And have been for a number of years – even if you haven’t used it before yourself.
Everything Salesforce related has been pushing Lightning now for a number of years…
But the biggest thing here is, don’t underestimate the change for your end-users. Remember this will mostly be brand new to them. And some will likely resist the move, at first…
One anecdote for you, which was something that I had to fight hard against myself. Don’t underestimate the impacts of some of the ‘out of the box’ features that come with Lightning. Remember as Salesforce users we have seen things like Kanban and Lightning Consoles in every Salesforce demo and feature release now for a number of years…
And this is how you want to ensure you avoid your end-users becoming like the proverbial ‘deer in the headlights’ (aka Bambi).
When we rolled out Salesforce Lightning, our sales and finances team LOVED Kanban View on their relevant list views. But it was something that was easy for the delivery team to skip over or avoid, because for us we had seen it all before, and it wasn’t part of what we were actually developing…
But we didn’t deliver that as a feature… Or did we?!
Sometimes the project team got a little disheartened, myself included. Why? Because the meetings you go to with end users, they would always say how ‘we love these things’, but those were the Salesforce Lightning ‘out of the box’ features, like Kanban.
But to make those features work and work properly for your teams, there is a lot of effort that is needed to ensure they work as expected. You have to adjust all the things that go on ‘inside’ Salesforce, in the places end-users don’t really see! Like your workflows and validation rules. These things simply have to be in-sync with what you are trying to deliver with Lightning.
So we might not have created Kanban, but we did everything behind the scenes that makes it work fluidly/’drag and drop’ in a system. We updated the workflows, approval rules and validation rules behind the scenes to allow users to be able to ‘simply drag and drop’ records into the new status.
In the old classic workflow, we would just throw up a validation error (not best practise, but so many orgs do this), if something was missing. But now moving to Lightning, this gave us a huge opportunity to rethink how/when certain information got entered in Salesforce.
Rolling out Salesforce Lightning? Engage the top brass, and the foot soldiers
A project on this scale, will need so many different people to be involved.
Success is paramount on engaging the top brass (ie senior leaders/stakeholders) and getting them involved in the process. And likewise, you have to also get the foot soldiers (or your super users) comfortable enough to be able to help take some of the questions.
We treated this as much of a culture change, as it was a system change. And that seemed to work really well for the project.
There are a lot of ways to do this, and you can search until the cows come home about Change Management practices. But put simply you and your team will need allies and generals. People on your side to help push your message across the teams / organisation and drive adoption.
And the biggest lesson here, is to remember that everyone reacts to change differently. Doesn’t matter what it is.
But by treating this like a cultural change, and preparing to support people as they went through the ‘change curve‘, you can help ‘short circuit’ the pain of change. You won’t get rid of it completely, but you can come up with a plan that helps people transition through to the ‘new way’ as quickly as possible.
And finally…
There is a lot to go through. The key to success really is to plan. I have touched on a number of facets to what we learned as part of our Lightning migration. Everyone has a different starting point, both re: Salesforce instance but also experience with driving changes within an organisation.
Planning your project will put you in good stead, and by scheduling in the change on your roadmap, you can use it as a golden opportunity to revisit almost everything to do with how Salesforce works at your organisation.
As part of this revisit, decide what are the must-haves and things that need to change, versus the nice-to-haves. And also use this as a chance to try to identify any risks to the project.
But don’t just focus on ‘must-haves’. Sometimes the nice-to-haves are the things that also help you get people excited about a new system…
Comments below!
Have you recently moved across to Lightning? What are your tips or lessons for moving to Lightning?
Or if you are planning on moving to Lightning, what are the things you are most looking forward to (or nervous about)?