Photo by Samuel Sianipar on Unsplash


Integrations happen more often than not, and reasons range from choosing the best system that fits the purpose, company growth or simply because you have a legacy system to take care of.

Initial Assessment

I usually start by understanding what data is missing and what reasons make us believe that we need such data.

This helps me to understand the criticality of this data, and many times to re-think if we need that data as part of MVP (Minimum Viable Product) for the next iteration.

Then if the data remains important, I start to think about:

  • Volumes
  • When Data is Needed?
  • Tools…

Seven years ago, I transitioned from being a C# enterprise developer to a Salesforce developer.

Let me start by saying that I had a good career as a C# developer — working at a large organization and developing some interesting solutions. However, it got to the stage where I felt that the technology being used was limiting the impact I could make. One day, a manager contacted me and asked if I would like to move to a different development stack, to further progress my career.

I jumped at the opportunity, and over the next few years, I implemented different…

Data structure vs Objects

Reading through the Clean Code book, I stumbled upon a very strong and deep piece of advice:

Mature programmers know that the idea that everything is an object is a myth. Sometimes you really do want simple data structures with procedures operating on them.

Batman (Clean code) slapping Robbin (purist OO developer): everything is an object. That is a myth!
Chapter 6: Objects and Data Structures, that is nearly a slap on the face of purist Object-Oriented developers.

However right before that, Uncle Bob explains why procedural and object-oriented code are completely opposite approaches:

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

The complement is also…

Photo by Kevin Ku on Unsplash

First impressions

I have to say that I enjoy Continuous Integrations: the process gives me feedback if the work I'm performing works with the work that others are performing.

When GitHub launched the Beta for GitHub Actions, I got excited. Mainly because it has an option that doesn’t require me to maintain build machines.

GitHub Actions

They are currently on v2 that uses YAML to define the jobs.

The Github-hosted environments available currently are Windows, Linux, and macOS. Pretty handy if you are building multi-platform apps. GitHub also plans to allow customers to self-host agents.

For public repositories, it is free of charge, which…

Or how to handle synchronous calls with slow backends

Photo by Pascal van de Vendel on Unsplash

I spent a long time of my experience Salesforce creating integrations with other systems: from Mainframes to microservices.

One of the main painful problems with synchronous integration in Salesforce is the timing constraint — especially because Salesforce imposes, with governor limits (10 callouts taking more than 5 seconds per instance) — and as I said, I worked with plenty of integrations serving different needs for different departments (Sales, Support, Channels, so on so forth). That meant that across any of those departments, we should avoid having integrations taking more than 5…

Callable Interface

Photo by La-Rel Easter on Unsplash

For many implementations that I worked so far, they tend to become a “Big Ball of Mud” — of course, this is not exclusive to the Salesforce ecosystem, but some challenges are specific. Currently, I work in a product company that is a Salesforce ISV (Independent Software Vendor that ships software using the Salesforce platform).

Then talking to some colleagues and other fellow software engineers I started to dive deeper into this subject to evaluate: why we get into such trouble? Is this truly a problem? What are the alternatives?


Because the implementations usually start small and simple, but eventually…

Photo by AbsolutVision on Unsplash

Just a quick note to talk about a pattern to lazy load constants (similar to an old question in Stackoverflow).


Sometimes you have a class full of constants and some of those are resource intensive (CPU or memory).


Lazy load those constants:

public static final Map<String, String> ISO_TO_SYMBOL {
get {
if (ISO_TO_SYMBOL == null) {
ISO_TO_SYMBOL = new Map<String, String>{
'USD' => '$',
'CAD' => '$',
'EUR' => '€',
'GBP' => '£',
'JPY' => '¥',
'KRW' => '₩',
'CNY' => '元'


  1. Assure the static instance is never changed: constant.
  2. Load the map only if requested: lazy load.


  1. More convoluted code.


Is this a supported pattern or just a corner case? Asking because have not found an example online.

Jenkins + Salesforce DX = ❤

If you use Jenkins as a CI tool and want to streamline the process to build and test the Salesforce DX project, this library is for you.


Salesforce did their job and provided a helpful walkthrough including a sample Jenkinsfile, but in my experience, that was not enough.

I realised this was not enough while assisting on migrating projects for customisation and managed packages at the company I work for — ClaimVantage — and we felt that we should address the following:

  1. Avoid duplication (we started with 76 lines but quickly jumped to 171 lines and mostly was performing the…

Jeferson Spencer Chaves

I’m a Software Engineer working with Salesforce Lightning Platform @ClaimVantage.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store