Cool! I'll add one more thought that I think might be particularly useful
> Granular permissions not only at row level but field level too. You can share parts of data with others for editing or have it view-only with ability for commenting and accepting suggestions
In my org (and I suspect many), many of the Sales/Operations people maintain Google Sheets with links into our internal apps. Generally it's TODO lists or other little organizational/workflow type stuff
What I think makes Airtable so powerful is that foreign-keys are first class. You can create a table and include references to rows from other tables. This allows the end user to create tables to support their workflows directly in the same tool they use to manage the data, and means I don't have to build that same functionality into the CRUD app (and until you're deep in a workflow it's hard to get it perfect, so there's always back-and-forth).
A good permission system would allow me to create a set of "core tables" that I tightly control the schema of, but allow others to still create tables which reference this one.
I'm interested in link density and diversity in those little workflow supporting spreadsheets you mention.
Do you have some examples?
We're building a sort of highly linkable (cell level) spreadsheet-type widget builder that is supposed to play nicely with existing workflows (instead of trying to force people to build out entire workflows like many of these new breed of "CRUD-replacer" low-code/no-code apps seem to want us to do). Might interest you!
I can't share anything directly but let me describe a little scenario for you that's close enough:
We have a CRUD app that acts as a CMS with all our product listings in it. There is a team of people who are tasked with curating and maintaining these product listings. So you can go to crud.com/admin/product/<id> and modify the listing, which needs to happen every now and then.
The team of people who maintain these product listings need to coordinate their efforts and so when they need to modify some set of the products they create a spreadsheet with (product_id, link_to_crud.com, Person who is responsible, status). Maybe there's some approval process or multiple statuses or something like that that makes this all a little more custom/complex. Maybe they need to update a few things across services at the same-ish time so there might be a few links per row but it's going to be relatively bounded by what a human can handle.
If our data lived in Airtable, it'd be really easy for this team to make their tables/spreadsheets with direct relations to our core tables (which replace the CRUD app in this case). That team understands their workflows better than I ever will as an engineer. Giving them the power to create their own workflow tools is way better than trying to have engineering build it for them, and that's going to be a huge selling point for me.
I don't think we'd need cell-level links but rather row-level. Right now they use Google sheets, but a more domain-specific tool would be better.
That makes total sense. Yeah you want to see tables with relationships/hyperlink to other tables. Deffo don’t want to be manually joining ids everytime.
It's more than that though, it's that I need to be able to create "core tables" that only privileged users can modify the schema of, but then let anyone create tables with relationships to those core tables.
> Granular permissions not only at row level but field level too. You can share parts of data with others for editing or have it view-only with ability for commenting and accepting suggestions
In my org (and I suspect many), many of the Sales/Operations people maintain Google Sheets with links into our internal apps. Generally it's TODO lists or other little organizational/workflow type stuff
What I think makes Airtable so powerful is that foreign-keys are first class. You can create a table and include references to rows from other tables. This allows the end user to create tables to support their workflows directly in the same tool they use to manage the data, and means I don't have to build that same functionality into the CRUD app (and until you're deep in a workflow it's hard to get it perfect, so there's always back-and-forth).
A good permission system would allow me to create a set of "core tables" that I tightly control the schema of, but allow others to still create tables which reference this one.