Salesforce Diaries

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

I'm writing this article as the second of my CTA series, and I want to walk through some areas that you should really think about when doing the CTA exam and aspects that need to be though about in unison as their impact is wide reaching in the solution. I'm going to call out a few examples in this article to get people thinking and be switched on, on the day of the board. (1) Data Model - Master-Detail or Lookup The use of Master-Detail and Lookup fields has a very stern impact on the Sharing Model. 'Who can see what' suddenly is driven by a parent object and not the object in question itself. Whilst this may seem very trivial it can lead to the downfall for a lot of candidates, and it's something to keep in mind very closely. When doing the Data Model, consider the Sharing Implication hand in hand. If you have time do a sense check for what kind of objects and records the users in the system need to see, and does your sharing Model combined with your data mod

The Salesforce Certified Technical Architect (CTA) credential is the ultimate credential in the Salesforce ecosystem and one that is extremely difficult to obtain, however it worth gold-dust in our industry and really stands you from the crowd. I would stand firmly and say that in the Technology Industry this is definately the hardest credential to obtain and proves that you really know your stuff about enterprise architecture and are one of an elite few. This is one of the hardest things I have done in life, and therefore it is my biggest accomplishment. Salesforce CTA's are a special and elite bunch. Here are the reasons why: ( 1) Consultancy Ability : You need to be a strong Salesforce consultant and on-the-spot thinker to be able to pass this credential. You need to know your stuff really well to be able to apply it in a highly time pressured scenario, and be able to explain highly technical concepts in a manner that makes sense. This is an art, and one that