May the full row of entityName be broadcast alongside its cache-invalidation event?
The subscription below is filtered only by ENTITY-level read permission, so anything included
here is disclosed to every signed-in session that may read the entity at all — regardless of
row-level security, field-level security, or any tenant scoping a consumer applies on the read
path, none of which this push traverses. The answer is therefore NO unless a deployment has
explicitly opted the entity in via cacheSettings.recordDataBroadcastEntities, and always NO
for an entity under field-level security (its own flag or an IS-A ancestor's), and for
MJ: Record Changes, whatever the allowlist says: the row would carry columns (or, for Record
Changes, other entities' values) some of those sessions may not read.
Callers that get false simply omit recordData; the event still carries the entity name and
primary key, so clients evict and re-fetch through the normal access-controlled read path.
Matching is exact (trimmed, case-insensitive) rather than substring: a loose match would let an
allowlisted name drag in every entity whose name contains it.
May the full row of
entityNamebe broadcast alongside its cache-invalidation event?The subscription below is filtered only by ENTITY-level read permission, so anything included here is disclosed to every signed-in session that may read the entity at all — regardless of row-level security, field-level security, or any tenant scoping a consumer applies on the read path, none of which this push traverses. The answer is therefore NO unless a deployment has explicitly opted the entity in via
cacheSettings.recordDataBroadcastEntities, and always NO for an entity under field-level security (its own flag or an IS-A ancestor's), and forMJ: Record Changes, whatever the allowlist says: the row would carry columns (or, for Record Changes, other entities' values) some of those sessions may not read.Callers that get
falsesimply omitrecordData; the event still carries the entity name and primary key, so clients evict and re-fetch through the normal access-controlled read path.Matching is exact (trimmed, case-insensitive) rather than substring: a loose match would let an allowlisted name drag in every entity whose name contains it.