Limits of Confiforms Tables

Question

Dear Confiforms-Users,

we have been facing some trouble with one of our SaaS providers and must now move our registration form from their System to Confiforms. We expect about 4.000 users (known in advance) that must register for roughly 1.100 events within 40 tracks. Workflow is as follows:

User shows interest for track → Sees list of possible events in this track → Selects one or more events from the list → Registers for participation → Gets email confirming registration.

We assume around 15.000 - 20.000 registrations all together. Can we handle this with the normal Confiforms tables? Or do we need an underlying database? Or is it impossible at all to do with Confiforms due to sizing constraints?

Any help greatly appreciated

Peter

Alex Medved {ConfiForms} · Answer

There are no limits on the number of records you can store in ConfiForms forms, but a lot depends on what you want to do with that data - showing 20000 registrations on one screen (in an html table) might be not the best user experience. But still is possible if you want to (on cloud there is a limit of 25 seconds per function execution in forge, and if you are storing data not in a native ConfiForms storage then this might be a blocker, as it is pretty slow. On DC or with a native ConfiForms storage on cloud - should be OK) :)

Arkadiusz Wroblewski · Answer

Hello Peter

One more thing to consider what i think now…. ConfiForms uses Confluence permissions, so access for 4,000 participants needs checking.

Also test simultaneous registrations and duplicate bookings.

Rest, @Germán Morales covered pretty well so have nothing to add :)

Best,

Arek🤠🧙‍♂️

Germán Morales · Answer

Hi Peter, 15,000 to 20,000 registrations is fine for regular ConfiForms forms, so you shouldn't need a database behind it. The ConfiForms team has explained that since version 2 there's no limit on how much data a form can store, and every record is saved separately (see their answer here).

What does slow things down is showing too much at once. A TableView that renders every registration on one page will struggle, which is why I'd build the setup around small views:

* Keep events and registrations in two separate forms, with one registration record per user and event.
* Show only the events of the track the user picked, not all 1,100.
* Turn on pagination in any TableView that lists registrations.
* Send the confirmation email from an IFTTT rule on the onCreated event.

That answer from the vendor is a few years old, so I'd ask Alex Medved ConfiForms to confirm it for your hosting type (Cloud or Data Center), and load a test copy with a few thousand dummy entries before you open registration.