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

Implementation considerations – part 2 of 2

Continuing yesterday’s email about keeping the client in mind during implementation…

4. Consistency
There are multiple ways of building something with consistency.
– If you’re taking over an existing platform, use the client’s existing approach. My philosophy is, if you’ve built it wrong, it’s better to be consistently wrong (with some caveats).… Read the rest

Implementation considerations – part 1 of 2

When you’re implementing a project or feature for a client, there are some important considerations.

Here are a few to keep in mind.

1. Ease of understanding
As a consultant, you spend countless hours looking at Salesforce. You understand how it works, how to find things, and what to do when things go wrong.… Read the rest

Who are you implementing for?

This is a quick reminder that when you’re implementing Salesforce, you’re not actually implementing it for yourself.

At some point in time, your client will inherit what you’ve and your team have built.

This raises the question, will your client understand how to maintain what you’ve built?… Read the rest

Data-driven architecture for the win

I recently obtained my first American nonprofit client for my tax receipting application. Very exciting, as all my previous clients were Canadian.

The app allows you to create multiple receipt templates and you can use automation to assign a template to a specific opportunity.… Read the rest

Popular debugging tools

As a Salesforce consultant, you’re probably quite comfortable with debugging flows. The Debug button is highly visible, and it’s easy to follow the flow’s path and see variable values.

Of course, there are several other ways to debug functionality. Here are three for your consideration.… Read the rest

Creating modular business logic

When building automation, whether that’s flows or apex, you’ll eventually find yourself building business logic.

Business logic is basically a module that performs a certain function in response to a business need. For example, a screen flow that creates contacts may want to first verify whether an existing matching contact exists before creating a new one.… Read the rest

Finding an object’s prefix

One of the many things I love about this email list is sharing my knowledge with you. But it’s not always a one-way street. Some days I learn from you.

In regards to yesterday’s email, a long-time reader mentioned there’s a more abstract way of knowing an object’s prefix.… Read the rest

One flow for multiple objects

It’s very common to write one flow for one specific object. This applies whether it’s a screen flow or an autolaunched flow (This obviously doesn’t apply for record-triggered flows).

For either scenario, you typically pass at least one input text variable (e.g.… Read the rest