Where a container-shaped model runs out
Permission models in work-management tools start from containers: the workspace, the base, the board, the table, the field. Record-level rules exist, usually on top tiers and keyed to a person field or a single interface. Operational policy is often about something else — this customer, this stage, this amount. When the two stop lining up, teams duplicate data to create a safe view, and that duplicate is the real cost.
What the workaround actually costs
Duplicating data to make it safe is the most expensive workaround in an operation, because it never gets removed. Every copy needs its own sync, its own permissions and its own explanation to new staff. Meanwhile the real exposure becomes invisible: nobody can answer "who can see this customer's pricing" without opening five settings screens and estimating.
Signals to look for
None of these is decisive on its own. Three or more together usually is.
-
A safe view is made by copying
The way to show a client or a contractor their part of the data is to maintain a second board, base or sheet. That copy is now a second source of truth with no rules of its own.
-
A role sees more than the job needs
Everyone in the role can see every record in the container, so the permission that actually applies is a social one: please do not look at the rest.
-
Authority changes with the number
A discount below a threshold is fine; above it, someone senior has to agree. A container-based permission model has nowhere to put that rule, so it ends up in an approval automation, a policy document, or memory.
-
External people get a whole board to see three fields
A customer, supplier or subcontractor needs to see and do something narrow on their own records. Guest access is often free on mid-tier plans, but it opens a whole shared board or base; the narrower options are usually a paid portal add-on or a filter set on one interface.
-
The automation is the way around the rule
Where a person is blocked, an automation, integration or agent performs the write instead — using credentials that are not bound by the same policy.
How to evaluate it
Five steps, in order. Each one produces something you can put in front of other people rather than an opinion you have to defend.
- 01
Write five real decisions as sentences
Not roles — decisions. "A rep sees the accounts they own. A regional manager sees their region. Finance sees every invoice and no salary field. A client sees their own jobs." Five sentences is enough to expose the shape of the model you actually need.
- 02
Test the five verbs separately
See, edit, act, export and call the API are five different permissions. Most tools let you reason about the first two. The last three are where operations actually leak.
- 03
Include the machines
Automations, integrations, service accounts and AI agents all act on your data. Ask which policy applies to them, and whether it is the same one that applies to people. Two policies means one of them is wrong.
- 04
Check what survives a report
A permission enforced on a screen but not in an export, a dashboard or an API response is not a permission. Test the copy, not the view.
- 05
Price the duplicates you already keep
Count the parallel boards, client copies and filtered exports that exist only to make something safe to share, and the time spent keeping them in agreement. That is the current cost of the gap, and it is already being paid.
Where this leaves Bondi
Where Bondi fits
Bondi applies one policy to people, Portals, APIs, automations and agents alike. On Standard that policy is role, screen and action. On Pro it goes down to the record and the field, with custom roles and Service Accounts for machine identities — so an integration is bound by the same rule as the person it acts for.
- Record- and field-level permissions, custom roles and Service Accounts on Pro
- External Portals on Pro, with no Portal-count or external-user seat limit
- Audit history for 90 days on Standard and 365 days on Pro
The other half of the answer
When Bondi is the wrong answer
- Everyone in the company can legitimately see everything — a simpler model is genuinely safer to operate
- You need SSO or SCIM to enforce it, which Bondi does not offer yet
- The rule is a statutory one that packaged software for your profession already ships
If one of these describes you, the honest recommendation is somewhere else. Nothing on this page is improved by pretending otherwise.
Common questions
Are no-code permissions insecure?
No, and it is the wrong question. A container-based model can be perfectly safe. The question is whether it can express your policy without a workaround — because the workaround, usually a duplicate of the data, is what creates the real exposure.
Do we need record-level permissions on day one?
Usually not. Role, screen and action permissions cover most internal operations and are included on Standard. Go deeper when the rule genuinely depends on which record it is: the customer, the amount, the stage.
How do external users work without buying them seats?
External Portals are included on Pro, and Bondi does not charge external identities as seats — there is no Portal-count or external-user seat limit. Resource quotas, rate limits and your configured permissions still apply, and custom domains and full white-labeling are not currently included.
Do automations get their own permissions?
Yes. Service Accounts on Pro give machine identities their own scoped access, so an integration or an agent is not borrowing a person's credentials to do its work.
Sources
- Airtable — Field and table editing permissions checked 2026-08-03
- Airtable — Interface Designer permissions checked 2026-09-25
- monday.com — Board permissions on Enterprise (item visibility by creator or assignee) checked 2026-09-25
Claims about third-party products are limited to what these documents state on the date shown. Where a document is silent, this guide describes the product's design center rather than asserting a limit.