You’ve adopted the idea that Airtable is a spreadsheet comprised of static cells and a formula model that is not much different from Google sheets or Excel. In reality, Airtable is quite a departure from that which you assume, and to be fair - it is intentionally different to solve many other data-centric challenges.
The equivalent to lookups and list summations in the world of databases is commonly (and loosely) known as stored procedures; code blocks that perform these types of operations on certain rows. Script blocks and extensions are designed to bridge the gap between database-like platforms and the desire to perform these types of multi-row data aggregations that are so common in the world of spreadsheets.
The irony is that we all want Airtable to be different but exactly the same. :winking_face:
I’ll bet there’s a clever Airtable consultant that can engineer a way to avoid this challenge but still see the exact information you need for reporting.
When users hit the wall with stuff like this, it suggests there’s a corner and you’ve unintentionally painted yourself into it. With a little data modeling and requirements planning, I have a hunch you can avoid this altogether.
