16

I believe what you are looking for is Super User access: Super User Access Users can be assigned super user access to give them access to data owned by other users belonging to the same role or those below in the hierarchy. For example, a Partner Manager with super user access can see data owned by other users in the Partner Manager role and ...


15

You can ask support to enable a feature called Defer Sharing Calculations. That way, you can suspend sharing rule calculations to not have them run immediately after you have deployed them, but at a time that suits you better.


10

The issue is some combination of data skew and (potentially) ownership skew. Furthermore, sharing rules might lengthen the time of parent record locks, leading to increased chances for row locks. Data Skew Because all records of both objects are related to the (single) Parent Account, the update of each Opportunity and the insertion of each Opp_Revenue__c ...


8

What you're attempting to create are Criteria-Based Sharing Rules. Unfortunately, you can't share records with your partners using criteria-based sharing. Instead, you can only share records based on their Role, not values in the record itself unless you use Apex Managed Sharing. In order to share records with Partners in the Community based on record ...


6

Refer this documentation: Sharing a Record Using Apex Apex sharing reasons are defined on an object's detail page. Each Apex sharing reason has a label and a name: The label displays in the Reason column when viewing the sharing for a record in the user interface. This label allows users and administrators to understand the source of the sharing. The label ...


5

You can't really restrict access to view records based on record types from the profile level. if you think of Salesforce as a filing cabinet, each drawer is an object, within the drawer there are folders that group the records. Record Types are those folder. On the profile when you say user has record type x, y or z available to them it only means their ...


5

without sharing will not reinforce SFDC field level access and visibility, so you will be running your class on system context. In system context, Apex code has access to all objects and fields— object permissions, field-level security, sharing rules aren’t applied for the current user. This is to ensure that code won’t fail to run because of ...


4

All security-related methods, such as UserRecordAccess and the describe calls, will always return the user's real permissions. All that "without sharing" does is turns off the permission and sharing table checks when querying, updating, or deleting records. It is strongly recommended by salesforce.com that developers check for a user's permission to fields, ...


4

I think you need to make sure that there are values in all your mandatory fields. The error could be related to a validation rule that fires if you don't insert for a a field related to "department team". As Rahul said, you should put sometime in Trailhead as well.


4

You can do manual sharing using Apex. It is possible to manually share a record to a user or a group using Apex or the SOAP API. If the owner of the record changes, the sharing is automatically deleted. To access sharing programmatically, you must use the share object associated with the standard or custom object for which you want to share. For example, ...


4

It would seem that Custom Report Types drilled down to the Users Role DO NOT respect the sharing rules ADDING records that the role would not normally see with the Hierarchy alone... Idea: https://success.salesforce.com/ideaView?id=08730000000kzURAAY Knowledge Article: https://help.salesforce.com/HTViewSolution?id=000004564 It seems counter intuitive but ...


4

For first point yes your assumption is correct. For second point is if in future you want to restrict this for some user and allow for some users then you need to again change the OWD to private but using sharing rule you just need to update their role do its easy to maintain. Also sharing rule will only user with Role Recruiter to see the records but the ...


4

No. Sharing rules open up access to records. If the user's profile does not have edit on the contact object, he will not be able to edit the record.


4

From the documentation, two critical rules: Inner classes do not inherit the sharing setting from their container class. Classes inherit this setting from a parent class when one class extends or implements another. And when no sharing model is declared or inherited, If a class isn’t declared as either with or without sharing, the current sharing rules ...


4

It's allowing you to delete it because it's a without sharing class, in which Apex does not enforce sharing permissions. This is correct behaviour. Also recall that object- and field-level permissions are not evaluated in Apex code unless you check them yourself. In a with sharing class, you said it is giving no rows found on SOQL. This is also correct ...


4

All of the notes in the docs apply: Apex sharing reasons and Apex managed sharing recalculation are only available for custom objects. Every time a custom object's organization-wide sharing default access level is updated, any Apex recalculation classes defined for associated custom object are also executed. The object’s organization-wide default access ...


