How QCFUM Created-User, Destination-Group, Profile, and Invite-Pack Limits Work
QCFUM applies four important numeric allowances to delegated onboarding: users created by each frontend creator, destination groups in a User Type Profile, active Profiles available to the tier, and active Invite Packs available to the tier.
The limits are evaluated from the current Effective tier. Downgrading does not delete saved QCFUM configuration.
Current Limits
| Tier | Created users | Destination groups | Profiles | Invite Packs |
|---|---|---|---|---|
| Basic | 10 per frontend creator | 1 per Profile | 1 | 1 |
| Pro | 100 per frontend creator | 5 per Profile | 10 | 10 |
| Max / All Access | Unlimited | Unlimited | Unlimited | Unlimited |
Created-User Allowance Is Per Frontend Creator
QCFUM counts rows attributed to the acting frontend creator whose onboarding status is active, pending, or invited. When a positive tier limit is reached, that creator cannot create another user through the governed QCFUM creation path until the count is again within allowance or the Effective tier changes.
This is not a limit on the total number of Joomla users on the site. It is a QCFUM delegated-creation allowance tied to the creator.
Destination Groups Are Checked When a Profile Is Saved or Used
A Profile can target only the number of approved Joomla destination groups allowed by the tier. Basic allows one; Pro allows five; Max/All Access are unlimited. The groups must also pass QCFUM's protection rules—an available numeric slot never authorizes an administrative/protected destination.
Profiles and Invite Packs Use Deterministic Allowances
When a finite tier is active, QCFUM loads the allowed published Profile/Invite Pack records in ascending record-ID order. Basic can use the first included record; Pro can use the first ten. Max/All Access do not impose a numeric record limit.
Creating and deleting extra Profiles/Packs is a Pro-or-higher management capability, while Basic can still use/edit its included record.
What Happens After a Downgrade
QCFUM does not delete the extra rows. Records outside the current allowance remain stored so they can become available again after entitlement returns. This same preservation-first principle applies to other premium settings such as HTML email and Custom CSS.
Verify the Limit You Are Troubleshooting
- Check Status for the current Effective tier.
- Identify the exact frontend creator when a created-user limit is reported.
- Check the Profile's direct destination groups separately from inherited Joomla visibility.
- For a Profile/Pack that appears missing after downgrade, confirm whether it is simply outside the current tier allowance before editing or deleting data.
Community Discussion
Want to compare Joomla user-onboarding workflows, share practical QCFUM tips, or discuss how other administrators use this feature? Visit the QC Frontend User Manager Community. For private support, bug reports, account-specific entitlement problems, or feature requests, use the QuantaCade support system.