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:
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
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.
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:
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:
- Create a child object
- Use a Quick Action to create a child object record from the Public Read Only record
- Use Process Builder on Create of the child object, to kick off an update to the Public Read Only record
- Cross my fingers and click go
Pretty basic, just two custom fields –> one to link to the parent record, and the other to mirror my date field from the parent
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.
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”
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
- A child record has been created
- The date on the parent has been changed
- 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.