ObjectOSPermission Sets
Grant application, object, field, and system permissions.
Permission Sets
Permission sets are the primary way to grant capabilities. They can be assigned directly to users or indirectly through roles.
What permission sets control
| Permission type | Examples |
|---|---|
| Application access | User can open CRM or Console |
| Object permissions | Create, read, update, delete records |
| Field permissions | Read or update selected fields |
| System permissions | Access Console, run reports, export data |
| Integration permissions | Use API keys, webhooks, or admin actions |
Object permissions
Object permissions answer:
Can this user perform this operation on this object at all?Permission set grants use these flag names (as enforced by the security plugin's permission evaluator):
| Flag | Meaning |
|---|---|
allowRead | Read records allowed by record access rules |
allowCreate | Create records |
allowEdit | Update records allowed by record access rules |
allowDelete | Delete records allowed by record access rules |
viewAllRecords | Read every record for the object, bypassing record access |
modifyAllRecords | Update or delete every record for the object, bypassing record access; implies viewAllRecords for reads |
Record access still matters unless viewAllRecords or modifyAllRecords
bypasses the normal row-level boundary. Reserve those flags for
administrative permission sets — they are effectively a tenant-wide
super-user grant for that object.
System permissions
System permissions are for platform actions such as:
- Console access;
- manage users;
- manage roles and permission sets;
- run reports;
- export reports;
- manage integrations;
- view audit logs.
Keep system permissions separate from business object permissions so administrators can audit them easily.
Recommended sets
Start with a few named permission sets:
| Permission set | Purpose |
|---|---|
| Basic User | Login and access the main application |
| Setup Administrator | Manage users, roles, settings, and diagnostics |
| Report Viewer | View reports and dashboards |
| Integration Operator | Manage webhooks/API keys |
| Support User | Read/update support objects |
Then add domain-specific sets for the customer's application.
Field security (appendix)
Permission sets also carry field-level grants. Even when a user can read a record, individual fields can be hidden or made read-only.
Two modes
| Mode | Effect |
|---|---|
| Hidden | Field is stripped from API responses and Console views entirely |
| Read-only | Field is returned but writes are rejected |
Where it's enforced
The same evaluator that checks object permissions applies field rules on every path — REST, ObjectQL, generated Console forms, exports. There is no "back door" through a lower-level API.
Typical patterns
| Use case | Recommendation |
|---|---|
HR data on sys_user (salary, SSN) | Hide for everyone except an HR permission set |
| External system identifiers | Read-only for support, writable for integration operators |
Internal cost vs. customer price on product | Hide cost from sales, surface to finance |
| Notes field with PHI | Hide unless permission set includes the relevant clinical role |
Authoring guidance
- Default to hide rather than read-only when the field carries sensitive data — read-only still leaks the value into responses and logs.
- Bundle field rules into permission sets that match a real role
(
HR Manager,Finance Read-only) instead of inventing one set per field — easier to audit. - For compliance use cases, pair field security with audit log retention so you can answer "who saw this row?" after the fact.