2

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. – Saumya Ranjan Satapathy Mar 31 '17 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 '17 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. – Saumya Ranjan Satapathy Mar 31 '17 at 11:12
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.

3

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.

2

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 '17 at 11:41
  • @Eric Updated the answer. – Rohit Mourya Mar 31 '17 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.