Considerations for a Phased Approach to Your Lightning Rollout

As an admin who is moving your org towards Lightning Experience, nothing is more exciting than getting the green light to develop your rollout plan. And as you get started, you have done the pre-work that includes running the Readiness Check and identifying any gaps you may have to close. Now, you have to decide the best way to approach your rollout.

Generally, you can take one of two approaches to your rollout: org-based or phased, and a phased rollout can be done based on a Persona.

Did you see that “Persona-Based Rollout” is highlighted as the preferred approach? This totally makes sense. There are a lot of good reasons you would not want to use the org-based rollout approach, especially if you’re managing a large org.

Preferred Approach

So, let’s look at the phased approach options. I have seen a few teams that start out enabling Lightning Experience for a trial group using permission sets, and then later the user population gets expanded based on Personas or Profiles. Be sure you have a solid understanding of the relationship between personas and profiles. Does each Persona have their own profile? Or are some personas obtaining their permission and access through a combination of Profiles and Permissions? You want to know because here is where your rollout could potentially get tricky.

Most of the readiness assessments and rollout strategies can lead you to assume that once you re-configure certain items, you are now all set for Lightning. Well, while that is probably accurate, you may just have broken some of the functionality your users that are still in CLASSIC use and need.

Let me give you a specific real-life example: To make things just a tiny bit easier for your users, we have replaced the Standard Button to create a NEW Contact with a custom list button that will pre-populate the Account name and Phone Number using URL parameters. You have 2 users (Classy and Lexi) with the same profile, but Lexi has Lightning Experience enabled through a permission set. For Lightning users, clicking the button will no longer pre-populate any of the default information, so Lexi will have to enter it manually, while Classy can go about life as usual. (Maybe not a big deal in this case, but stick with me as we are looking at solutions and impacts).

To still provide this feature to Lexi, you create a custom Account action that looks like this:

You then add the new action to the Salesforce1 and Lightning Experience Actions section on the account page layout, and, in a perfect world, you would remove the custom list button from the contacts related list, because you know it’s not doing the job for your Lightning Experience users. However, if you do that, your Classic users will no longer be able to create new contacts from the account page.

So, what are your options?

1. You keep a single page layout and communicate to your Lightning Experience users that they should use the new account action you created for them and be aware that using the related list button they are used to will act differently

2. Duplicate the profile and append the name with “Lightning” (or something like that). Do the same for the page layout. Now assign the Lightning Experience page layout to the Lightning profile. At this point, you can remove the related list button and give the user a single option to create a new contact.

Things to keep in mind

• As a general rule, cloning a page layout might make sense if changes to the core are needed (i.e. related list buttons or columns, fields, custom links, buttons, etc). However, if most of your changes are limited to the shell (i.e where to place a Lightning component), you should not need to clone your page layouts.
• If you have a LOT of profiles and page layouts the option above may not be feasible because maintaining the increased amount of profiles and page layouts may outweigh the user benefits. Your best option might be educating them about the differences and best practices based on the UX they are currently using.
• Page layout assignments are not dynamic (unfortunately). So, if you have users switching back and forth between Lightning and Classic they will still encounter problems because only one of the page layouts can be assigned to them. Be sure to train your users and remind them of the specific differences until they spent 100% of their time in Lightning Experience.

Resources

Trailhead: Lightning Experience Rollout, Customize Record Details with Page Layouts
Salesforce Admins Blog: Pro Tip: Boost Productivity with Activity Actions in Lightning Experience
Webinar: Sales Cloud Lightning Migration Best Practices
Admin Hero Blog: Getting Started with Lightning Components and Record Pages