📏 Capacity and System Limits ​
Autologyx is designed for enterprise-scale workloads, but like every well-engineered platform, it operates within defined limits.
That is not unusual — in fact, limits are a healthy part of system design. Databases, APIs, storage engines, browsers, operating systems, and even office buildings all have limits. The important question is not whether limits exist, but whether they are practical, well understood, and appropriate for real-world use. In Autologyx, many limits are set at levels that support large-scale operational use, and some can be increased on request where there is a justified need.
This page summarises the standard platform limits currently documented for Autologyx. These limits are useful for:
- understanding the default operating boundaries of the platform
- planning solution design and data architecture
- sizing test data for performance and scale testing
- identifying areas where a higher threshold may be needed for a specific implementation
INFO
A * next to a limit indicates that it is system-imposed by default and may be possible to increase on request, subject to technical review and suitability.
Why limits matter ​
System limits are not just technical constraints — they are also design signals.
They help solution designers, implementation teams, and testers understand the scale assumptions under which the platform is expected to operate. In practical terms, this means they give you useful parameters for:
- designing object models
- structuring forms and permissions
- planning operational scale
- testing realistic data volumes
- understanding when a solution is moving beyond standard operating assumptions
Just as importantly, published limits help customers and internal teams distinguish between:
- what is supported as standard
- what is configurable or extendable
- what may require architectural review before scaling further
What “enterprise scale” looks like in practice ​
The standard Autologyx limits are already large enough to support substantial enterprise workloads.
For example, a transaction review or claims-handling solution might include:
- hundreds of Object Classes covering customers, matters, transactions, claims, documents, audit events, exceptions, and decisions
- thousands of Object class fields across those classes to model operational, financial, regulatory, and workflow data
- millions of Object Records in active use
- hundreds of users working across teams, Roles, and permission models
- large numbers of Task Templates, Task Group Templates, and sequences supporting operational automation
- high-volume document generation and structured JSON fields for integration payloads or case metadata
A banking transaction review solution, for example, could realistically operate with millions of transaction records, thousands of fields across related object models, large review teams, extensive automation, and fine-grained permission control — all within the normal design intent of the platform.
Similarly, a claims or settlement platform might maintain very large case volumes, many Document Templates, multiple User Groups and Roles, and complex process automation while still remaining within standard platform boundaries.
The key point is that these limits are not “small application” limits. They are intended to support enterprise use. Where an implementation expects to push beyond a standard threshold, that should usually be treated as a solution design and scaling conversation rather than a sign that the platform is unsuitable.
Standard limits ​
| Resource | Limit |
|---|---|
| Number of Object Classes | 10,000 |
| Number of Object class fields in an Object Class | 2,000 |
| Number of Object Records in an Object Class* | 5,000,000 |
| Total number of Object Records | 5,000,000,000 |
| Number of owners of an individual Object Class* | 100 |
| Number of owners of an individual Object Record* | 100 |
| Number of class permission sets defined for an individual Object Class* | 10 |
| Number of assignees for an individual class permission set* | 100 |
| Number of record permission sets defined for an individual Object Class* | 10 |
| Number of assignees for an individual record permission set* | 100 |
| Number of Task Group Templates | 10,000 |
| Number of Task Templates | 10,000 |
| Number of Task Templates in a Task Group Template | TBC |
| Number of fields in a task form | 2,000 |
| Number of Sequences | 1,000 |
| Number of Users (1TC / System users)* | 1,000,000 |
| Number of User Groups | 1,000 |
| Number of members in a single User Group | 1,000,000 |
| Number of owners of an individual User Group* | 10 |
| Number of Roles | 5,000 |
| Number of Roles per User* | 25 |
| Number of SSO configurations | 25 |
| Number of Authentication Objects* | 100 |
| Number of characters in an Object class field label | 100 |
| Number of characters in an Object class field alias | 50 |
| Number of options in an Object class field of type single/multi select* | 100 |
| Number of standalone forms in an Object Class | 100 |
| Number of components (fields, properties, instructions) in a standalone form | 200 |
| Number of fields in an Object Class create/edit record form | 200 |
| Number of sections in an Object Class create/edit record form | 100 |
| Number of Document Templates within an Object Class | 1,000 |
| Maximum characters in a JSON field | 250,000 |
Interpreting these limits ​
A limit is not always a target.
In many solutions, it is good practice to stay comfortably below a maximum where possible, especially in areas such as:
- form complexity
- very large select-option sets
- very large numbers of permissions or roles assigned to one user
- extremely large record counts concentrated in a single class
This does not mean those upper limits are not valid. It simply means that good solution design still matters. The best implementations combine platform capacity with sensible modelling, clean automation, and appropriate operational partitioning.
When to ask for more ​
Some limits are marked with * because they are imposed as standard platform thresholds and may be adjustable on request.
Where a project expects to exceed one of those limits, the right next step is usually to review:
- the use case and business need
- expected data growth and user growth
- performance implications
- operational and support considerations
- whether an increase is the right answer, or whether a different design approach would be better
Notes ​
TIP
When performance or scale testing a solution, it is usually more useful to model realistic operational behaviour than to test only theoretical maxima. A well-designed test with millions of representative records, realistic user concurrency, and production-like workflow behaviour will tell you more than a synthetic test that only tries to hit a numeric ceiling.
WARNING
The values on this page describe currently documented standard limits. They should be treated as implementation guidance, not as a substitute for architecture review where unusually high scale, unusual data shapes, or non-standard usage patterns are expected.