This year, Europe’s largest Salesforce Community gathering – London’s Calling – was back for its 11th year and it did not disappoint. From solo admins to enterprise architects to consultancy developers, there is always something for everyone, and this year there were so many amazing talks that I was deciding between 2 or 3 in every time slot. I knew that AI was going to be a big deal this year, and what became clear to me as I went through the day is that we are past the ‘hype’ phase of AI and moving firmly into the era of implementation. I came away from it all with pages of notes, new techniques to get the best out of AI and a new perspective on Salesforce security. If you didn’t make it down to London this year (or even if you did!), here are the top things I learned about all things Salesforce.
Leveraging AI in Salesforce: Strategic Implementation Tips
Aidan Harding delivered a very insightful presentation on ‘Claude Code for Developers’ that focused on the concept of making AI work for you – not the other way around. He emphasised the importance of first considering whether a task should utilise AI or if it is better served by a deterministic tool. I really appreciated this perspective in the world of AI-everything, and I think he was right on the money. His approach of thinking about what parts of a task should be scripted and which parts should be delegated to an agent, which then runs the script at the right time, has inspired me to start thinking about how to implement more of this “high-effort AI”.
Where we think carefully about our detailed prompts, create tailored context resources and tools for the agents to use and put in the up-front effort needed before handing it off to Claude autopilot. In my experience using plan mode with Claude, this up-front effort really determines the success of the whole endeavour, and I was excited to find that Aidan aligned with me on that and to see the tips and tricks he had for me to incorporate into my development. A specific tip I’m keen to try out myself is using the learning-opportunities skill for Claude to see how it can help me improve my knowledge at the same time as completing my dev work.
Salesforce Security Benchmark and OAuth Best Practices
Nobody can have missed the Salesforce security breaches in recent times, and Pablo Gonzalez delivered a really clear and concise talk on how we can all think about security in Salesforce. The stand-out takeaway from this talk was that when you grant access to a third-party app via OAuth, the scope of the access doesn’t matter as much as the user who grants the access. This is why it’s so important to have dedicated integration users with minimum access to run your integrations – because the Oauth token behaves essentially as the user, with all the permissions the user has. This one definitely made me run home and check my Connected Apps for anything stale or unknown.
Finally, Pablo left us with news of the brand new Security Benchmark for Salesforce, an open-source security standard for Salesforce orgs that provides guidance on the security practices we should all be implementing to protect our orgs.
Optimising Load Times with Experience Delivery in LWR
This one was a hidden gem of a talk from Fabien Taillon on a new feature in my love-hate favourite part of Salesforce: Experience Cloud. For a long time, we’ve had both Aura sites and Lightning Web Runtime (LWR) sites available in Experience Cloud, and I’ve been excitedly watching as the much faster LWR sites gradually gain feature parity with Aura in each release. Now in pilot we have Experience Delivery, which is a game-changer in terms of load times within LWR sites.
This provides us with ways to use Island Architecture – where the static parts of a page are cached and loaded first before discrete chunks or ‘islands’ of dynamic content are loaded – within experience pages to massively speed up the time to the first load of the page. We can now specify which Lightning Web Components (LWC) are fully static and can be safely cached on the server, which contain dynamic islands that must be loaded client-side and which are full client-side components. Not everything is available to Server-side Rendered (SSR) components; for example, they can’t do wire calls to get data or display dynamic content based on user context, but it does have the potential to speed up load times for static content such as public homepages. As a beta feature, we also have the ability to designate an Apex data provider, which can provide live data to SSR components, so I’m excited to see that go GA in the near future – fingers crossed!
Applying the Salesforce Well-Architected Framework
My day was neatly bookended by the well-architected framework and the principles of ‘Trusted, Easy and Adaptable’. First thing in the morning, I attended a workshop from Lilith Van Biesen and Miriam McCabe where we explored the ‘Trusted’ pillar by identifying anti-patterns and possible solutions to problems within Salesforce security. It was a great opportunity to wake my brain up for the day, and just in general to remember that thinking deeply about these problems and all the possible solutions is central to architecting. That being an architect is truly not out of reach for most devs because we spend so much of our time doing this kind of thinking about how systems fit together and which quirks and pitfalls of the platform they’ll bump into. This session was also a great opportunity to get to grips with Salesforce Archive, which came in from the Own backup acquisition and, as it turns out, has some very interesting implications for record access and security.
While the morning workshop gave me a deep dive into the technical application of the Trusted pillar, the afternoon took that same framework and applied it to a different subject: us. It was a fascinating pivot from optimising our system architecture to considering how we can optimise ourselves using those same pillars of trusted, easy and adaptable.
At the end of the day, I attended a presentation from Pei Mun Lim on how we can apply the well-architected principles to ourselves and make ourselves better in the process. We were tasked with thinking about what makes a person trusted, easy and adaptable, what we can do that AI can’t, and how we can look inwards to improve our projection outwards. She emphasised that ‘well-architected’ people are really just people who empathise, who can think critically and who can balance those soft skills of human connection with the hard skills of getting the work done. Sometimes, as developers, we neglect those human skills in favour of technical excellence, but ultimately, if you’re difficult to work with on a human level, then excellence gets you nowhere.
In a sector saturated with AI, where Agentforce and Claude are mentioned in every second sentence, it was nice to leave the event thinking about the critical thinking and emotional intelligence we possess as humans that can never be superseded by AI. So I absolutely agree with Pei: while it’s important that our systems are trusted, easy and adaptable, it’s even more important that we have those qualities as people.
