Salesforce Diaries

A poignant topic, but something that is really important to keep in mind. We never know everything, and despite reaching what one would think is the pinnacle of a Salesforce career, there is always more to learn. The moment we think we know everything, the journey stops, and we become a brick wall to ourselves, the clients that we serve, and overall the world around us. So, having gone through the Salesforce CTA journey, and having spent the last few years architecting solutions with the CTA badge, here are some of the lessons I have learnt. (1) Salesforce as a platform keeps evolving. Since passing the review board, new integration patterns / approaches have come out such as Change Data Capture and External Services. I recently did a presentation on the topic of integration, and was delightfully asked by an audience member, so why not 'External Services'. Hadn't come across this approach before, which highlights the importance of staying up to speed with the developments o

Top 10 Expert Salesforce CTA Tips Below are my list of top 10 tips for the Salesforce Certified Technical Architect (CTA) exam as published in the Salesforce Architects Trailblazer Community . CTA Pro Tip Number 1   A good architect is always confident and self assured, but remains honest to their knowledge. Present your solution confidently in the review boards, but also be honest on where you may have a knowledge gap. 'I'll get back to you on that', is always better than a white lie :-). And secondly, confidence in delivery of your presentation is half the battle so make sure you deliver your solution with faith, conviction and confidence. CTA Pro Tip Number 2   This one relates to large data volumes and LDV management. It will sound common sense but a lot of people still architect this incorrectly. Typically speaking objects with a volume > 1M records can be considered an LDV object.. As a CTA, it's really important to know and be able to arcitulate what performan

Integrating with the Internet of Things In this article I talk about some integration patterns that can be used when wanting to integrate multiple devices with Salesforce. Imagine the scenario where we are a fitness tracker manufacturer and we want to communicate real-time or near-real-time updates from a fitness device through to Salesforce. Typically this would be challenging due to the issues of LDV (Large Data Volume) and the Salesforce Inbound API limits which would make it near impossible to build a solution making calls into a Salesforce org. Despite these large challenges, there are still patterns we can adopt and use to make this form of use case work, and drive automations from the Salesforce platform. Lets work through a few examples and I will detail out the architectures that can be used to make it work. Scenario 1 - Connected Fridges We are a company that manufactures smart fridges. We want to be able to send real-time alerts and notifications to customers w

Salesforce Integration Approaches Most if not all enterprise Salesforce projects involve an element of integration. In this article I have summarised 3 common integration use cases that come up and an optimal approach for solving those use cases. This is useful for the CTA exam when certain scenarios come up and you have to consider possible approaches that can be used to solve them. Pattern 1 - Remote Process Invocation - Request Reply Scenario  In this scenario we want to make a callout from Salesforce to a Remote System and receive an immediate response. For example, we want to make a callout from Salesforce to SAP to check on Stock for a particular Product chosen on a Salesforce opportunity. We want the stock check results to be displayed in real time.  Approach Create a Lightning Component which has an Apex Controller that can make a REST or SOAP callout to an external service. Create a button on the Lightning Component to invoke the callout method in your Ape

How Implementing Salesforce has Evolved Little bit about me I started my Salesforce career in 2009, working as a Graduate for Deloitte on a large Salesforce Customer Portal implementation for a media client in London. Having worked through multiple roles from developer through to Program Architect I have had a chance to see the growth and evolution of the Salesforce platform. In 2018 I obtained the elusive Salesforce Certified Technical Architect qualification, the topmost credential in the Salesforce ecosystem and am now the Head of Architecture for a global Salesforce Silver Consulting Partner, VRP Consulting, helping our enterprise clients innovate on the platform. In this article I will be talking about how the platform has evolved and how some of its newest features are transforming the way Salesforce is implemented. How things began Back in 2009, the declarative options were more limited and required the use of APEX code to deliver any form of cus

The Role of the Technical Architect In your standard Salesforce project, there are multiple roles involved: Business Analyst, Quality Assurance, Project Managers, Developers and the infamous Technical Architects. The success and cohesion of the team and steer of the project is heavily based on the quality of the Technical Architect involved. The architect plays a critical role throughout the lifecycle of the project from Presales through to Delivery & Handover, and it with their expertise that the project evolves. The TA must provide strong support for all members of the project team, and is the heartbeat of the project team as the delivery carries on. “The binding glue of a Project” The role of the Technical Architect is to have a deep understanding of the Salesforce platform, alongside supporting technologies, but also have a strong understanding of what the client is intending to do. I like to think of the Architect as “the binding glue of the project”, suppor