A Componentisation Fairytale

I recently had a delivery saved by the componentisation brought to the Salesforce platform by the Lightning Experience. I thought I had to tell this story as it sticks so much to my beliefs of the architectural benefits of components frameworks over more “classic” web-app style configuration.

The context

It starts like this:
🧚‍ Once upon a time, a team of consultants were migrating their customer to the Lightning Experience. The customer’s actual requirement was to retrain their staff and deploy the mobile app. After a quick gap analysis, we identified that the solution footprint was qualifying for LEX upgrade (all objects supported in Lightning, that was Winter ’17 by the way). This was an ideal situation since the work required to upgrade to Lightning was also configuring Salesforce 1 at the same time. It all went well: config, UAT, training, cutover.

The drama

A few weeks after go-live, the news came in that one niche use case had been missed in UAT (not part of the customer’s test scripts) and that it was becoming a massive pain point. The Sales Ops team was used to go through their list of today’s tasks on the home page in Classic, calling back customers one after the other to address all sorts of issues. The routine didn’t even involve a single click since thanks to a custom mini-page layout they had all the required information handy when hovering on a Task.

Classic Task detail page

Accessing the Phone number was now requiring several clicks. This issue laid with a combination of reduced capabilities at the home page level and the record detail page level plus the specific constraints found on standard objects in general and Activities in particular:

  • The Home page Tasks didn’t support hovering.
  • The Task’s page layout wasn’t showing the Contact’s phone number whereas it did in Classic.
  • The Task Phone field is not exposed, preventing the consultant to build workarounds.

Not satisfied with the current behaviour of Tasks management in Lightning, we realised we would be able to deconstruct part of Salesforce and rebuild it with bits and bolts found in the AppExchange… Welcome to the world of componentisation! 🎉

The fight

We identified a Salesforce Labs components in the AppExchange called “My Tasks“. Although there was some hope at first contact, its lack of customisation turned out to be a major pain. The fact that it was opening Tasks in Edit mode meant that we wouldn’t be able to show any formula should we find a way to, somehow, pull-in the missing Phone number. So, we dropped it. Still, I left a feedback to let the developer know about what I thought were areas of improvements.

I investigated ways to do things differently but hit product limits:

I’d like to take the opportunity and remind you of the Salesforce professional rule #1:

Always leave your feedback in the AppExchange. 🛒
Always submit or vote for your needs in the IdeaExchange. 💡

So, during this investigation, although no immediate solution was found, I left behind me a trace that will later save my day!

The hero

Introducing Anthony Barrow, the creator of Mopsy. Anthony bumped on my AppExchange feedback. At the time, he was looking for a use case to start his journey into Lightning components development. He used my feedback as a set of requirements and built Mopsy, a highly configurable Lightning component to display a list of tasks and their relevant information.

When done, he visited me at the Thames Valley Salesforce Developer Group to show-off his baby.

Anthony Barrow

I was stoned! I waited for Mopsy to become GA and installed it at my customer who loved it! I later re-used it on other Lightning projects to fix a bit of Salesforce which would have otherwise been left untouched with the good old Classic.

The conclusion

I see three things here.

  • First, Lightning builds on the Citizen Developer success story started in 2006, I think, when Salesforce introduced the Developer Edition. It was nice for me to see the solution to my problem coming from a local developer and it validates that the model still works with LEX.
  • Also, one of the key factor of success for “Salesforce’s DE org driven ecosystem” was the fact that besides ISVs, developers have been empowered to create their app, say at the weekend, and publish them on the Appexchange. In return, Salesforce’s apps library was growing the same way the iPhone AppStore was. In Classic, although you could publish something as small as a Report, the trend was to write self-sufficient applications. With Lightning though, the level of granularity of the code pushed to the AppExchange is reduced drastically to potentially focus on a tiny use case. It means that we should see more and more of these components landing on the AppExchange to address very niche needs, maybe to the point to make finding the right component more difficult than needed. Is it time to improve the AppExchange search engine?
  • By the nature of the framework, parts of Salesforce otherwise non-modifiable are now open for customization. So, as a Lightning solution architect you need to forget about the old fashioned frustration when out-of-the-box doesn’t cut it. You now have a bigger “toolbox“, or should I say a “palette“, full of small components that you can use to refine the behaviour of your next delivery.

The end

I hope you enjoyed this post. Don’t hesitate to ping me on Twitter if you have any comment or question.

Fab 🐸