An Ecosystem Of Trailblazers

On October the 17th 2017, Salesforce renamed the “Success Community” to “Trailblazer Community“. This may not sound like a relevant information in a blog dedicated to Salesforce architecture but in fact it is! Let me explain…

Success” was a Sales message: buy Salesforce and you’ll be successful. “Trailblazer” is a humble move from Salesforce, removing itself from the center stage and bringing its great community of customers and partners under the spotlight.

What it says to the prospective customer is, it’s not about our technology alone, it’s about the perennity of your investment in your business critical platform: unlike its competitors Salesforce comes packaged within a community of trailblazers. So yes, somehow, it ends up as a Sales message but one built on the Salesforce Ohana rather than on the product itself.


What I like with the new paradigm is that it’s scalable. In such a high growth economy, scalability is key to avoid bottlenecks. By recognising the role played by the community, Salesforce delegates a part of its Marketing efforts to an always growing number of trailblazers. This number is roughly growing at the same pace as the ecosystem, making it a sustainable model…

Eric Kuhl, Vice President Community, said in her annoucement post

It’s more than just a name. It’s a statement.

For me, Salesforce just discretly changed gear. In a few years time, we’ll look back at October 17 and realise how much of a great move renaming the Success Community was.

So, for the architects, this new name reinforces the idea that Salesforce is only the foundation, the starting point. Salesforce as a business solution takes its building blocks from the good old AppExchange and the AppExchange for Components, as much as the native platform. As a Salesforce professional, you’ll learn with Trailhead, resolve blockers with Answers, expand your professional network with the Community Groups, get a quick tip on Twitter, etc… In other words:

☁️ Salesforce is the technology, 🌺 the Ohana is the solution.

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

Fab 🐸

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 🐸

Salesforce, The A.I. First Platform

Sadly I didn’t manage to make the trip to San Francisco last Tuesday and attend Salesforce’s first developer conference ever: TrailheaDX.

Thankfully though, Salesforce had thought about us all professionals working on their own customers’ orgs, writing code and configuration, deploying from sandbox to sandbox to production, training future users or simply not being able to find a budget to travel to the US… All User Group leaders were sent in advance a TrailheaDX “Viewing Party Kit” pack including all sorts of swags and the secret details for the keynote webcast.
Viewing Party Kit

As a co-organiser of the Thames Valley DUG meetup in the UK, I was one of the happy attendees to this remote keynote and haven’t been disappointed…

The keynote content is, of course, a little different from what you would find at a World Tour event: less sale and more technical information. I particularly appreciated some insight to the Winter and Spring ’17 releases… There was also a mention of the new cloud, the e-Commerce Cloud, just one week after the announcement of the Demandware acquisition. If you want to know more about TrailheaDX in general, I recommend you read Alba Rivas’s recent post on the subject.

Alex Dayon
But make no mistake, the big announcement was about Artificial Intelligence. Salesforce has seen quite a lot of innovations along the years: “the social platform”, “mobile first”, “API first”, … now “AI first” as announced by Alex Dayon. Unlike the previous phases though, “AI first” is not just an architectural update, it’s an entire new paradigm. One that I would say is taking componentisation to the next level and is about to blow your consultant mind off!

“AI first” is not just an architectural update, it’s an entire new paradigm

With a componentised (Lightning based) solution, implementers don’t write bespoke code any more but reuse well tested components built by niche specialists developers and deliver a solution which is declarative, still highly granular. Componentisation doesn’t mean that we won’t need developers any longer but, typically, developers will build and sell multiple small components to many customers around the World rather than one big custom app to one unique customer. Implementers (IT or SI) will either re-use components or build low code applications. This is very much in line with the evolution of programming languages and the never ending addition of abstraction layers, IDE, libraries and tooling to simplify the developer work, now all packaged in one component.

So, what’s all about this AI first platform? Well, the AI components that implementers will use in their solutions will bring some capabilities to help on a specific task (like “guess the most realistic probability to close a deal”) but without being directed on how to provide this information. It will works thanks to the clever algorithms (Artificial Intelligence) embedded in the component accessing a huge amount of data and the relevant CPU power to process it. The first attempts may fail (for instance a few 80% opps may not close in the end) but then the system will learn and improve with time… without modifying its code!

The system will learn and improve with time… without modifying its code!

As you read more about Salesforce AI-first platform in the coming months, try and figure out use cases for yourself or your customers. What will you do when Salesforce releases the technology to its customers? No doubt Salesforce’s new strategy means that it will develop its A.I. footprint and continue acquiring specialised startups, so, stay tuned!

[Edit 1]: Salesforce has just released a new Trailhead module about AI basics. It’s a fun way to get a better understanding of AI and how could it help your customers.
Salesforce Einstein
[Edit 2]: Salesforce provided more details about it’s AI offering (“Einstein”) at Dreamforce 16. Salesforce’s AI algorithms will do the leg work for you. The big amount of data required to train these algorithms will be provided by Salesforce not by the customer. The Data Scientists who build the AI algorithms will also be working behind the scene, in Salesforce “labs” (Data Scientist as a Service anyone?). This means that in my example of “opportunities with a real chance to close” the solution will be already trained before go-live and not six month later thanks to trends and patterns already known by Einstein.

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

Fab 🤖