Summary
When you enable multiple views on an entity and organize each view with its own curated set of fields and relationships, creating a new field on that entity causes the new field to appear at the top of every view. You then have to manually open each view and hide the field — once per view, every time a new field is added.
There is no setting to prevent this, and for users who intentionally organize views as mutually exclusive groupings, it creates unavoidable rework every single time the schema is extended.
Where this happens
-
Open any entity (e.g. a Company)
-
Go to Views and enable multiple views
-
Create tabs — each tab is a view where you can group fields and relationships however you want
-
Spend time organizing each view so that every field and relationship has a logical home, and no field appears in more than one view
-
Add a new field to the entity’s database
-
That new field now appears at the top of all views you created
Why this is a problem
The entire point of creating multiple views on an entity is to separate fields and relationships into distinct, purposeful tabs. The typical setup:
-
View 1: Overview / headline fields
-
View 2: Contacts + communication
-
View 3: Deals + pipeline
-
View 4: Projects + services
-
View 5: Assets + deliverables
-
…and so on
In this kind of setup, every field lives in exactly one view. There is no scenario in which a user who has deliberately built 10 organized views would also want a newly created field to appear in all 10 of them.
So the current behavior guarantees that:
-
Creating a new field = polluting 10 views with that field
-
The user must then open each view, find the new field at the top, and hide it
-
This happens again for the next field, and the next, and the next
It’s a tax on schema evolution. The more organized your views are, the more painful it becomes to add fields.
What I’d expect
One of the following, ideally as a workspace/entity-level setting:
-
New fields are hidden in all views by default. The user explicitly adds a new field to whichever view(s) it belongs in.
-
Per-view “auto-add new fields” toggle. Some users may want auto-add on certain views (e.g. an “All Fields” debug view); most views should be able to opt out.
-
When creating a new field, prompt the user to assign it to a specific view. Similar to how some tools ask where a new column should live.
Any of these would prevent the unavoidable rework without removing the current behavior for users who actually rely on it.
Current workaround
Manually open every view after creating a field and hide the field. This scales poorly — with 10 views, one new field = 10 hide operations. Adding 5 fields in a schema change = 50 hide operations.
Severity
Low-impact individually, but it adds up fast for anyone who organizes their entity views carefully. Friction actively discourages good view hygiene: the cleaner and more numerous your views, the more you pay each time you evolve the schema.