Permissions
What a credential may do, and why it can never be more than the person who made it.
The model
An app has groups, and each group has its own permissions: on which tables it may do which operations, optionally narrowed to some rows and some fields. A person's access is the union of their groups, taken per field and per operation. There is no order, no deny and no override, so adding a group can only ever add access, and anything no group allows is denied.
Four questions, answered separately
| Question | Example |
|---|---|
| Which tables | Support cannot see invoices at all |
| Which rows | A rep sees deals where owner is them |
| Which fields | Nobody outside Finance sees margin |
| Which actions | Read yes, delete no |
What "cannot read" actually means
A field you cannot read is absent, not blanked. It is not in the row, not in the schema document, not in the OpenAPI spec you are served, not in the MCP tool list, and not named in any error, because naming it would be the leak the rule exists to prevent.
Before you change a rule
Ask what someone would see, without granting it to them. This answers with the rows and fields a set of groups would get, and changes nothing:
POST /v1/apps/{appId}/rules/simulate
{ "groups": ["grp_v6nh3ta8rk2e"], "tableId": "tbl_8fj3kq2wmv5d", "op": "read" }The answer breaks the union down per group, so you can see which group is granting what.