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.
Territory Management is more than just a sharing device, it probably makes sense when there exist clearly defined Sales Territories, with Sales Reps mapped to Territories and where Sharing Accounts and Opportunities would be tedious through conventional means - be it Account/ Sales Teams and/or Ownership/Criteria Based sharing rules.
Everyone in a territory ...
I would hazard a guess that you have sharing rules on the account that are causing the contacts to be shared. However, you can definitely determine why by going to a "deleted" contact, and clicking on the Sharing button. From this page, click on the Expand List button, and choose the "Why?" Link next to a user that shouldn't have access. It will list all the ...
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 ...
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 ...
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 ...
"Only Manual Share Records can be created on standard objects".
The above sentence is definitely incorrect. It must be a documentation error or a (failed) attempt to describe some other limitation or Manual Sharing.
"You can create criteria-based sharing rules for accounts,
opportunities, cases, contacts, leads, campaigns, and custom objects."
If your Sharing Settings use "Use Role Hierarchy", you get this feature for free if you set up your role hierarchy correctly. Otherwise, you'll have to create a mess of public groups and creating sharing that way. You can't use the Manager field on the user record to cause sharing without using a trigger. Personally, I would advise configuring your role ...
Unlike master-detail relationships, Accounts in a hierarchy don't have an implicit sharing model. Therefore, I think the only options for you are the two you outlined.
There is one alternative worth mentioning and that is Territory Management. The idea with territory management is to tie account and/or opportunities into defined territories. This may be ...
Just have a User trigger create ContactShares when a User is added to a Group.
public static void shareContacts(Map<Id, Set<Id>> groupToContacts)
List<ContactShare> contactShares = new List<ContactShare>();
for (Id groupId : groupToContacts.keySet())
for (Id contactId : new List<Id> ( groupToContacts.get(...
You cannot share private contacts currently. Check the success community forum.
You cannot share contacts without accounts .just for visibility sake you may assign a dummy account to your contacts
There is a way which can help in troubleshooting and narrowing the problem
Query your contactShare table with newly created contactId and the userId for the user you are troubleshooting and if you dont get any records this means rule did not run.
[ Select ContactAccessLevel,
Territory Management sounds like the feature you're looking for. Try this in a sandbox or developer edition first, of course. Roles are for a more traditional approach where a user has a defined place in an organizational hierarchy, and doesn't translate well to business processes that have overlapping territory.
This doesn't appear to be possible. If other permissions are already in place, a workaround for the delete problem is to create a custom controller with the delete operation and give it the without sharing modifier.
It think it is provided in the documentation link that you have mentioned, in the end.
An Apex class used for recalculation must be associated with a custom
To associate an Apex managed sharing recalculation class with a custom object:
From the management settings for the custom object, go to Apex Sharing Recalculations.
Choose the Apex class ...
If you users have same profile then you cant use page-layouts-profile trick to hide edit button then you have to restrict update using Validation Rule.
AND ($UserRole.Name =='Department A' ,
CASE(RecordType.Name ,'T',true,'U',true,'V',true,'W',true,false) ,
Sharing is not used for giving access to read/edit object but specific record.
In your case you probably should create permission set for people that would be able Create, Edit, Delete Libraries and assign it to them. Then create sharing rule that will permit the group to Read/Edit records (which you already have).
The record owner is automatically granted Full Access, allowing them to view, edit, transfer, share, and delete the record
If the user is the owner of the record then they have implicit visibility. You will need to remove that user from being the ...
There are couple of ways you can do the sharing on child records,
Apex Sharing - Create a custom button on Master Object. On click of that button query the child record and used the apex sharing to share the child records.
You can vote for an idea Sharing Settings for Lookup Relationships like Controlled by Parent
I think that this can be solved by doing the following:
Create a Public Group.
Create a CheckBox on the Account with name:"XYZ"
Create the same CheckBox on the User page layout.
Create a Sharing Rule on Account based on criteria. Criteria is 'checkBox(XYZ) equals true'. Now assign the account to the public
group created in point one.
Not really. It's theoretically possible to do so, but not even Financialforce's MDAPI supports SharingRule. You would have to spend a significant amount of effort. For custom objects, you can use Apex Managed Sharing, and for standard objects, consider Apex-based manual sharing; it's relatively painless to perform in bulk, and is pretty easy to maintain. In ...
Sharing rules are usually present in the metadata .So metadata API will have definitions of your rule .
Salesforce recommends to use this for all updates to sharing rules .
However under the hood salesforce has tables named as "OwnerSharingRules" for each object where you have these sharing rules .
However to enable these object for your org you will ...
There is no way to unit test Criteria Based Sharing so that post is still accurate, So what I would do is create a few records, and then jump from user name to user name and see if they can see the newly created record. It's going to have to be a manual process..
As you discovered from the comments of others, you've encountered a limitation of most portal licenses except Partner Portal Licenses. About the only other option you'd have would be to "mirror" your Account Object and your Contact Object (or portions thereof) as custom objects using triggers (as part of a custom application) in order to make them available ...
First you are correct that M-D relationship is out.
As for sharing rule, I'm looking at a sharing rule in an org I demo with where I have a criteria-based sharing rule that shares with the Public Group "All Customer Portal Users". So sharing with rules to Customer portal is an option, however, sharing rules do not support sharing to individual users ...