3

You absolutely can get this error by having 2 successive iterations in a batch try to update the same group of parents in a hierarchy. This is one of the worst parts about having data skew and why there is 1 parent account in your error message. The Opportunity and Opp_Revenue__c are causing a lock row in the Account hierarchy, since there is no guarantee ...


3

I have encountered this exact challenge before. The simplest approach I've found is to do the following: Create a Public Group for each Territory/Zone Assign users to their relevant Public Groups With either apex managed sharing or criteria based sharing create an AccountShare record with UserOrGroupId=Account Territory/Zone The third bullet has a lot of ...


3

You should leverage Case Team functionality. Basically, whenever Case ownership changes you should add the user to a case team as member and provide read/write access to that user. Here is the logic: Define case team role. If previous case owner ownerId and new OwnerId are not same then add the user in the team. Also, put a check that, previous ...


3

One bit of advice from past experience -- If you think your org will be the "winning org" when and if you acquire another company or add another business unit wherein the acquired company's users shouldn't be able to see Accounts/Oppos/Cases/etc owned by users in your current org, then .. Start with OWD Private If you think your org will divest a business ...


3

The most probable answer to you issue might be how Activity Access Levels work in SF. When you set "Controlled by Parent" to Activities it means: A user can perform an action (such as view, edit, transfer, and delete) on an activity based on whether he or she can perform that same action on the records associated with the activity. For example, ...


3

The "Transfer Cases" permission will give you the access you are looking for. You can find some information here: https://help.salesforce.com/articleView?id=000175883&type=1 And here: https://help.salesforce.com/articleView?id=data_about_transfer.htm&type=5


3

Just to test out... I created a sharing reason for a test object and ran the following line in Developer Console: System.debug(Schema.MyObj__Share.rowCause.MyCause__c instanceof String); I got back the error Operation instanceof is always true since an instance of String is always an instance of String. So that tells me it returns a String and not some ...


3

I would ideally write a Trigger on After Insert/After Update, and create ContractShare record with edit access. But, You cannot create an Apex Sharing for Contract. Also, Account and contracts are tightly coupled. Which means you have to give read-write access to Accounts to get Edit Access on contracts. I would handle it using Sharing rule based on ...


3

Because of M-D relationship of the Account and Contract, if Account has Edit access then Contract will automatically have Edit access. As Contract is Detail object so ownership is governed by Account owner. Best way to handle this is, when Account owner is getting changed then create a trigger to add previous owner as Account Team member of that Account and ...


3

Edit is a CRUD permission on the Object, in this case Opportunity, defined on profile/permission set level. So as long as a User on say Profile A has Edit rights on Opportunity, they will always be able to view the Edit button all across, if the button is available on the page layouts. Your options here are: Change the OWD to Private. As long as Users from ...


3

Set up records that need sharing in @testSetup. The share records will be visible for all unit tests after @testSetup completes. By using @testSetup, things that occur "after the transaction", such as record sharing, are created. Tests that use those records will then have access to those records. Confirmation @isTest class q293720 { @testSetup ...


3

Note that both of them create share records under the hood. Most of objects in salesforce (exception may be a detail object in master-detail relationships) have a junction object with name __share that holds share records. It’s advisable not to use apex sharing unless you absolutely need it and use the platform sharing features. This is because you can do ...


3

The advantage of Apex sharing is that you can calculate sharing conditions that otherwise cannot be done by standard and criteria-based sharing rules. For example, you could base sharing on an web service call, a separate business logic sharing table, standard or custom fields, etc. For the majority of use cases, the various sharing systems in Salesforce ...


3

From the Manual Sharing section of the document "A Guide to Sharing Architecture" https://developer.salesforce.com/docs/atlas.en-us.dat.meta/dat/dat_components.htm Manual sharing is removed when the record owner changes or when the sharing access granted doesn't grant additional access beyond the object's organization-wide sharing default access ...


Only top voted, non community-wiki answers of a minimum length are eligible