One year of Salesforce (three lessons I learned)

6 minute read

When I started at NIST, we used Pipedrive as our CRM system. Pipedrive was a good solution for us at the beginning because it was intuitive to use and easy to administer. But after only a few months, the software was no longer able to keep up with our growth and the increasing requirements that came with it. That’s why we decided to replace Pipedrive and introduce Salesforce. Due to various reasons, this migration unfortunately took place under considerable time pressure. There was hardly any time for a thorough familiarization with the Salesforce platform and a preliminary planning of the project. So I literally made many technical decisions in the dark. About a year has passed now since we introduced Salesforce. I learned a lot of new things and with this knowledge I would make some decisions differently. This article summarizes the three most important lessons I had to learn.

Selection of a suitable development model

There are two ways to make extensive customizations to Salesforce.

Change Set Development Model

The Change Set Development Model is the classic way to develop with Salesforce. A developer (or administrator) uses a Salesforce Sandbox environment. This is a partial copy of a production system that has the same configuration but no data from the production system. Such a sandbox is therefore ideally suited as an environment for development, testing and training. If a sandbox is used for development, the changes must be packaged as a change set and uploaded to the production system. Unfortunately, this approach is very cumbersome because the change sets are created manually. So the developer has to keep a record of every change he makes.

Package Development Model

The Package Development Model is the modern approach to develop on the Salesforce platform. The main difference to the Change Set Development Model is that the result of the changes is available as source code - not just as the state of a sandbox. A modern toolset supports the developer in the creation, administration and deployment of these changes. The advantages of this model are obvious:

  • Team development is drastically improved and simplified.
  • Extensive applications can be developed modularly and specify dependencies between modules.
  • The source code of packages can be managed in version management.
  • The implementation of automated tests and the establishment of a continuous integration pipeline are relatively easily possible.
  • The release process is efficient and supports agile work.

Selection of a suitable technology for automation

Sooner or later there will be a need for automation with every CRM installation. These can be implemented using tools of the Salesforce platform or external tools.

Tools of the Salesforce platform

Salesforce offers various visual tools for automating processes under the name Lightning Flow. Although the tools have a similar scope, they perform their tasks in very different ways. Choosing the right tool for a particular task is not always easy. Roughly speaking, the Process Builder can be used to automate simple processes:

"Screenshot"

With the Flow Builder, however, even complex workflows can be automated and visual sections, such as wizards or tutorials, implemented.

"Screenshot"

If both visual tools are not sufficient for certain requirements, APEX remains the most powerful but also the most complex tool. APEX is a complete programming language with many similarities to Java. In addition, APEX is perfectly suited for development on the Salesforce platform. Database queries for example can be implemented with SOQL queries, which are directly integrated into the language. The use of OR frameworks is therefore completely eliminated.

External services for automation

Salesforce provides several APIs that allow external services to interact with the platform. These include the REST API for accessing entities of the Salesforce data model and the Streaming API for implementing event-based architectures. With these two APIs, it was very easy for us to migrate existing integrations from Pipedrive to Salesforce when we introduced Salesforce.

For example, a typical integration had the following process:

"UML sequence diagram"

  • A user updates a record.
  • An APEX trigger fires and creates an event that is published via the streaming API.
  • The external service receives the event, loads the updated record from Salesforce, and processes it. If the record was changed in the service, the changes are saved in Salesforce.

Developing an external service to outsource business logic or automate processes can be tempting: the development team can work in their preferred language and with their preferred tools, reusing any existing logic and libraries. However, this approach also has some nasty side effects:

  • Tight coupling: Salesforce’s REST API provides direct access to the entities of the organization’s data model. Salesforce and the external service share a common data model. The events merely serve as an asynchronous extension of the data record triggers. Ultimately, both applications are coupled at the database level. This type of coupling is particularly tight and will probably lead to various problems in the long run.
  • Low coherence: The distribution of the business logic between two systems reduces the coherence, which makes it difficult to understand and maintain.
  • Transactions are not feasible with the REST API, which can easily lead to inconsistent data.
  • Bad Usability: In the example process it is clearly visible that the data was changed by the external service after it was displayed to the user. The direct connection between the change and the triggered action is thus obscured for the user.

If it has to be an external service, you should always take the trouble to define a correct interface. This is also relatively easy with Salesforce. APEX classes can be published as REST resources. Individual APEX methods can be exposed via the SOAP API.

Implications of development without code

The Salesforce platform enables users to do extensive customization without writing code. For example, the platform’s metadata-driven development model allows the data model to be extended and customize using a intuitive graphical user interface. The Salesforce platform can then automatically create a significant portion of the user interface. User interface elements such as dialog boxes, record lists, detail views, and forms that you would normally have to develop yourself are automatically adjusted. All functions for creating, reading, updating, and deleting user-defined entities in the database are also automatically available. Thanks to this predefined functionality, developers have more time to implement more sophisticated functionalities.

Salesforce offers several of those tools for this declarative development. Using most of these tools does not require knowledge of development concepts - in particular, no code has to be written. According to a training guide in Salesforce Trailhead, “even users who think JSON is just a misspelled first name can create a robust, complex data model. And even users who think Cron is the title of a science fiction movie can schedule batch jobs”. I find this statement negligent and misleading. Creating a complex data model with a graphical environment is not difficult. This has long been possible with database tools from IBM, Microsoft or Oracle. However, if the data model is also to be high-performance, robust and expandable, the user needs in-depth knowledge of data modeling.

Intuitive tools, automation solutions that require little or no code, and automatically customizable user interfaces should not obscure the fact that you are working with a complex technical platform that is likely to play a key role in the enterprise IT environment. For this reason, I believe that any development and adaptation of data structures and logic should strictly follow the rules of good software engineering. Starting with consistent names and descriptions, the creation and regular execution of automated tests also for changes implemented with “No-Code” or “Low-Code” techniques and the application of the SOLID principles - to name just a few key points.

Updated: