3

Querying AccountShare

When I query for an AccountShare, I get some interesting stuff, including an ID but no name, label or fullname :

SELECT ID, RowCause, UserOrGroupId, AccountAccessLevel, ContactAccessLevel, CaseAccessLevel, OpportunityAccessLevel FROM AccountShare WHERE AccountId = 'any-account-id'

returns stuff like this

enter image description here

Account Sharing Rule in Setup

Supposing the returned id is '03Gb0000000L72T', I can lookup this sharing rule at

https://<mydomain>.my.salesforce.com/setup/own/shareRule.jsp?id=03Gb0000000L72T

This setup screen shows some descriptive fields 'Label', 'Rule Name', 'Description' before the definition of the sharing rule :

Sharing rule

Account Sharing Rule in SFDX Metadata

Now when I look at what SFDX returns for those AccountShare sharing rules, in sharingRules/Account.sharingRules-meta.xml, I get something like this : enter image description here

Question

** How can I programmatically match the AccountShare id and the Account.sharingRules fullName ?**

1
  • PS : I do realize that the id returned by theSELECT AccountShare is not the SharingRule id, but the id of the AccountShare created by that sharing rule for a given Account record. – altius_rup Nov 4 '20 at 18:25
1

I don't think there is such a thing. The RowCause should be Rule if it resulted from criteria-based sharing, not ImplicitParent. But in any case there is no lookup from this object to the rule itself. Criteria-based sharing is calculated at the time of DML on the row, and mass recalculated after you update a criteria-based sharing rule. I'm not sure the platform even KNOWS which rule the sharing row came from.

4
  • 1
    If it knows, it certainly won't tell us. I think internally there's some sort of mapping for efficiency purposes, but we don't have access to that. – sfdcfox Nov 4 '20 at 20:19
  • My reckoning is that - based on the limits to how many criteria rules can exist on one object, and the fact that re-evaluation runs at the end of every DML transaction - it probably calculates every rule on-the-fly at runtime and decides which share rows should still exist. And I would guess when you trigger a mass recalculation by adding a rule, it re-evaluates ALL applicable rules. – Charles T Nov 4 '20 at 23:08
  • @CharlesT I saw in a video a long time ago, about SF implementation, that share records are generated when the rules are calculated, NOT at run-time : that is why it takes a long time, and can be deferred. – altius_rup Nov 5 '20 at 13:28
  • Sorry to be clear, when I said "runtime" I meant only for the end-of-DML recalculation on a record. That does happen synchronously. – Charles T Nov 5 '20 at 14:40

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.