A Force to Reckon With

… but you’re sure not going to give them the “Edit Read Only Fields” permission?  Here’s how I used Actions to make this happen.

Let’s say in Salesforce you’ve built an object where the record is completed (people have to have access to the fields to edit) but once it goes through an approval process or a final save of some sort, the desire is for no one to be able to easily edit the fields. And by the way, you’re doing all of this declaratively- no code or visualforce here!

You would create the object and basically have 2 record types – one where all the appropriate fields can be edited, the other you’ve locked down at the page layout level everything to be Read Only (so users don’t even get the impression they could make a change). Also add a validation rule that you can’t make a change to the record if it is a read only record type. So when it’s “done”, it switches record type to Read Only layout and Bob’s your uncle. I’ve referred to this as “locking” the record.

Until someone comes along and says “Well, that’s awesome, love what you did there, but Sally in Accounting, Tom in Marketing, and our CEO all want to be able to make edits AFTER it is “done” and “locked””. Uh oh. 3 (at this time) users with nothing in common- not the same profile or role… how are we to give them access so they can edit this read only record type (locked record)?

There are a lot of complicated ways to go about it- and depending on your situation you may decide another way would be best for your org. I came up with a couple of different avenues including some that used process builder but nothing that I really loved.

Then something popped in my head– Action buttons. One of the features of Action buttons is the ability to update a record. See where we’re going? I created an Action button for each of my “locked” record types and added it to the page layout. The action button layout gives me the ability to limit what fields can be edited once the record type is “locked” – if I don’t want them to be able to change it, I leave it off this layout. In my situation because different fields appeared on the different layouts, I have an action button on the object for each of the locked record types to reflect appropriately what can be modified on each. Future changes are easily managed, just remove or add to the layout as desired.

How you determine who can utilize the action button? I created a simple checkbox on the User record – “Can Edit Locked *object* records”. I added an exception to the validation rule written earlier for $users with the permission and done.

So that is how you can get edit access to a user for a read only field on a page layout without giving them access to the permission “Edit Read Only Fields”.

My special snowflakes who has this permission can now go into the locked record and make modifications as necessary without having to change record types or add additional page layouts or use any code.

Any questions? Thoughts? Concerns? Please share in the comments- always looking for feedback!

PS- If you use this, put the action at the end of your regular actions.  Lead off with something else like Post or you’ll be greeted by the action button layout when you access the page.  Other users without the permission on their user profile can still see and click on the action button, but will get a validation error when they go to save it.  Out of sight, out of mind works well here and you’ve got the rules to back up if someone gets click-happy.  Consider using field history to track changes as well depending on the situation.