Building flows: go down or go across?

Let’s say you design a subflow that attempts to find a contact. After several attempts, if a contact isn’t found, it creates one.

Each attempt tries to find a matching contact using different criterias. For example, find by

  1. Email address
  2. First and last name
  3. Last name and postal code/zip code
  4. Last name and birthdate

If attempt 1 doesn’t return any results, you move to attempt 2.… Read the rest

Does Salesforce perform a noop?

Here’s a question for you: When you update a field to its current value, what happens?

For example, let’s say you have a contact with a phone number of “123 456 7890”. Then you execute a flow that updates the phone number to “123 456 7890”.… Read the rest

Updating and deleting multiple records in a flow

Thanks again to everyone who responded to yesterday’s email about updating a record collection.

The most popular solution to test for > 0 records is to simply use a decision element with {Get_Contacts} Is Empty. This is simple and clean, and I’ll adopt this approach going forward.… Read the rest

How do you verify whether a record exists?

This email is more of a question than a comment. So I’m looking forward to your thoughts.

In flows, it’s common to verify whether a record exists before performing an action. For example, let’s say you need to update a contact if it exists, or create it if it doesn’t.… Read the rest

The somewhat useful “Update Existing Records” feature

In Salesforce flows, there’s a relatively new feature called “Update Existing Records”.

It’s only available in Create elements, and it allows you to update existing records instead of creating new ones. This effectively turns the create command into an upsert command.… Read the rest

You (probably) should learn how to program

I must admit, I’m using AI more and more these days. It helps me in numerous ways, but the majority of the time, it’s with development.

Gemini Pro is pretty good with apex coding. With a few prompts, it can create or edit code fairly easily and accurately.… Read the rest

An easier way to build Salesforce packages

When building a Salesforce package, there are two ways to create and maintain them: 1GP and 2GP.

1GP uses a development org as the source of truth. Most consultants are very familiar with this way of working. You typically start in a DEV sandbox for development, then migrate changes to a UAT sandbox for testing, and finally to production.… Read the rest

Where is Salesforce headed?

During my two week hiatus from these emails, I stopped talking and listened more.

One recurring theme in particular caught my attention: Salesforce is not the company it once was.

This theme presented itself in multiple ways:

  • People leaving the Salesforce ecosystem and moving to another career
  • Throngs of junior consultants who are out of work
  • Comments about how Salesforce is pushing Agentforce down our throats when most organizations are not even close to being ready to adopt it
  • With all the recent layoffs, the feeling of the “ohana” slowly dying

As I’ve said several times, our careers are based on a single platform.… Read the rest

Breaking up long logic

When designing long flows or apex, it may make sense to break things up.

One approach is to keep things modular. But then the question becomes, where to break up the logic?

Let’s say when A happens, do B, C, and D.… Read the rest

Using AI for first drafts

While AI may not be a full replacement of a good developer, it can still help in some instances.

Using the prompt, “Write a Salesforce LWC that allows users to edit a field”, Gemini Pro actually built a working lightning web component (LWC).… Read the rest

Using AI as an apex developer

You may not have known this, but in a previous life, I was a software developer.

It’s been years since I’ve developed, so I’m not an expert in apex. There are far too many awesome developers out there, and I lean on them for help.… Read the rest

What is data skew and how do you avoid it?

In Salesforce, building a future-looking data model is important. You generally want to anticipate issues before they occur.

One consideration that is overlooked is when a parent record has too many child records. Or when one user owns too many of the same records.… Read the rest

One-to-many relationships vs many-to-many relationships

Both Lookup fields and Master-Detail fields create a one-to-many relationship. This means the parent object can have multiple children. However a child cannot have multiple parents.

To allow the parent to have multiple children and the children to have multiple parents, a many-to-many relationship is needed.… Read the rest

Lookup fields vs Master-Details fields

When associating objects with each other, there are two main choices: Lookup fields vs Master-Details fields.

