When you are the only user, permissions are pointless.
Add two more people and the problems show up: someone tweaks a filter by accident, someone sees a cost column they should not, someone deletes an entire field and nobody notices.
This article is about drawing those lines before any of that happens.
30-second overview
| Role | Roughly what they can do | Typically |
|---|---|---|
| Owner | Everything, including deletion and billing | You |
| Creator | Change the schema, the data, and create views | Whoever maintains the system |
| Editor | Change data, but not the schema | Most of your colleagues |
| Commenter | View and comment, cannot change anything | Stakeholders who give feedback |
| Viewer | View only | Managers, other departments |
In practice the line that matters most is between Creator and Editor: whether someone can change the schema.
Why schema permissions should be tight
A bad data edit is visible — that cell has the wrong value, and you can put it back.
A bad schema change is hard to spot. Someone switches a field from number to text, or nudges the filter on a view, and everything looks normal on screen. The numbers just stop adding up, and you notice days later.
So make Editor the default, and grant Creator only to the people who genuinely need to restructure tables.
Locking views: protection finer than roles
Roles apply at the base level. But a common need is "everyone should use this view, and nobody should break it".
Once a view is locked, other people can still open it and edit data inside it, but they cannot change its filters, sorting or field settings.
Lock every shared working view. A filter someone silently changed is the kind of problem nobody admits to and nobody notices.
Public links: where things go wrong most often
Any view can produce a public link that works without an account. Convenient, but three things deserve attention:
| Risk | What to do |
|---|---|
| Links get forwarded | Set a password, or turn the link off when you are done |
| There is no concept of expiry | Review which links are still open on a regular basis |
| It shows that view's fields | Confirm the sensitive fields really are hidden before you share it |
The third one bites most often: you think you hid the cost column, but you hid it in a different view. Before you publish a link, open it yourself in a private window and see what it actually shows. That step takes less than a minute.
Forms are the safest way to face outward
If all you want is "let people outside fill in data", use a Form view rather than a public grid view.
A form is write-only — whoever fills it in cannot see the existing records. That is what you should reach for by default when collecting data.
API tokens are permissions too
Every NocoDB table has a REST API, and an API token is a key that never expires.
- Issue one per use case — one for n8n, one for the website form. Then revoking one does not break the others
- Never put one in front-end code — that is the same as publishing it
- Revoke when someone leaves or a project ends
The API quickstart covers how to wire it up.
Practical advice for working as a team
Decide "who needs to see what" before you create views
Views organized by role are more useful than views organized by feature. Sales see their own customers, managers see everything sorted by amount, other departments see status only.
One person owns schema changes
This is a habit, not a permission setting. Only one person should be able to change a table's schema, and everyone else asks them. That is far easier than working out afterwards who changed what.
Deleting is more dangerous than editing
A bad edit can be undone; a deleted row is gone. When you grant Editor, be aware that it includes deleting rows.
A permission plan that works
For a five-person team's customer database, this is how it usually breaks down:
| Who | Role | Extra settings |
|---|---|---|
| You (whoever maintains the system) | Owner | Only you make schema changes |
| Three sales reps | Editor | Their own Kanban views, filtered to "owner = me" |
| Manager | Viewer | An overview view, locked so it cannot be changed |
| Website inquiries | No account | A public link to a form view |
| n8n automation | No account | A dedicated API token |
Two decisions matter here: the manager gets Viewer, not Editor (they do not need to change anything, and an accidental change is expensive), and automations get their own token instead of a shared one (so revoking it does not break another system).
Beyond permissions, the real issue is usually habits
To be honest: most collaboration problems are not misconfigured permissions, they are unclear ownership.
Three things that help more than permission settings:
- Name one person for schema changes — everyone else asks instead of doing it themselves
- Lock every shared view — a filter someone changed is the hardest problem to detect
- Review the list of public links periodically — those links do not expire on their own
FAQ
Q: Can I set permissions at the field level?
Hiding fields in a view gets you something similar, but that is presentation-layer control, not strict data permissions. If your requirement is "these people must never see this field", split the data into separate tables or bases.
Q: How do I know who changed what?
There is a record-level revision history you can check. But that is forensics after the fact, not prevention — tightening schema permissions is still the more effective move.
Q: What if an outside partner needs to see the data?
Create a view with only the fields and filters they need, set a password, and share the link. Do not create an account for them just for this; an account covers more than you think.
Q: Can I track who viewed a public link?
Public links are anonymous by nature. If you need to know who saw what, people have to log in with an account.
Checklist for departures and finished projects
This is the step most often missed, because unlike setting permissions there is no obvious moment that triggers it.
| What to check | Why |
|---|---|
| Remove their account permissions | The basics — but remember they may be in several bases |
| Revoke the API tokens they created | Tokens do not stop working when an account does |
| Public links they opened | Those links have no expiry and are not tied to an account |
| Whether they are the only Creator on a table | Otherwise nobody can change its schema afterwards |
The second row is what actually goes wrong in practice: the account is disabled, but the automation they wrote is still reading and writing data with a token nobody remembers. That is also why we recommend a separate token per use case — at least you know whose it is and what it does.
Sources and further reading
- NocoDB roles and permissions documentation—the full capability matrix for each role
- NocoDB official documentation
- NocoDB source code and release notes
Further reading
- NocoDB: The Open Source Airtable Alternative
- NocoDB Tutorial: Build Your First Table and Views
- NocoDB Views: Grid, Kanban, Calendar and Form
- NocoDB API Quickstart: Tokens, Reading and Writing Tables, Automation
- NocoDB as a CRM: When It Is Enough and When to Move On
- NocoDB FAQ: API Integration, Data Volume and Collaboration
- RoamerHost managed NocoDB plans
Want someone to do it for you?
Once the data volume grows, or the system has to plug into what your company already runs, this stops being a question of picking a tool. Roamer Tech takes on custom enterprise systems and API integration:
