ObjectOSRecord Access
Control which records a user can see or modify.
Record access controls which rows a user can see or modify after object permissions allow the operation.
Mechanisms
| Mechanism | Purpose |
|---|---|
| Row-level security | Enforce tenant or organization isolation |
| Sharing rules | Grant access based on declarative criteria |
| Record shares | Grant access to a specific user, position, or unit (with subordinates) |
| Ownership/hierarchy | Grant access through the owner and the business-unit tree |
Sharing model defaults
Every object declares (or inherits) a sharingModel that sets the
organization-wide default: private, public_read,
public_read_write, or controlled_by_parent.
Since ObjectStack 13, custom objects that carry an owner field and do
not declare a sharingModel default to private — records are
visible to their owner (and admins) until a sharing rule, record share,
or wider default opens them up. Declare the model explicitly to restore
open behavior:
defineObject({
name: 'crm_lead',
sharingModel: 'public_read_write',
// …
});The pre-13 aliases read, read_write, and full were removed;
os compile flags unset or aliased models via the security-owd-unset
and security-owd-alias lints.
Default tenant isolation
The security plugin enforces tenant isolation through the current user's context. For standard platform objects, default rules protect global tables that do not carry the normal organization field.
The practical customer expectation is:
Users only see records that belong to their organization or records
explicitly shared with them.Sharing rules
Use sharing rules for repeatable business policies:
- all regional managers can read accounts in their region;
- support managers can see escalated cases;
- finance can read approved invoices;
- auditors can read records tagged for audit review.
Record shares
Use record shares for exceptions:
- share one opportunity with a specialist;
- grant temporary access during an escalation;
- give an external integration access to a specific record.
Troubleshooting visibility
When a user cannot see a record, check in this order:
- Is the user authenticated and in the expected organization?
- Does the user have object
readpermission? - What is the object's
sharingModel(custom objects default toprivatesince ObjectStack 13)? - Does row-level security allow the record?
- Is there a sharing rule that should apply?
- Is there a direct record share?
- Is the record owned by a user in the expected business-unit subtree?
- Is the user looking at the correct project/hostname?
The explain engine answers all of these in one call — it reports each layer's verdict and which grant (or missing grant) decided the outcome.