Platform Security
Roles and ACLs
Authorization on the platform is enforced by access control lists (ACLs) stored in sys_security_acl. Each ACL targets an operation - read, write, create, delete - on a table or a specific field. An ACL has either a condition, a script, or both, and one or more required roles. Evaluation is layered: a table-level ACL gates access to the row; a field-level ACL gates the field on top of that.
Default allow is the rule to remember: if no ACL exists for an operation, the operation is permitted. Security questions frequently test this, because most people assume the opposite.
Contexts and scope
ACLs can be scoped to context - record access in the UI, REST, SOAP, or specific channels - so an integration may have different rules than a person in a browser. User criteria grant access for catalog items, knowledge bases, and portals. For row-level filtering, a read ACL with a condition makes records invisible to users who fail it (they simply do not see the row).
Related controls
Password policies, multi-factor authentication, single sign-on via SAML/OIDC, IP access restrictions, and domain separation (which partitions data and configuration by domain) round out the model. Scoped applications ship with their own role namespace, which is why custom roles often look like x_vendor_app.user.
Trap and rule of thumb
Do not assume admins bypass everything - an ACL can be configured with admin overrides disabled. Rule of thumb: most specific wins; absence of an ACL means open. When designing, start from table-level ACLs, then add field ACLs only where needed.