Thing I Learned: Flow Entry Formulas

So here's one I learned the hard way: Until a few releases ago if a field was used in a flow entry formula it would not register with the Where is this used? button. And you wouldn't be prevented from deleting that field either.

If you have flow entry conditions, built one field at a time in the builder, that would register show in Where is this used? as well as prevent deletion. But put the same conditions, with the same fields, into a formula and there are no guardrails. Yikes!

So...first the good news: Salesforce has fixed this. I don't know exactly in which API version the fix rolled out, but flows on the last few releases do not suffer from this problem. (As of writing we are on API version 63, with 64 rolling out very soon.) The issue, in fact, should not occur for flows that use a version somewhere in the high-high 50s or early 60s.

But just because your org has been updated to Spring '25, that doesn't mean that your flows have. If you start building a new flow, it will be on the latest API version by default. But your old flows do not get updated. Even if you save them as a new version, unless you take intentional action to update their API version, flows stay on their original version. So you could have flows in your org that will suffer from this bug.

How I Really Learned This

Funny story.

I had actually seen a thread in Salesforce MVP Slack several weeks ago that mentioned this issue. At the time, I remember thinking, "That's potentially bad." But one of the flow Product Managers replied that the issue had been fixed a few API releases ago. With that in mind, I filed it under "interesting" and moved on with my day.

Then more recently I wanted to do some cleanup in one of my client orgs that's been around for a while and has, for the whole time I've worked with them, had a bunch of fields with names like zStart Date Report and zDep - OAG Client Status or other artifacts left over from their initial implementation and migration from a prior system. I confirmed a whole bunch of fields were not on any page layouts and had never been used and then I started deleting them. In the course of that work, I noticed that there were two fields on Case whose purpose was clearly duplicative: Admin Touch and Tickle Record.

If you're not familiar, these names may make you chuckle. But I knew immediately that these were fields meant for a single purpose: An admin could update that field, which would count as an edit on the record, thus kicking off any record-triggered flows. I like to keep a field around on most objects to use for this purpose. In fact, "Tickle Record" is often a name I would use for such a field. Indeed, that field was built by me (and properly documented exactly for that purpose).

Admin Touch was also properly documented, it had just been created before I came along. Clearly I hadn't noticed it before I made my field. But now we had both in the org and needed only one, at most. Since I was already on a field deletion kick, now was the time to clean this up. I decided I would keep the one I'd built—it was an arbitrary decision.

So I deleted Admin Touch with nary a second thought. I had checked Where is this used? and it wasn't on any page layouts, nor in any reports, nor anywhere else. And the deletion went through without any hesitation.

Then a few hours later I get an email from the organization's sysadmin forwarding an email she'd gotten from another user, who was getting this error:

Honestly, it took me longer to read the error message than to realize what had gone wrong. I immediately remembered the Slack thread. And it had only been a few hours since I'd deleted the Admin Touch field.

It was easy to undelete Admin Touch to stop the error from happening right away. (I had to undelete it and then remove "_del" from the API name of the restored field, of course!) Then I went into the flow that was mentioned and saw that, indeed, Admin Touch is mentioned in an entry formula, not in conditions.

And when I checked the flow's Properties, it turns out to be on API 57.

(So we know the problem was fixed somewhere after API 57...)

By the way: While grabbing screenshots for this article from a sandbox, I confirmed that while the flow is on 57, Where is this used? for Admin Touch does not show the flow. But if I save a new version of the flow at 63, it shows. Empirical proof for the win!

(I suppose that if I cared enough I could save the flow at 58, check Where is this used?, then try again at 59, etc... until I found the point where the bug was fixed. But I'm sorry readers, I'm not quite that dilligent!)

The Takeaway: You Need to Update Your Flow API Versions

I leave you with some homework: update your flows to newer API versions.

Here are the steps:

1. Working in a sandbox, of course, open the flow.

2. Select Save As New Version.

3. Click Show Advanced.

   

   
   

4. Scroll down to API Version for Running the Flow.

5. Select the latest version. (If you're working in a Preview sandbox you won't be able to deploy because it will be one version ahead of production. So know your versions and consider whether you have to save one version lower.)

6. Save.

7. Activate

8. Test.

9. Deploy to production.

10. Repeat for every other flow that's on an older API version.

This is probably basically busywork, of course, and I'm sorry about that. But I don't really think there's much risk in just saving as a new version, updating the API, and activating. You ought do to this in a sandbox and test the flow at the new API version before you deploy. But we both know the realities of life.

Your org's metadata governance and testing requirements might be more stringent, of course, so perhaps this will be a bit of a hassle.

But at least I've told you why it would be worth the effort!

Full Disclosure: I haven't done this for most of my clients yet. But I intend to...eventually...