Sharing vs. Salesforce's Recalculation Model
Salesforce’s sharing model – implicit parent/child sharing on Master-Detail,
criteria-based sharing rules, manual sharing – is backed by a materialized
sharing table (AccountShare, OpportunityShare, and so on) that a
recalculation job keeps in sync with org-wide defaults, role hierarchy, and
rule changes. That job can run slowly on large data sets, leaving visibility
briefly out of date between a change and the job’s completion.
Henceforth has no equivalent job, because it has no equivalent materialized
table. Visibility is evaluated live, on every read, by PostgreSQL row-level
security policies, under the two-tier authorization model – a service-layer
PDP check followed by an RLS USING clause that PostgreSQL evaluates as part
of the query plan itself (see Authorization
model).
There is nothing to fall behind, because there is nothing precomputed.
What’s actually shipped
Section titled “What’s actually shipped”The one sharing mechanism shipped today is sharing.edge on junction
(many-to-many)
relationships:
setting sharing: { edge: "endpoints" } lets a principal read a junction
edge when they can read both endpoint rows, in addition to the edge’s own
owner. The generated RLS policy is a plain boolean expression – owner_exists OR (from_exists AND to_exists) – evaluated per row, per query, by Postgres
itself.
Propagation is one-hop and explicit: it applies to the relationship it is declared on, and only to that relationship. There is no transitive “sharing cascades several levels down” behavior, by design – see Relationships and Lookups: sharing. Forward propagation (edges visible to principals who can see the source record) and reverse propagation for lookup relationships are designed but not yet shipped (#663, under epic #650).