Changing the way Salesforce Admins and Developers think about client solutions.

Hacking Salesforce Record Access – Editing a Read-Only Record

Access Granted

It’s been a little while since I posted but this solution got me back into the swing of things.  There was a question on Answers, not unlike others that have come before it, about how to open up one field for edit by non-owners in a public read-only environment.  Not a different profile, not custom pages, just one field that non-owners can edit on each other’s records.

This is one of those things that comes up now and again, and the answer is always that it isn’t really the way Salesforce is built.  The difference this time is that it bothered me enough to come up with something.  I decided to roll up my sleeves, break out my “try crazy stuff” developer edition, and see where I could take things.

Once it’s done, the solution is remarkably simple.  So here it is:

Use Case

I have an object aptly named “Public Read Only” with a Date field that I want everyone to be able to edit.  The problem is that the security on this object is Public Read Only

Public Sharing

Quick definition of Public Read only from Salesforce themselves

All users can view and report on records but not edit them. Only the owner, and users above that role in the hierarchy, can edit those records.

For example, Sara is the owner of ABC Corp. Sara is also in the role Western Sales, reporting to Carol, who is in the role of VP of Western Region Sales. Sara and Carol have full read/write access to ABC Corp. Tom (another Western Sales Rep) can also view and report on ABC Corp, but cannot edit it.

Which means that only a System Administrator or someone above the owner in the hierarchy is allowed to edit this record.  But I want to allow anyone to edit the date.

People have done this in different ways before

  • Opening up access and then locking it down with validation rules
    • I’ll spare you the details
  • Different profiles and field level security
    • Doesn’t help if they are the same profile
  • Fancy code
    • Hassle to maintain

But I wanted to do it in a more declarative way.  First I wanted to verify that my object is set up properly and that the security is working as expected.

Test Case

I confirmed behaviour quickly by creating a standard user profile and assigning it to a random person below me in the hierarchy.  So they have no rights to edit my records for this object.  If they try to hit the Edit button, they get this error as expected:


To make sure Salesforce hadn’t changed the rules on my, I also tried creating a Update Quick Action to test that out:

Update Action

When the standard user tried to use the Update action, this is what they see, which would also be expected:



What I need to do is find a way to force an update on this record in what is called System Mode, meaning outside of logged in user restrictions.  I’ve actually got Rakesh Gupta to (once again) thank for this because it was his site where I first remembered seeing that Process Builder runs in System Mode and not User Mode.  Taken straight from his article

  • System mode :- In which the object and field-level permissions of the current user are ignored.
  • User mode :- In which the permissions, field-level security, and sharing rules of the current user are enforced.

So now I know that I can use Process Builder, what I still need is a way to kick it off.

What I came up with was to use Quick Actions.  I’m a huge fan boy of Quick Actions and think that everyone should spend more time learning what they can do.  Not now necessarily, I’m still going here, but as soon as you are done reading this, it’s Trailhead time for

and really spend a lot of time thinking what you can do with them.  This use case is slightly different, but I would never have gotten here without trying to constantly push myself for new ways to use them.

What I came up with is:

  1. Create a child object
  2. Use a Quick Action to create a child object record from the Public Read Only record
  3. Use Process Builder on Create of the child object, to kick off an update to the Public Read Only record
  4. Cross my fingers and click go

Child Object:

Pretty basic, just two custom fields –> one to link to the parent record, and the other to mirror my date field from the parent

Child Fields

Now on my Public Read Only record I would have a related list.  In real life I would never show the list, but this is a good way to test


Next up I need a Quick Action on that page to create a child record.  It looks like this:


and on the parent record would look like this:


So now I can create child records from the parent object and since this object is unrelated, anybody can use it.

Process Builder

Next up I need a process to take whatever date a person creates in that child record, and push it back up to the parent.  Here are the three steps in my process.  I won’t go into detail on Process Builder itself, there is a ton of resources out there for learning the basics




That’s all I need my process to be, pretty basic.

Don’t forget to Activate it.


Log in as a standard user, in this case my brother, and find “My Record” Tom1

Then open the Chatter Feed and click on the Action to create a child record, and pick a different date


After clicking Create, refresh the page since this will not happen automatically.  Now you’ll notice that

  1. A child record has been created
  2. The date on the parent has been changed
  3. The record is showing the non-owner as the person who last modified it
    • Which wouldn’t otherwise be possible because this is a Public Read Only environment.  So we have hacked the Organization Wide Default sharing setting for this record



There you have it, with Quick Actions and Process Builder you now have a way for non-owners to update one or more fields on records that they do not own, even in a Public Read Only sharing environment.

What to get really fancy?  Layer on a delete of the child record into your Process so that it’s like it never even existed.  I covered that here so I won’t go over it again in this article.

I’d also like to gives thanks to Rakesh for doing a sanity check for me on this one.  If you haven’t used his site yet I really recommend it.

Share Button


  1. Great writeup, thanks for sharing Geoffrey!

  2. Sandeep Kumar Gaddam

    February 19, 2016 at 9:56 pm

    I read the complete post and amazing its simple but also need a smart brain like yours to this about.

    There was a question recently a day ago about System Mode which i got to answer


    and today i was explaining to my office colleagues about how this field is different from lastmodified field and how this field can be use in process builder.

    and today i read your post and felt happy.


  3. Process Builder holds so much potential. Very creative. Keep the ideas coming Geoff!

  4. Thanks, Geoff!

    When I created the M/D field on the Child Object, Salesforce’s default sharing setting was: “Read/Write: Allows Users with at least Read/Write access to the Master record to create, edit, or delete related Detail records”.

    I needed to switch this to “Read Only: Allows Users with at least Read access to the Master record to create, edit, or delete related Detail records” in order for a User to create Child records.

    Worked like a charm. Thanks, man.

    • geoffreyflynn

      February 2, 2016 at 3:26 pm

      Thanks for the feedback Brooks! I did it with a Lookup relationship so that I didn’t have to worry about that scenario. Good catch

      • Not sure why I naturally assumed a Master-Detail relationship was needed. You’re right, Lookup would work just fine. Thanks, Geoff!

        Best, Brooks

  5. Thanks @Geoffrey for this awesome tips. Yes, process builder is awesome to use for this type use scenario and with more complex business scenarios. And I am also a big fan of Quick Actions. They are rock in lightning especially 🙂

Leave a Reply

Your email address will not be published.


twenty − 11 =

© 2018 ExploitedDevOrgs

Theme by Anders NorenUp ↑