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 ?**

Improve this question
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, 2020 at 18:25

1 Answer 1

Reset to default
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.

Improve this answer
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, 2020 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, 2020 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, 2020 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, 2020 at 14:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .