9

Disclaimer! I have searched for a result to this question on the web with no success therefore I need someone with expertise to review it and provide an answer.

I use a public read/write OWD model on an object Object__c, therefore all users can view all these records for this object. However, there may be some objects that need to be privatised, i.e., the vast majority SHOULD be available to all users, but only a FEW need to be made private. Furthermore I would like the user to be able to select which role or user they can limit the record access to. How can I achieve this through configuration or code?

13

I have always had the understanding that as soon as any records need to be private than that defines yours OWD as Private. Then sharing rules and the role hierarchy are used to open up access. I think any other mechanism would not prevent the user getting access to the record via an export or a report for example.

You might use a sharing rule based on criteria picklist not equal to which shares with your top role and subordinate. Then another rule with the picklist equal to sharing with a custom group of the users who need access.

I'm not aware of another way of doing...I suppose you could use a VF page but that's not true security the users would still be able to report on it.

10

The salesforce.com sharing mechanism is permissive, not restrictive, meaning you can only ever increase access through code or configuration levels, not decrease it. This means that if your organization wide defaults (OWD) is set to Public Read/Write, then no record may be less than Public Read/Write to any user, assuming that user has the appropriate profile permissions (but that's not a sharing setting). For example, with OWD of Public Read/Write, it is ineffective to try and create a manual share for Read/Only, because it would have no effect.

The bottom layer of sharing is the OWD. It defines the minimum access to a specific record, assuming the user has profile permissions to that object. Higher levels of OWD increase system performance, because fewer checks must be made to determine if a user has access to a record. For example, queries will run much faster if OWD is at least Public Read/Only, and edits will be marginally faster if the OWD is Public Read/Write. After OWD comes sharing rules, owner sharing, team sharing, manual sharing, implicit sharing, and role hierarchy sharing. It doesn't matter which order these rules are evaluated in, as the highest permission wins.

So, to make most records Public Read/Write, but a few Private, you have to start with Private OWD, then build sharing rules that meet your criteria. Thanks to Criteria-Based Sharing, you can choose to create rules where records of a certain record type, etc are shared with all users. The remainder can then be manually shared, or by code, or by more specific rules. This may have a performance impact on list views, reports, and searches, as the Private OWD will automatically kick off a bunch of other necessary checks to see if users have access to a specific record.

6

First, as resources, I recommend the Security Implementation Guide, the Security Workbook and the Sharing Cheatsheet.

It sounds like you want to set the OWD on your custom object to Private, then create a sharing groups at different role levels and enable sharing on the custom object. You'll want to create a group that includes the users you know should have access to the fields you want available to everyone, if that's everyone in the org, then select CEO and subordinants (assuming that role exists). You'll find more detail on this in the references I've mentioned along with the Force.com Workbook.

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.