More Required Spots
Last post I wrote about the various ways you can require a field. I want to shout out my readers because y'all are a smart bunch! I got several comments about places I'd forgotten, so I figured I needed to do a follow-up post to bring things all into the same place.
1.1. Also on the Page: Dynamic Forms
In the last post I started with requiring fields on the page layout editor. In my mind, I think, this was supposed to encompass any time you are building a "page" or "form" within Salesforce. The places where you can click the Require box. But I think that the way I wrote it implied that I was only talking about the Classic page layout editor. So my first shout-out is to Stacy Irwin for calling attention to making fields required on a Dynamic Form.
As Stacy notes, "Data imports and the classic interface won't enforce it." Think about that for a moment. Data imports not enforcing I had mentioned. But if you have any potential use case where someone could switch to Classic, then your requirement on a Dynamic Form will not apply, only the state of that field on the page layout editor. If you've heard me talk about Dynamic Forms before—it's an aside moment in many of my presentations—you might also realize that field editability and/or requiredness on list views is also controlled by the page layout editor. That may change someday, but for now, you have to keep the page layout in mind in addition to the Lightning record page for exactly this reason.
1.2. Not A Page But Still A "Page": Screen Flows
Heath Parks was actually first to call out one of my omissions when he commented on my LinkedIn post to mention requiring fields in screen flows. A great point! Of course we sometimes require fields in screen flows. And it's worth calling attention to the idea that you might require different fields in the screen flow than you might on the page layout.
But Heath's larger point was that you can use screen flows to require different fields at different times than you might in the general user interface. He said, "I have found this useful in cases where you now have guided screen flow to do an Intake and now some fields that were optional on an object are now required, so this way all new records get the required information and any legacy records we can still edit, etc as needed." In oter words, a screen flow is replacing the New button, so any time a user is creating a new record they're going to fill out the important fields. But the Edit button on existing records does not force users to fill in details they might not have if they're making a small edit to an old record.
Keep Your Data Clean
Lastly I'm going to reiterate something that I wrote last time in a parenthetical and now I think I should have highlighted more: Just because you require a field, that does not ensure clean data! Users are sneaky. They'll just fill in garbage values to get past a required field if they have to. This is particularly easy with text fields where they can just mash the keyboard. But they'll do it for numbers, emails, dates, or even picklists. I don't think there is any technical fix for this. The solution is social and has two main components:
Take your users' feedback and build it into the system. Maybe a field doesn't need to be required at all. Or maybe it should only be required at a particular stage. Users are the ones that understand this, often better than admins.
Teach users the value of clean data. Help them understand the reports and management functions that these required fields are driving.
My gratitude to all of you that read this blog carefully enough to spot my omissions and generously enough to point them out to me. Plus extra thanks that you all do it in positive ways!
