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 custom functionality outside of standard edits on records. Today the various powerful no-code options to facilitate customisation are constantly evolving and being extended over time. This is making Salesforce deeper as a platform, and also allowing more functionally rich implementations to take place, without the need to write complex lines of code. At the same time the APEX coding platform has grown offering more features and capabilities making coding simpler, easier and more performant for the user. Here are a few of the key features released by Salesforce and the benefits they have brought to the project delivery process.

Salesforce Process Builder

Process Builder is the replacement for Salesforce Workflow rules. Process Builder offers a visual approach for developing custom workflows, whilst also adding in additional capabilities. You can do: Field Updates, Launch Apex, Fire Platform Events, Email Alert, Create & Update Records, Post to Chatter, Submit Record for Approval. The capabilities to create and update related records and fire off platform events enable developers to move away from writing custom APEX triggers, allowing the same functionality to be achieved via a declarative approach.

Lightning Flows

Visualforce Pages were the common approach for creating visual step by step processes to make it easier for the user to perform a critical piece of functionality. This required the creation of multiple Visualforce pages with their associated APEX controllers, or show and hide sections of a Visualforce page based on step completions in a process. Now this can be easily achieved using Lightning Flows. You can now show custom screens, fetch, create and update records and have custom decision-based flows to implement a custom process. These processes can be fired from the Community, from custom Salesforce buttons, from Process Builder, Visualforce or within a Salesforce page to realise a key business process. These processes can be built declaratively and easily without the need to deploy or write unit tests, thus allowing your business to deliver with much lower development effort, increased extensibility and reduced maintenance overhead. In addition to this, as this feature gets built out further by Salesforce over time, you can immediately make use of the enhanced capabilities. When building custom visual processes in the platform consider using Lightning Flows first before building custom Visualforce pages or Lightning components. This should be the preferred approach.

Salesforce Community Builder

Remember the days of Salesforce Customer and Partner portals, built on Salesforce Tabs and Visualforce? In 2015, Community Builder was released, enabling drag and drop building of Community pages and allowing an organisation to spin up customer-ready communities in a matter of weeks.  These would previously have been months-long projects, requiring multiple custom Visualforce pages to deliver this functionality. The Community Builder also allows you to segregate community pages and content by audiences to drive a targeted digital engagement strategy. When creating a new community or revamping an existing community, leverage community builder to quickly spin up a rich and functional theme-driven customer or partner community to minimise development effort.

Platform Events

Platform Events are a new declarative approach to integration. Previously there was a reliance on custom integration approaches via APEX or Workflow Rule – Outbound Messages. Platform Events rely on a publish-subscribe model, placing the reliance on receivers to build the functionality to subscribe to and receive a platform event. This is an asynchronous means of performing an integration, and decouples the sending application from the rest of the process. Typically, this would be combined with a Middleware solution in the form of an Enterprise Service Bus to receive the details in the platform event, make any necessary call-backs into the Salesforce platform and then forward the action on to the recipient system. Platform events can also be used in an inbound stream – one can be fired to a Salesforce org, which can then launch a process builder or an APEX Trigger to execute the next actions in your Salesforce org.

Platform Events provide the following benefits:

• Multiple subscribers can listen for an integration event in the Salesforce Platform and perform the next steps in a business process.

• Decoupling of systems that send and receive events simplifies your integration build and maintenance.

• Declaratively fire or receive an integration event in the Salesforce platform, thus reducing the complexity and build time for an integration flow.

• Platform Events generated via Heroku Connect do not count towards the Salesforce Inbound API Limit. This is a crucial advantage, if you wish to do near-real-time messaging into the Salesforce platform, without breaching the standard API limits.

APEX & Visualforce

Lightning

No article on the evolution of the Salesforce platform can be complete without mention of the introduction of Salesforce Lightning. Salesforce transformed the way applications and components are built by introducing the Lightning framework. Drag and drop approaches to building platform applications, and a re-usable component ecosystem have truly allowed admins to deploy rich, functional apps in their orgs, without needing to write lines of code. The Lightning Components themselves leverage a new architecture, relying more heavily on client-side UI interactions and server-side data processing. This reduces the number of server-side calls required when interacting with a custom component, providing a much faster and richer UX than was possible with Visualforce. This has now become the defacto platform for building custom code and components, and I’d recommend all customers re-assess their use of Visualforce in their org and look to migrate to using Lightning components.

Salesforce DX

Salesforce DX brought about a large transformation into how we go about creating, packaging and deploying Salesforce logic and how teams are managed in a Salesforce project. DX is founded on the notion of Scratch Orgs – temporary orgs which a developer spins up when they are working on a certain piece of functionality. Once this functionality has been verified, tested and completed, it is packaged and deployed into the version-controlled code repository, which in turn sends the code-base to a combined development build org. Using this approach allows us to control and package all the components associated to a certain use case or item of functionality, making the process of decoupling and deploying individual changes much more robust in the Salesforce platform.

Summary

In this article, I’ve walked through the advances in the Salesforce platform over the last few years, that in my experience have been the most beneficial and had the most impact. I’ve focused this article mostly on the core Salesforce platform and clearly when you couple this with the evolution across all the Salesforce Clouds you get a sense of the innovation and transformative power at play.

With the growth of the platform, it can now be difficult to find a partner who invests enough time with its architects, consultants and developers to allow them to keep on top, understand the best practises as they evolve and advise clients on the best way forwards. At VRP, we use technical architecture boards, bi-weekly lunch & learns and strong presales and delivery governance to broaden our internal horizons and ensure that all our clients can benefit from a CTA-inspired culture.

Get in Touch

About the Author

Mitesh Mistry

Chief Technology Office (Asia Pacific), VRP Consulting

Mitesh is CTO of VRP Consulting in Asia Pacific. He is a Salesforce Certified Technical Architect (CTA) and Technical Delivery Manager, specializing in cloud computing, business intelligence and solution architecture.