Base design when form requires more than 500 fields

Topic Labels: Base design
744 1
Showing results for 
Search instead for 
Did you mean: 
7 - App Architect
7 - App Architect


So I’m working on system for a client and could use some help with designing the base required. It turns out that the client’s intake form is a long complicated form and when I counted all the questions in the form, which will eventually need to be fields in Airtable, it turns out to be 530+ fields. Not to mention that even if I could reduce the form fields down to just under 500 to stay within the field limit, I’d still not have enough additional fields to hold calculations, formulas, status tags, etc.

It’s unlikely that the form fields can be reduced as these are legal immigration forms and require the submitter to provide a great deal of information. The form however is going to be created using Paperform so we’ll not be using Airtable to build the form itself, but the intent was to use Airtable to store the form data. How would I go about this given the 500 field limit?

One thought that came to mind would be to break up the form into multiple forms, so a stage 1 form, stage 2 form, etc. Then the results from stage 1 could be stored in a stage 1 table, stage 2 in a stage 2 table and so on, and somewhere each of these tables link to the name/email of the submitter as the common key linked field.


Something tells me that this may not be the best approach as we’ll end up having the submitter’s information split across tables. Maybe that’s not a bad thing given that the design should be normalized anyway. Either way, I can’t think of any better approach so am looking for advice on (a) whether this is a good/bad approach and (b) if there’s a completely different approach that I could use.

Also, it would be better if there were just one form and the fields 1-265 go to table A and fields from 266-530 go to table B – but I’m not sure that’s even possible.

Thanks in advance.

1 Reply 1
8 - Airtable Astronomer
8 - Airtable Astronomer

I am not sure there is an easy / better answer but I would maybe probe to see if

  1. we are really finding out 500 things about the same concept / object / Table or whether there is potential for splitting into some related entities - particularly master detail relationships

  2. whether there is scope for multiple select columns / fields rather than individual fields

But if you are satisfied all the data is needed and the data structure is right then it may be that Airtable is not the right tool