When building views I find myself wanting to see derived information - most commonly another field from a relation and an aggregation of fields. For example when looking at Feature requests associated with User I might want to see User.company or User.status (Trial, Paying, etc.) instead. And honestly sometimes I just want to play around to see if connecting some of the information together will deliver an insight. At the moment I need to add an entity level formula field to derive this information which then “pollutes” the entity. Also - as I understand but haven’t tested it - users without permissions to modify entity schema won’t be allowed to do this at all. It would be great to be able to define view-level (aka “throw-away”) formula fields when specific information is only required for bespoke view or it’s needed one time only when playing around with your knowledge base. Similar to: Formulas in Views Filters

I mentioned what I think is the same idea a while back, it’s similar to something Coda can do, and Michael said it should be “easy” to implement, so hopefully it comes around! [image] Migrate Entity View to Blocks Ideas & Features I know Michael addressed this, but in case there is remaining confusion, my understanding is that Blocks will be arbitrary units of content/functionality, and will not have to be consistent from entity to entity, thus they do not involve creating “fields”. They are a more “lightweight” solution than formalized Type modifications, i.e. new Fields. Perhaps that is a more direct/succinct answer to the root of your question/concern. Think of them like blocks in Notion, simply individually manipula… Also possibly related (read through the thread, hopefully you’ll see the connection): [image] Block inputs and outputs Ideas & Features This is obviously related to the [IN DEV] Migrate Entity View to Blocks but thought it might be worth it to keep it separate. One of the things that I hope would be baked into the foundation of the blocks is ability to define inputs and outputs into a block. I assume the block types in the first iteration would be very basic and probably static (text, bullets, views with hardcoded filters, etc.) . However, in the long run, I would hope that we will have more dynamic blocks available (perhaps so…

It does look related, although the conversation was focused on Blocks, which was a bit confusing to me. Are Blocks intended to replace current Views (Table, List, etc.)? Will Table and List views stay as the basic out of the box components and Blocks are intended to be the more advanced flexible alternative?

[image] Pawel_Badenski: When building views I find myself wanting to see derived information - most commonly another field from a relation and an aggregation of fields. I’m not sure I fully understand the use case you’re describing. Are you thinking in reference to a particular type of view (Report, Board, Timeline, Table, Document…)? [image] Pawel_Badenski: For example when looking at Feature requests associated with User I might want to see User.company or User.status (Trial, Paying, etc.) instead. Where do you imagine the user information (Company or Status) would be displayed/presented when viewing a particular set of Feature requests? Or are you talking about being able to filter which Feature requests are shown according to a characteristic that belongs to the User?

[image] Chr1sG: I’m not sure I fully understand the use case you’re describing. Are you thinking in reference to a particular type of view (Report, Board, Timeline, Table, Document…)? I’m thinking about Table or List view (but I think it applies to any view that can display Fields). [image] Chr1sG: Where do you imagine the user information (Company or Status) would be displayed/presented when viewing a particular set of Feature requests? For example in Table view it would be displayed as a Table column - in the same way Field is normally displayed. The only difference is that the column would not display Field value directly but instead would be computed on the fly from a Formula.

OK, understood. So would it be effectively solved if fields could be hidden in entity view? i.e. you create the formula field you need (in Table view or wherever) and it would be created as a new database field (available in any view) but wouldn’t show up on the entity view UI by default? (or any other view)

For the use case presented here it would be a step forward although I think it’s a bit of a workaround because: over time these ad hoc fields will accumulate and might be tricky to trim them down: “have I created that hidden field or someone else did”, “are those fields used anywhere, which views are using them” users without permissions to edit schema would be still restricted in their ability to experiment

[image] Pawel_Badenski: I think it’s a bit of a workaround Indeed. Quick q: Is your wish that the ad hoc fields should be per-user as well as per-view? Or per-view and available for all users to see?

In my mind it was per-view and available for all users to see (ie fields are subordinate to view in terms of permission, if a user can see the view they can see the fields).

I am 100% with Pawel here. Ad-hoc fields in Rich Text/Docs (or even Whiteboard? :exploding_head:) would be a huge value-add to me. There are zillions of uses I can think of for them. Coda has this, and there are multiple other systems that implement varying degrees of sophistication in similar tools, e.g. Patera: [image] Patera - Dynamic Documents An environment for teams to think, plan, and model scenarios in. By using excel syntax inside documents, teams and individuals can explore possibilities, outcomes and alternatives. It's like a spreadsheet you can read. Now just imagine the examples on that Patera page, but with also the ability to do formulae that connect to Fields/Entities, etc. :rocket:

[image] Oshyan: Ad-hoc fields in Rich Text/Docs (or even Whiteboard? :exploding_head:) would be a huge value-add to me. That’s not quite what he’s asking for, i believe. He has asked for ad-hoc fields in views (table view, list view etc) which is a subtle difference.

Ad hoc formulas in views

Ideas & Features

Matt_Blais May 17, 2023, 10:11pm 17

Topic		Replies	Views
Formula fields that are filtered by the context they're viewed in Ideas & Features	7	211	September 5, 2025
Inline formulas Ideas & Features rich-text	20	668	May 11, 2026
Hide view : filter on view content Ideas & Features	2	56	March 19, 2026
Can't add Formula-type fields to customizable list at top of entity view Ideas & Features	1	224	May 28, 2022
Readonly only formula fields - Add formula to form Ideas & Features	0	198	March 20, 2023

Ad hoc formulas in views

Related topics