Here are some considerations for these two:

Master-Detail fields
These fields create a strong connection between two objects. The field is created on the “detail” object, and points to the “master” object.… Read the rest

Considerations when creating custom fields

One of the services I provide is technical debt assessment. I cannot tell you how many times I’ve been called in to help a client who is frustrated with their Salesforce implementation. I cannot tell you because the number is too damn high.… Read the rest

What to display on the home page

So you’ve rightly decided to have the home page as the 1st tab in your app. But what should be displayed on this page?

The out-of-the-box home page isn’t sexy at all. It’s a bunch of random widgets that are not usually related to your client’s needs.… Read the rest

Who’s on first? Deciding tab order

When preparing to create a new app in Salesforce, the first step is to determine your audience. Each app should have a specific audience in mind.

For small orgs, one or two apps may be sufficient. But for larger ones, you’ll probably want several.… Read the rest

Should you create a tab for a custom object?

Let’s cut to the chase. Just because you can create a tab for every custom object you create, doesn’t mean you should.

The question then becomes, when should you and when shouldn’t you? Here are some questions to help you answer that question.… Read the rest

Autonumber naming convention

Let’s say you’ve decided to create a custom object and use an autonumber as the data type for the record name. The next decisions are, what should be the naming convention for the record name and display format.

Record Name
The most commonly used record names have either “Name” or “Number” (or “#”) in it.… Read the rest

Custom object record name

When creating a custom object, you have two choices for the Record Name: text and autonumber. What principles can you use to determine which one is best?

Consider the following:

1. Uniqueness
If you want the field to be unique, use an autonumber, since uniqueness cannot be enforced with text.… Read the rest

Data modelling – standard vs custom

When creating your data model, there are several principles that can be used. One of them is the KISS method: Keep it Super Simple (which is a better alternative than Keep it Simple, Stupid).

Here are some considerations when applying this principle:

Standard Objects
When the functionality you’re trying to build fits about 80% of the existing data model and built-in functionality.… Read the rest

Montreal Dreamin 2025 Summary

Today is day 1 of Montreal Dreamin. Overall, this year’s event was much better organized than last year. The organizers learned what works and what doesn’t, and then made the necessary changes.

As a speaker, I was able to share how Salesforce freelancers can escape the limits of hourly billing and unlock their full value.… Read the rest

Another category of documentation

When discussing the recent documentation emails with a colleague today, he mentioned Confluence.

This was a great callout, since when you hear the words “design document”, you usually think about MS Word or Google Docs.

Now, both these solutions work well, as long as they are stored in the cloud.… Read the rest

The best way to write documentation

A reader responded to yesterday’s email about which way to write documentation is the best, or at least which is my preferred way.

The short answer is, whichever way people will actually adopt.

You can write the best documentation on the planet, but if no one updates it after you leave, it’s effectively useless.… Read the rest

Ways to write documentation

There are only a handful of popular ways to document Salesforce. Here are three for your consideration.

1. Design document
Your team usually needs precise instructions on how to configure the platform. A design document, usually written in Google Docs or MS Word, is a common way to communicate these instructions.… Read the rest

Sending mass emails from Salesforce

Client’s typically don’t use Salesforce to send mass emails. There are lots of good options for mass emailers out there, ones with significantly more features than what Salesforce offers.

However, there are legitimate use cases to just use Salesforce. Two of those are cost and technical simplicity.… Read the rest

Examples of helpful helptext

A number of readers commented after yesterday’s email about guidelines for helptext. They felt the only thing missing were some examples.

Not wanting to disappoint, here are a few.

Acknowledgement Date
Original: Date of acknowledgement
Better: Date the donation was acknowledged.… Read the rest

Actually helpful helptext

When creating fields, it’s best practice to always add a description. Sometimes it’s also a good idea to add helptext. The question becomes, when should you add helptext and what should you write?

To start, here are some samples of what not to write.… Read the rest