I have Account Object With Public Read/Write Sharing setting. There is one Profile(P1)with Read Access for Account Object.

When I create a record, the User of Profile P1 cannot Edit the record, even the Sharing is Public read/write.

Why is this happening?

  • 2
    You need to enable Edit on Account for that profile P1 for him to edit an Account. Sharing settings ensures which records can be seen by which user not what a user can perform on that Object. Mar 31, 2017 at 11:05
  • but the Sharing setting is Saying Public Read/write ,Means The record can be seen as well as Edit,then why its not editable .
    – dem
    Mar 31, 2017 at 11:08
  • 1
    By public read/write it mean any one can access any record of that object provided they have the required level of access to that Object (CRED). i.e. in you case anyone can edit any Account record if he has write access for Account in his profile or by permission set. Mar 31, 2017 at 11:12

3 Answers 3


Although you have setup your sharing rule with Read/Write access, you need to apply the correct levels of Permission at the Profile level. Sharing will provide you access to record level whereas profile provides access on object level.

Sharing rules will grant Read or Read/Write dependant on the users Profile access.

Take a look at Adam Tormans response on this question within the Success Community.


You have to relax permission at profile level. If the user does not have permission he will not be able to edit the record

Sharing model allows access of records to non-owners, and non-owners must have that access at profile level.


Organization-wide defaults —specify the default level of access users have to each others’ records. You use organization–wide sharing settings to lock down your data to the most restrictive level, and then use the other sharing tools to selectively give access to other users. For example, you can give all employees access to an object called Candidate to allow anyone to add a candidate to the database. But you can restrict access to Positions so that anyone can see the jobs available but only the employees with the proper permissions can edit them.

Now coming to your scenario,

  1. The permissions on a record are always evaluated according to a combination of object–, field–, and record–level permissions.

  2. When object– versus record–level permissions conflict, the most restrictive settings win.

In your case, you've set OWD of an object as Public Read/Write whereas in Profile you've set it as Read Only. Then the most restrictive access is given. So, in your case User with that Profile will not be able to edit that record.

From Trailhead:

A user’s baseline permissions on any object are determined by the profile.

If the user has any permission sets assigned, these also set the baseline permissions in conjunction with the profile.

Access to records a user does not own are set first by the organization-wide defaults.

If the organization-wide defaults are anything less than Public Read/Write, you can open access back up to certain roles using the role hierarchy. You can further expand access, to additional groups of users, using sharing rules.

Finally, each record owner can manually share individual records with other users by using the Share button on the record

enter image description here

  • This does not address the root of the problem and where the OP seems to be misunderstanding the above. The relationship between the profile permission (Object) and the OWD (Record). Can you expand on that a bit. Good start though
    – Eric
    Mar 31, 2017 at 11:41
  • @Eric Updated the answer. Mar 31, 2017 at 11:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .