Security and Access Control
Levels and roles
Project security has three levels: Off, Prototype and Production. Prototype allows demo users and belongs in development; Production enforces every rule and is required for a real deployment. Module roles are defined inside each module. User roles map to one or more module roles, and a user receives the union of the mapped roles' rights.
Entity and member access
Each entity has access rules per module role with create, read, write and delete flags plus an optional XPath constraint for row-level filtering. Attribute access is separate: entity-level write does not grant write on an attribute, and if no attribute is readable the entity is unreadable for that role. In a user context the runtime adds entity-access constraints to every retrieve, so a microflow that retrieves all invoices returns only permitted rows.
Microflows, pages and services
Microflow and nanoflow access lists the module roles allowed to call them from the client. Pages are secured per module role and must also be reachable through navigation. Published REST and OData services and consumed/published web services carry their own allowed roles and authentication settings.
Worked example
Invoice is readable by Finance with no constraint and by Sales only with [System.owner = '[%CurrentUser%]']. A Sales user opens a page whose data source is a microflow retrieving all invoices: the runtime silently applies the constraint and returns only that user's invoices. The same microflow called from a scheduled event runs in a system context, where entity access is not applied and everything is returned. Reasoning: never expose system-context output directly to a user without re-checking rights.
Traps
Granting create but not write, so users create records they cannot edit; writing a constraint over an association the role cannot read; forgetting to add microflow access after introducing a new role; assuming Prototype enforces the same rules as Production.