There are many things to consider when building your app, like...

Let's look at how we can create apps that are resource-efficient, easy-to-use, and maintainable.

The amount of fields you use is dependent on the context of the app and its design team.

If you are a seasoned Fulcrum user, or your line of work requires collecting a significant amount of information in a single record, we’d recommend that you limit your app to around 600 fields. We've seen experienced customers build super apps that try to accomplish multiple goals, but this yields apps with over 1,000 fields. While it is technically possible to make an app with up to 1,400 fields, it is usually a sign that the responsibilities of your app could be distributed across multiple apps. This can be done efficiently through record link fields.

If you are newer to Fulcrum, we would recommend limiting the amount of fields to 50. Fulcrum provides many tools to customize your app, but the larger your app is in the beginning, the harder it becomes to test.

In general the lower the number of fields your forms contain, the more performant they will be. This is a serious consideration for your field users as mobile environments have limited computational resources.

Repeatable sections should only be used when you have a finite number of similar, non-recurring data points that you need to log. For example, repeatables are a great option if you want to log the condition of all floors in a specific building. The number of floors is not subject to change, and we should not be going back to the same building to enter a new repeatable child record for the same door since we will edit the existing record. Additionally, we could include another repeatable section in the floors repeatable section if we wanted to log the condition of rooms on each floor.

However if there is a limitless, growing number of data points you need to collect, then record links should be used over repeatable sections. For example, if you have a record where you are collecting information on all plants in a specific garden, where new plants are sprouting up all the time, you will want to include a record link field in the app that logs garden data, with the record link field linking to your plant log app.

One of the major drawbacks of using record link fields instead of repeatables is that reports will not automatically include information on all of the linked records. To mitigate this, you can use the API and QUERY functions in an advanced report to fetch the data you need. This does require some coding knowledge, but you can always reach out to our support team if you need help writing a query, or our professional services team if you want a whole app or report built for you.

Another drawback of record links is that they are unidirectional, meaning that an app that has a record link field will contain references to its linked records, but the linked records will not contain a reference back.

Additionally, you plan on having more than 60 repeatable child records within parent records, you should also consider using record links.

Repeatable sections are a great way to reuse fields to create child records to log a finite amount of similar data. All repeatable data is stored within the root record which can balloon in size. This will cause an increase in record load time and report generation. We recommend limiting the nesting of repeatable sections to the grandchild level in order to prevent this, meaning that at most, a repeatable section can have one more repeatable section inside of it, and that one grandchild repeatable section should not contain any more repeatable sections.

Additionally, importing data into grandchild-level repeatables can get complicated quickly.

If you feel like you do need repeatable sections at the grandchild level and beyond, we would encourage you to look into record link fields. They are links to other apps which can be more convenient to use and will cause less performance-related issues.

The more of these items per record, the longer mobile sync times will be. We’d strongly recommend putting a cap on repeatable child records at 60. We also want to emphasize that the less media in a record, the better. We recommend the amount of media per field at around 5, and no more than 20 media items per record. Note that if you require at least 10 photos in a single field, make the limit for that field 10 instead of making 2 photos fields with a limit of 5. We want to decrease the total number of media items per record, and it doesn’t matter if all media files are separate across multiple fields or all in a single field.

Visibility rules are a great way to prevent overloading your users with information they need to fill out until it becomes necessary, and requirement rules are paramount for collecting the data you absolutely need.

However, when first designing your app, wait until the end of your design phase to set them both up.

This becomes especially relevant when testing calculation fields and data events. Manual testing of apps is necessary, but when your code can only be triggered when several other conditions are met it means that there are several more manual steps involved. For example, if you are testing code that is related to fields inside of a repeatable section, but that section is only visible when conditions X, Y, or Z are met, then we have to fill out those fields every time we test, or set them through code or default values. Another example: if you want to test code that triggers during a save event, but your app has several required fields, then you won’t be able to test your code until all of the fields have been filled out. This results in wasted time spent manually filling out fields or setting up default values / code you will need to remove in the future.

We recommend this limit because every auto-population rule will duplicate data from the linked app. If your users require read-only access to a linked record, they can always tap on the linked record to open up its details as a reference.

This is for both organization and performance reasons. You want the scope of each calculation field to be as focused and small as possible. If you are doing a big calculation and need access to more fields, consider breaking up your calculations into several calculation fields.