Enum - PermissionRuleScope

Key: enum.permissionRuleScope

How broadly a rule inside a permissionSet's rules applies.

Values

Value	Description
all	The rule applies to every record the permission code covers (narrowed by any restriction the holder carries — see restrictions).

Currently the only value. The principle of a breadth/scope dimension is kept — a future value can be added the same way any of these were considered — but all is the only one actually implemented today.

Removed

own ("applies only to records the user owns") was considered and dropped — checked against every committed doc at the time, own was not used anywhere, and the one existing ownership-based access rule in the system (report-builder: only a template's creator may rename/edit/delete it) is implemented as a feature-specific business rule keyed off createdBy, not through this generic scope. A future feature wanting a generic "only records the holder created" grant needs its own bespoke createdBy check, same pattern as Report Builder, rather than a Permission Set rule scope.

resource ("applies to one specifically named resource") was accepted on write but never actually enforced — no column anywhere identified which resource a rule of this scope meant, and no endpoint consulted the value at evaluation time. Dropped, rather than built out, once flagged: nothing depended on it, and leaving an accepted-but-unimplemented breadth in place is the specific trap this enum's own concept (Permission Model) warns against — a value that validates on write but silently does nothing at evaluation is worse than not having it. If a future feature needs to restrict a rule to one named resource, it should be redesigned then (with a real resource-identifying column and at least one consuming handler), not revived as-is.

References

• permissionSet.rules (JSON-DAT)