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

F*ck cancer

It’s very rare that I don’t discuss Salesforce in these emails. After all, that was my promise to you and the reason you signed up for these emails.

However, tomorrow is a very personal day for me. I will be participating in the Relay for Life.… 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

Exposing your weakness

I must admit, I’m good at many things. However there are a few things I’m not so good at. And that list feels like it’s getting longer each year.

Recently, I noticed that I don’t like writing long documents about the project’s implementation plan.… Read the rest

The elephant in the room

People often ask me what’s the biggest concern I have when implementing Salesforce. Which technical issue or process keeps me up at night?

The answer is neither. It’s change management.

Technical details usually get flushed out and the results are often good enough.… 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

Looking for a business development rep

As you may know, I’ve been working on Dryad Receipting for Salesforce for a couple of years now. The app saves nonprofits time and reduces stress when generating tax receipts for their donors.

When it first launched, the focus was on the Canadian nonprofit market.… Read the rest

How to say you’re open for work

As a followup from yesterday, here’s how I would have written this post.


Availability opening for Salesforce projects in manufacturing

Hi, LinkedIn network — My principal mandate is coming to an end soon. So I’ll be available for new opportunities starting May 15th, 2025.… Read the rest

How NOT to say you’re open for work

Talking about specialization or lack thereof, here’s a real world use case about how NOT to advertise you’re available for work.

Below is a post from LinkedIn that appeared in my feed today. I removed the person’s name to keep them anonymous.… Read the rest

How to convey knowledge without certifications

Given how Salesforce certifications have lost most of their value, another question logically follows. How do you convey knowledge without them?

Here are three steps to get you going.

1. Specialize
If you’re a generalist, it’s difficult to distinguish yourself from your competition.… Read the rest

Should you let your certifications expire?

There’s a lot of recent chatter on social media about Salesforce certifications. Some consultants are asking whether certs still have any value or not.

Back in the day, certs were a great way to distinguish yourself from competition. And partners shared the total number of certs from their employees as a vanity metric.… Read the rest

Montreal Dreamin 2025 announcement

It is with great pleasure to announce that I’ll be attending Montréal Dreamin’ this year.

The event takes place on June 5 and 6, 2025 at the Double Tree Hilton. Once again, I’ll be a speaker and a sponsor.

The speech is the same one I did at True North Dreamin (TND), called “Free yourself from hourly billing and unlock your full value”.… Read the rest

Making yourself available 24/7

Another key point with an advisory retainer is making yourself available 24 hours a day, 7 days a week.

To be clear, “being available” doesn’t mean “being responsive”. It simply means the client can contact you anytime. You can make a best effort to respond ASAP, and even answer after 5pm.… Read the rest

What a quote for an advisory retainer look like

Regarding advisory retainers, here is the exact template I use for quotes.

Feel free to copy+paste and adjust as needed.


This is an advisory role, assisting with strategy and best practices without hands-on involvement. I will meet regularly with the team to review progress, answer any questions, and generally advise the team as needed.… Read the rest