The biggest problem with spreadsheets is not missing features, it is that one file can only look one way. Sales want to see progress, managers want it sorted by amount, and the field team just wants to submit one record — so three people each keep their own copy, and the copies stop matching.
Views exist to solve exactly that. One set of underlying data, and everyone sees the shape they need.
30-second overview
| View | What it looks like | Best for |
|---|---|---|
| Grid | A spreadsheet | Entering and checking large amounts of data |
| Kanban | Cards in columns by status | Data that moves through stages |
| Calendar | A month calendar | Data with dates |
| Gallery | Image cards | Data with photos |
| Form | A questionnaire | Letting other people submit data |
How each view is actually used
Grid: the default, and your main workspace
Data entry, bulk edits and quick scanning all happen here. It is where most work starts.
Kanban: make the process visible
Columns come from a single select field, and cards can be dragged between them. It suits customer follow-up stages, task progress and hiring pipelines — anything with clearly defined stages.
Kanban only works if that status field is well designed. Too many stages and you scroll forever; too few and you cannot see progress. In practice five to seven columns is the comfortable range.
Calendar: make the timeline visible
Places records on a month calendar by a date field. It suits content schedules, event planning and follow-up calls.
Gallery: only meaningful when the data has photos
Products, property listings, staff directories. For plain text data, a gallery just wastes space.
Form: the most underrated view
A form view can be shared publicly, the person filling it in needs no account, and they cannot see the existing records.
That solves a very practical problem: you need to collect data without opening the whole database. Inquiry forms, event sign-ups and on-site registration sheets can all be built this way, and submissions land straight in the table.
Filters and sorting live at the view level
This is the point people most often misunderstand: the filters and sorting you set in a view affect only that view.
So you can have all of these at once:
- "All customers" — a grid with no filter
- "Follow up this month" — filtered by status and date
- "High-value customers" — filtered by amount and sorted by amount
Three views, one set of data. Change a record and all three update; change a filter and only that view is affected.
Field visibility is per view too
You can hide unneeded fields in a given view. The sales view does not need internal cost, and the manager's view does not need every logged phone call.
What to watch when sharing externally
A view can produce a public link for people without accounts. Check three things before you open one:
| Check | Why |
|---|---|
| The hidden fields really are hidden | A public view shows whatever that view's field settings say |
| The filter is correct | A wrong filter exposes data that should not be shared |
| Whether it needs a password | Links can be forwarded |
Public links have no concept of expiry; once shared, they stay live. Remember to turn off links you only needed temporarily.
How many views should you create
To be honest: too many views is more trouble than too few. Past a dozen, nobody remembers which is which, and everyone drifts back to the default grid.
The practical approach is to create views by "who is looking", not by "how to look". One for sales, one for managers, one public form, and all three people know which one is theirs.
A view setup that works
Take customer tracking: three people need completely different things.
| Who | View | Settings |
|---|---|---|
| Sales | Kanban | Columns by follow-up stage, filtered to "owner = me" |
| Manager | Grid | No filter, sorted by estimated amount, all fields shown |
| Website | Form | Only three fields: name, contact details, requirement |
One dataset, three views. Sales drag a card to a new stage and the manager's grid reflects it immediately; an inquiry from the website lands in the first column of the sales board.
Three common design mistakes
1. Treating views as backups
Duplicating a view does not duplicate the data. Delete a row in any view and it really is deleted. For backups, use an export, not extra views.
2. Stage fields that are too granular
A Kanban board with twelve columns means nobody scrolls to the end. Five to seven columns is the comfortable range; keep finer distinctions in another field.
3. Forgetting to check before sharing
The classic is "I thought that field was hidden". After you publish a public link, open it once in a private window: what you see is what outsiders see, and the check takes less than a minute.
FAQ
Q: Do views affect the underlying data?
No. Filtering, sorting and hiding fields only change the presentation; the underlying records are untouched. Deleting a record inside a view, however, really does delete it, so be careful.
Q: Can I lock a view so others cannot change it?
Yes. Once locked, other people can view it but cannot change its settings, which stops someone accidentally altering a filter — a problem that is hard to spot, because everything looks normal apart from a few missing rows.
Q: Can forms have required fields and validation?
You can mark fields as required. The field type is itself a form of validation — an email field rejects badly formatted input, for example.
Q: Does dragging a Kanban card change the data?
It does, and that is the point — dragging a card changes the status field on that record. That is exactly why Kanban suits running a process.
Views and permissions work together
Views control what people see; permissions control what they can do. You need both.
| Requirement | View setup | Permission |
|---|---|---|
| Sales only handle their own customers | Filter by owner | Editor |
| Managers see everything but cannot break it | Overview grid, locked | Viewer |
| External people submit but do not read | Form view | No account |
The hole in setting up views without permissions is this: a filter is only a default, and anyone with permission can change it and see everything. Data that truly must not be seen needs permissions or a separate table, not just a hidden field in a view. The full approach is in the permissions and collaboration guide.
When views are not enough
Honestly, there are two situations views cannot solve:
- You need strict field-level permissions — hiding a field is presentation-layer control, not a data permission
- Different people need different field structures — that is two tables, not two views
Naming conventions for views
A small thing, but it decides whether anyone is still using this system three months later.
Name views "who + what they see", not "Grid 2" or "New view". Names like "Sales – my customers", "Manager – sorted by amount" and "Website – inquiry form" tell anyone who opens the base exactly which one to click.
Once you have a lot of views, sloppy naming costs you everything: people fall back to the default grid, and the whole design was for nothing.
Sources and further reading
- NocoDB official documentation—full settings reference for every view
- NocoDB source code and release notes
Further reading
- NocoDB: The Open Source Airtable Alternative
- NocoDB Tutorial: Build Your First Table and Views
- NocoDB Formulas and Links: Let the Data Calculate Itself
- NocoDB Permissions: Who Can See and Who Can Change
- NocoDB as a CRM: When It Is Enough and When to Move On
- 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:
