What behavior does the force.com platform perform as it relates to manual sharing records, when ownership changes?
when the owner of a record is changed, the platform deletes all the manual shares associated with the record. In effect, it “clean sthe slate” for the new owner and let them decide whether they want to share it to anybody. And if you have been writing code that shares the record, your shares will get deleted, too, because they have the same ‘manual’ row cause—the platform cannot distinguish between a sharing row you created and a sharing row created through the UI.
What Mechanisms does a developer have to prevent force.com from removing manual sharing records? what are the limitations?
- Apex Sharing Reasons, they are a custom rowCause value. The platform will no longer ignore them when ownership changes.
- Custom objects only (no custom sharing reasons for std objects)
What strategies can I employ to prevent ownership changes from removing manual sharing on std objects?
- External Assignment Engine: Use an outbound message & workflow to detect ownership change and trigger (not sfdc trigger) an external system to act as appropriate
- SFDC Trigger: leverage an after update trigger to send a service call to the external assignment engine
- Shadow Table: when the logic is simple enough to handle it all on SFDC in a custom object. Detect ownership change in an after update trigger then compare those records to any present in the shadow table and recreate records required.
