Governance is designed into the application
Access control and business rules are part of the architecture, not a layer added before launch. Roles, policies, granular permissions, server-side enforcement and workflow controls decide who can act, which records and fields they reach, and how important changes happen.
- Roles, policies and permissions
- Field and record level rules
- Enforced on the server
Enforced in more than one layer.
BuildPad DaaS uses defence in depth. Hiding a button improves the experience, but it is not an authorization model, so the rules sit lower down too.
Application 01 of 03
Sessions and input
The application layer validates JWTs, manages sessions and checks input, so a request is identified before it reaches anything else.
Roles, policies and permissions.
Access is built from three parts that are managed centrally instead of being spread across screens.
Roles describe who a user is
- A role is a named group such as Editor, Viewer or Approver
- Each role can have an icon, a parent role and assigned users
- One user can hold several roles at once
- Policies attach to the role, not to each screen
Users can hold several roles at once, so responsibilities combine.
Policies decide what access those roles get
- Policies hold the access flags and permission rules
- They attach to a role, or to one user where needed
- A user's access is the union of everything attached
- Flags cover admin, DaaS Studio and delegate access
A user's effective access is the union of everything attached to them.
Rules down to the action, field and record
- One rule covers one action on one collection
- Create, read, update, delete and share
- Rules set which fields and records a user can reach
- They can also set valid values and defaults on create
Two kinds of access, kept apart.
Managing a project is not the same as approving a record inside the application, so the two are separate systems for separate audiences.
BuildPad Dev Platform roles
Decide what a person can do to the project itself: working inside the organization and managing platform-level resources.
- Organization and project access
- Microapps, workers and builds
- For the team building the app
DaaS roles and policies
Decide what users of the application can do with its data while it runs, down to the action, the field and the record.
- Collections, fields and records
- Workflow transitions
- For the people using the app
Governance is the promise. xAppHub is the product that keeps it.
Everything on this page is true of one application. The harder question is what happens at thirty: who has access to what, across everything your teams have commissioned, and who can answer that in one place. That is xAppHub. One portal, one access model, one reporting layer.
See xAppHub