In my prior post, I raised the question of why traditional developers should consider Salesforce Developer as a career. I also reviewed some aspects of how Salesforce has evolved over the years into a deeply technical developer platform that requires a community of serious developers.
In this post, I’ll focus on what it means to be a Salesforce Business App Developer and look at the capabilities of the platform that require sophisticated development skills to achieve success with an architecture that is both declarative and programmatic.
Complex business systems contain many moving parts. Whether they are designed to run in a browser, on the desktop, or in a mobile device, nearly all apps require a data store, a user interface, navigation, and actions to invoke behind-the-scenes logic. More complex business systems require reporting and analytics, and global enterprise customers need localization.
Don't forget security, as all those custom pages and their logic must enforce the rules around who should see what and who should be allowed to interact with which data and processes. You’ll also need some back-office functionality to manage all those security settings.
The unfortunate truth is that because many of these elements are ubiquitous to any sophisticated business application, you often end up building them again and again for each project. The customizations specific to your business are where the greatest value resides, and typically where the greatest development effort is required. It's a lot to build and a lot of effort to maintain and enhance going forward.
What if you could leverage a platform that allowed configuration of these common elements—let’s say 80% or more of a system—rapidly, easily, and without any code? What if you could leverage a platform that would allow you to focus your development skills on the more complex and distinct aspects of your application, a platform that even provides the majority of these elements ready to go, right out of the box? Why wouldn’t you? It's important to remember that successful application development is about more than just being successful as a coder, or throwing code at a problem.
That's what Salesforce is: a no-code/low-code platform that takes care of those repeatable pieces for you, while still allowing you to customize your application as needed, both declaratively and programmatically.
Let's look at how the key pieces of the Salesforce stack work together for a business app developer. It all begins when a customer is provisioned with an Org (a Salesforce customer instance), which is essentially a dedicated space in the Salesforce cloud. Users with administrator permissions use a browser-based developer environment, known as the Setup area, to configure all facets of their application and its security.
All database tables in Salesforce (referred to as Salesforce objects) belong to an Org and are automatically provisioned with a basic user interface. Functionality such as navigation, menus, search dialogs, page layouts, list views, detail views, and edit and data entry forms are all automatically created for each entity. In addition, standard data management CRUD (create, read, update, delete) actions and any additional processing logic specific to each entity are also created.
All of this is provided out of the box for a huge collection of pre-existing tables (Salesforce Standard Objects) that typically support the core CRM features such as Account, Contact and Opportunity. Custom tables (Salesforce Custom Objects) can also be created to represent any business entity. Entity schema, data relationships, custom validation rules, and user interface security rules—and much more—are all configured rather than coded.
The newer generation of declarative logic tools, Lightning Process Builder and Lightning Flow, allow for extremely sophisticated automation processing and can include the materialization of a built-in user interface or provide the ability to add a custom user interface. Lightning Flow emulates structured programming, albeit with a visual metaphor in its builder.
Lightning Flow Builder : flow example courtesy of Jennifer Lee - Salesforce MVP - https://jenwlee.com
The platform also provides a scalable message bus (Platform Events) that promotes an event-driven architectural model, and it supports both the declarative processing tools as well as programmatic logic.
It is typically when customer functionality exceeds the capabilities of the declarative tools that programming a custom user interface or coding automation logic is needed. A Salesforce developer must know when to step beyond the declarative tools, as well as how to properly design and implement their Apex, Lightning Web Components, or Visualforce pages. Their goal is to effectively and efficiently interface with the declarative metadata driven functionality. Here is where solid development skills, if properly honed, will find high demand.
The Apex programming language has been around for well over a decade. While similar in appearance and syntax to Java and C#, it has significant differences. It’s primarily designed first and foremost to process Salesforce data on the Salesforce cloud platform. It is aware of all of your Org's metadata, all of its declarative elements and processes, and all of its data entities.
Apex binds to all data objects and can manage object-, field-, and record-level security. Additionally, it can process inbound email and send outbound email, perform outbound web service calls, and process inbound web service requests from external applications. Apex is able to run asynchronous jobs, be scheduled to run high volume batch data processes, be invoked as a low-code service from a declarative process, and much more.
Both sophisticated and complex, Apex has evolved from a simple stored procedure-like scripting model (Triggers) to a fully object-oriented and rich programming language with classes, inheritance, interfaces, properties, and exception handling. It provides special data types, operators, and built-in system classes that promote efficiently-written code that can safely execute and share scaled resources in a multi-tenant environment.
While multi-tenant processing constraints (Governor Limits) on Apex have been relaxed significantly over the last few years, the currently evolving serverless runtime container (Salesforce Functions now in beta) will allow developers to write granular microservices in Node.js, Java and other languages. These are expected to allow elastic flow of low or high compute processes in the language of your choice, fully context-aware of your Salesforce Org, with the goal of true elasticity and scalability, simple to invoke from declarative automation.
The Salesforce user interface, whether Classic or Lightning, is also automatically materialized at runtime by the platform architecture.
Your custom components can tap into the powerful standard component library and leverage all of the same secure data services. They can also be added to any Lightning application or record page, following a similar low-code development pattern to build a powerful user experience. You can even build applications off-platform using the open source version of the Lightning Web Component framework, whether or not they integrate with any Salesforce data or logic.
Even teams of just one or two developers need tooling and support for robust development and Application Lifecycle Management (ALM). In the early days, building Apex, Visualforce, or any other metadata components required the use of the popular and openly available Eclipse IDE. Salesforce provided a free plugin (the Force.com IDE), allowing a developer to create, modify, and deploy their metadata files using the Salesforce Metadata API. As Salesforce built out their APIs to better support developer tooling, other third-party IDE products also evolved. While functional, the early Salesforce developer experience was on the whole...well, let's just say...suboptimal compared to more traditional developer practices.
The platform has always provided isolated sandbox environments. Additionally, they've recently introduced ephemeral development environments (Scratch Orgs) that can be spun up rapidly and easily loaded with metadata and mock data content. The flexibility and programmability of the SFDX model has greatly enhanced the Salesforce developer experience and clearly accelerates the development effort.
These same tools support and promote Unit Testing, both server-side for Apex and client-side JEST for Lightning Web Components. They also increase the performance of the deployment and retrieval of metadata, an integral part of the migration process required for programmatic development on the platform.
The Salesforce developer experience only gets better and better, and its speed of evolution has been truly remarkable over the last few years. The downside has primarily become the challenge of keeping up with its rapid changes and enhancements.
Of course, while you can certainly try to restrict your development activities on the platform to coding, Salesforce developers achieve the greatest success by mastering the platform's declarative capabilities. The more skill and expertise gained on how to best integrate programmatic and declarative capabilities, the more valuable you’ll be in the ever expanding Salesforce ecosystem.
Believe it or not, AppDev is just the beginning. While the platform has so many strengths, no platform should be a closed island, and the Salesforce Platform is no exception. Things get really interesting when Salesforce applications need to integrate beyond the system boundary within a broad enterprise system landscape.
In my next post, I'll provide a high-level overview of the many tools and mechanisms that Salesforce provides to leverage their open architecture in an integrated enterprise system landscape. I’ll show that while many of these mechanisms are indeed configurable without code, the role of a Salesforce Integration Architect greatly benefits from deep knowledge of the general declarative platform, the programmatic platform, open standards around identity and security, plus technical experience within the various domains needing to be integrated. I hope you’ll continue to join me on this Salesforce Developer Journey.