Naming Convention Flows

Salesforce has two options for object records: they can either have a text Name field or be auto-numbered.

• Accounts, of course, have an Account Name field.

• Contacts, technically, only actually require LastName, which is obviously text.

• Opportunities are named.

• Payments (an NPSP object) are auto-numbered.

Auto-numbering is nice because nobody has to think about it, but it’s kinda’ impersonal. Text fields, however, can be the Wild Wild West.

If you’ve spent any time in Salesforce, I bet you’ve already encountered this with Opportunities. Some organizations train people to stick to a standard, but more often than not even adherence to a policy is spotty. You can end up with an opportunities list that is just impossible to sort through, whether it’s opps that all have extremely similar names

or each has a very specific name that somebody painstakingly typed in,

whether or not it gives all the information you might want at a glance.

(And these were examples from Opportunities, which already lend themselves to some structure around naming!)

We Need Naming Conventions

Sometimes we need records where the name tells us something but where it would be annoying to make your users type it in. We need naming conventions.

For example, I have clients creating records of students applying to colleges. Wouldn’t it be great to be able to glance at a list view and know most of the important information about that record? Something like:

Harry Potter - Wizarding U - SY24 - Waitlist

Hermione Granger - Wizarding U - SY24 - Accepted

It would be bad enough trying to get users to type all of that. They would never be consistent with school names or school years. And they would definitely not keep the stage up to date!

But thanks to Flow, it’s also not very hard to do it for them.

Build a Naming Convention Flow

These are some of the easiest flows you’ll ever build. Take the example of the college application tracker: You can actually just have one step:

This is a Before Save flow (the setting in Flow Builder is “Fast Field Updates”), which means it runs before the record is even saved to the database and it runs very fast.

In this case all you have to do is assign a new value to the Name field of the record. It’s going to overwrite whatever value was there with the most up-to-date information.

This kind of naming convention is really easy and helpful for all sorts of objects. I use it regularly for applications, report cards, test scores, financial aid awards, and the like.

If you want to impose a naming convention for opportunities, you might want to build in more logic, perhaps distinguishing between naming for individual gifts, corporate gifts, recurring donations, etc. That takes a slightly more involved flow, but there’s really nothing too complex here. It’s just a handful of decisions to decide the type of gift and then use the right naming based on that.

So we’re done! Build a quick flow that updates the name–probably in a before save context–activate and move on.

One Small Gotcha - The New Button

I do have one pet peeve related to this: The Name field is still going to be required when you click New. 🤦

A really conscientious user (my favorite kind!) is going to see the required New College App field and type out something that matches what they’ve seen in other records of this kind. And they’re going to hate that they have to type so much. A not-conscientious user, of course, is just going to put the name of the school, or the student, or the year, but definitely not all three.

You can teach people they can just put anything in the field and it will be overwritten, but that offends my sensibilities on more than one level. (Not how it works in other places. Not a good habit to get people into. Unnecessary extra typing...)

And you can’t even give any sort of on-screen hint about this. (You can't put help text on a Name field. Probably nobody would read it if you did.)

So you have a few choices here, none of which make me happy.

1. Training - Just tell people that for the object in question the name field is going to be overwritten and they should put any character in that field and move on.

   1. I don’t love this option because it relies on them knowing to ignore the field in this case but you probably don’t want that kind of behavior in other places…

   2. You can make things slightly better by setting the record Name to be “_object name_ (filled by flow)” or the like. But then "(filled by flow") is also going to show up in the headers of your reports and list views, which I kinda' hate.

2. A Quick Action - It’s very easy to make an object-specific Quick Action and then remove the standard New button on related lists.

   1. The benefit of an action is that you get a custom mini Page Layout for the action and you can remove the name field from that layout (which you can’t do from a regular page layout that would be used for the New button.

   2. You can also remove other fields that are perhaps not relevant at the moment of first record creation and can prefill fields to save your users time.

   3. My disappointment with this approach is that you can’t actually have this new action override the New button in related lists. This new action will show up at the top of the page on the parent object, next to the Edit button and the like. You have to remove/hide the New button on the related list. I think it’s confusing for users that some related lists have New right in context on the list and for others you have to look elsewhere on the page. Is this a huge deal? No. Is it poor user experience and user interface design, yes!

   4. And by the way: Your Quick Action will be used when creating a record from the related record’s page. But not if you click New on a List View…

3. A Screen Flow - If you want to get really fancy you could make a screen flow for creation of new records.

   1. Like with a custom Action, you don’t have to ask users for the Name in your screen flow. It’s then possible to create a new list button and reference the flow’s API name as a URL. (/flow/FlowAPIName?InputVar1={!Mergefield1}&InputVar2={!Mergefield2}etc…)

   2. Then you can use that list button to override the New button both in list views and related lists.

   3. By default a screen flow isn’t going to redirect to the created record. (There are ways to fix this using UnofficialSF components, but still…)

   4. The screen flow is going to look different than other New button behavior.

   5. And the screen flow is also going to run more slowly.

   6. Let's also not forget that building a screen flow takes more than a little work, even for a simple one, and leaves you with yet one more custom thing to maintain.

In real life I’ve usually gone with option #2, but sometimes just lived with #1.

Option #3 just feels bad all around.