Skip to main content
All CollectionsHelp ArticlesForms and RecordsWorking with Forms
Form Creation & Structuring Through the Lens of Data Tables
Form Creation & Structuring Through the Lens of Data Tables

In this guide, we will be thinking about form creation and structuring through the lens of data tables.

Updated over 7 months ago

Every form is represented by a data table in an Apricot database. Every data table has a Row Size Limit of 65,000 bytes. Each field type uses varying amounts of bytes, some have higher impact than others. The more bytes used, the more performance issues we see. As a best practice, forms should be kept under 25,500 bytes.

Rule #1: Forms that require the use of many high impact fields should be broken down into multiple forms.

High Impact Fields 

  • Name  150 bytes

  • Address  100 bytes

  • Address Lookup 1460 bytes

  • Global Address Lookup 612 bytes

  • Radio Button 255 bytes

  • Masked Radio Button  255 bytes 

  • Drop Down 255 bytes

  • Masked Drop Down 255 bytes

  • Attach Doc 278 bytes

  • Signature 242 bytes

  • User System fields (E.G. Mod User, Creation User) - Each form will always have two, this is unavoidable but should still be considered) 255 bytes

Rule #2: You should not exceed 100 fields per form.

Here’s a very important fun fact: Inactive fields still count towards Row Size Limit bytes. As a best practice, you should not exceed 100 fields per form to allow for that form to evolve over time and avoid negatively impacting performance. Our clients do make changes to their forms; they retire fields, they add new ones. We need to consider that upfront during implementation and plan for the long term. 

Form Logic Considerations

Rule #3: Form Logic rules should be consolidated and optimized.

Almost every interaction the user makes with the form triggers form logic rule validation where we need to validate whether or not a form logic condition was met, and if we need to perform a rule action. The more conditions exist, the more checks need to be made per interaction with the form. Each of these validations is a request to our server.

Form logic and field count is a compounding issue for performance. Forms with extensive field counts AND many form logic rules will see performance issues. If rules #1 and #2 are followed, form logic should not be too detrimental to performance. However it’s important to understand the relationship between the two and whenever building out form logic, make sure rules are written well. 

Linking Considerations 

Rule #4: Linking should be kept to a minimum.

Linking is the primary way we build relationships between different forms / content in Apricot. It’s foundational for features like the Registration Grid and for tracking & managing households. Linking can also contribute to performance issues in Apricot. Though it is unavoidable by nature, it’s important to understand the impact links have when building out Apricot form structure. 

Here is a good example of how to keep links to a minimum: 

Often times Wizard Links are used to create workflow for clients. In the case of a form that may be getting too large, it would be best to use the Workflows feature in lieu of Wizard Links to optimize performance of the form.

Did this answer your question?