While Fulcrum is built for both small and enterprise organizations, all software has its limits. If a user is experiencing performance issues with Fulcrum, it may help to know where they fall on the limit scale of Fulcrum.
Web: When over 1000 apps in an account, certain app-related pages start to take longer to load. Usually only for the owners or managers that have access. Standard users typically only have access to a portion of those apps, so they are unaffected.
Mobile: Sync times, especially initial syncs, can begin to take over 30 seconds when syncing hundreds of apps.
With each repeatable section added to an app, a new relational database is created for the "child records." Each new child record will be attached to the parent record. While it is possible to add child, grandchild, and even great-grandchild repeatable sections nested inside of each other, users may find using this app to be time-consuming. The length of time it takes to sync may also begin to increase when there are dozens of repeatable sections in one app.
Further, as more and more child records are added to one parent level, the size of the record increases. When a user syncs, the entire record payload is sent to our servers, including parent and child data. When the number of child records reaches a certain point (usually thousands), syncs can take a significant amount of time to complete, or, if paired with a weaker internet connection, can timeout, causing the sync to fail. A limit to the number of records created in a repeatable section can be added in the app designer to avoid this.
There are no set limits to the number of records in an account or app. Dozens of customers with over a million records in their account with no slowness in syncing. When you have apps with over 100,000 records, the initial mobile sync time can take a few minutes. However, additional syncs will only exchange new, edited, and deleted records and should be faster. These are referred to as changesets. Regular syncs do not exchange all records, so it should be quick regardless of how many records are in the app and account.
When there is a high density of records on the map view, the browser can take longer than average to load the pin/dots on the map. The tile server API can lag when records are high in density.
The importer can only import 10,000 records at one time. If you import via the API, there is a limit of 5,000 requests an hour.
It is strongly recommended to import a couple of records to learn the importer before importing a large volume of records. At this time, there is no way to mass delete in Fulcrum.
There is no limit to media storage. There are media packages that come with each plan (not per user) - 20GB (Essentials), 100GB (Professional), 1000GB (Enterprise). Still, many customers exceed these amounts, and we offer expansion on plans if needed.
There is a limit of 100 files per app. Reference files are accessible offline; the documents are synced locally to the mobile device, making initial sync time lengthy depending on file count and file sizes.
There are no set limits to how many users can be on an account. We have customers with thousands of users with no degradation to sync time or slowness in operation. We know that managing accounts with hundreds of users can become tedious, and we are considering solutions to this challenging operation.
There is a set limit of 1,400 fields allowed on an app. PostgreSQL has the limit, and Fulcrum uses PostgreSQL to store your data.
MBTiles are downloaded to the mobile device in order to be used on the mobile device. There is no limit on the size of MBTiles, but the larger it is, the longer it will take to download to the mobile devices.
Issues generating a PDF report have been seen with records of a rather large size (tons of photos and child records). The report builder engine includes a timeout limit of 30 seconds. If a record takes longer than 30 seconds to render and print, an error message will show on the output.