All Collections
App Design
App Design Best Practices for Performance, Usability and Maintainability
App Design Best Practices for Performance, Usability and Maintainability
Vince Lauffer avatar
Written by Vince Lauffer
Updated over a week ago

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

  • How many fields should I have?

  • Will my teammates be able to easily use the app I have created?

  • How much information do I want in a single record, and can responsibilities be distributed across multiple apps?

  • How easily can other members of my team edit the apps I create?

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

This is a series of general guidelines. As you build out your app, you may need to bend or break some of these rules. Please do so, but at your own risk. Regardless of which rules you follow or break, the definitive way to know if your app is ready for production is to test it. Interactions between fields can be complex and result in unexpected behavior, so make sure to test on the web and mobile apps!

Limit the amount of fields

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.

When to use repeatable sections vs record link fields

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.

Limit the depth of nested repeatable sections to two levels

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.

Set a maximum number of items per field (relevant to repeatable sections, photos, videos, audio, attachments, record link)

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.

During the initial development of your app, do not use visibility rules or requirement rules (manual or conditional) for your fields

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.

Limit the auto-population rules of record link fields to under 5

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.

Limit the amount of field references in a calculation field to 5

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.

Some other things to consider:

  • If you need the same visibility rules on multiple fields, apply the rule to a single section field, and put all of the other fields into the section

  • Limit data events scripts to under 600 lines, and do not repeat the same ON events

  • Limit calculation fields to under 100 lines

  • Always include comments for any code that is not self-explanatory

  • Limit amount of media fields to under 10

  • Include labels and description fields whenever your users require additional information in order to help them understand how to use your app

  • Use text validation to limit the characters of a text field value

  • If you would like an app built for you, reach out to our Professional Services team. In order to get in contact with them, please contact your account executive

Did this answer your question?