To ensure consistent performance, stability, and scalability across the platform, Quixy enforces a set of Platform Governance Limits. These upper-limit values are carefully derived from years of historical data, best-practice implementations, performance benchmarks, and the analysis of poor-performing applications.
By enforcing these boundaries, the platform ensures that citizen developers build applications in an optimized, modular, and scalable manner—without overloading compute resources or creating monolithic, unmaintainable solutions.
Important
Governance limits are introduced with a clear purpose: to guide citizen developers toward responsible, efficient design practices. These limits act as protective rails that:
- Developers must follow best practices and avoid unnecessarily large or complex structures.
- Controlled use of resources reduces compute overload and enhances the overall responsiveness of applications.
- Breaking larger processes into micro-applications increases scalability, maintainability, and clarity of execution.
- Limits prevent accidental misuse, over-configuration, and inefficient workflows.
Upper-limit enforcement is a standard practice across the technology industry.
For example, Oracle Database defines strict upper limits on tables, fields, functions, and storage blocks. This compels developers to architect efficiently while also protecting the system from resource-heavy designs.
Similarly, Quixy applies these governance limits to help maintain a healthy platform ecosystem for every customer, regardless of scale.
The following sections detail the upper limits defined across platform components.
| # | Type of Limit | Limitation |
|---|---|---|
| 1 | Sections in an App | 50 |
| 2 | Form fields in each App Section | 100 |
| 3 | Form fields in each App Grid | 50 |
| 4 | Business Rules in an App | 500 |
| 5 | Validations in an App | 500 |
| 6 | Conditions per Business Rule | 30 |
| 7 | Actions per Business Rule | 30 |
| 8 | Validations per Business Rule | 20 |
| 9 | Workflow Steps in an App | 100 |
| 10 | Workflow Step – Actions | 10 |
| 11 | App Data Functions in an App | 200 |
| 12 | App Data Functions per Step | 40 |
| 13 | Triggers in an App | 200 |
| 14 | Triggers per Step | 20 |
| 15 | User Functions in an App | 10 |
| 16 | Notifications in an App | 100 |
| 17 | Notifications per Step | 10 |
| 18 | External APIs in an App | 100 |
| 19 | External APIs per Step | 10 |
| 20 | Quick Flows in an App | 100 |
| 21 | Quick Flow per Step | 10 |
| 22 | App Reports in an App | 50 |
| # | Type of Limit | Limitation |
|---|---|---|
| 1 | Data Functions in each Data Table | 50 |
| 2 | Fields in each Data Table | 200 |
| # | Type of Limit | Limitation |
|---|---|---|
| 1 | Data Tables in each Data Source | 20 |
| 2 | Permitted Data Fields per Data Source (Selected elements) | 150 |
| # | Type of Limit | Limitation |
|---|---|---|
| 1 | Permitted Data Fields per Report | 100 |
| 2 | Custom Views per Report | 30 |
| # | Type of Limit | Limitation |
|---|---|---|
| 1 | Permitted Data Fields in each View | 100 |
| 2 | Permitted Actions in each View | 50 |
| 3 | Custom Views in each View | 30 |
| # | Type of Limit | Limitation |
|---|---|---|
| 1 | Static Fields in each Add-on | 50 |