| 50,000 record fetch limit |
You cannot fetch more than 50,000 records in a single Deluge query. Aggregations on large datasets hit this ceiling. Batch workflows can process records in chunks but have their own fetch limit of 5,000 records per batch operation. |
Design summary/aggregate tables early. Don't plan to calculate totals from raw data at scale. For high-volume processing, batch workflows help manage throughput within the limits. |
| Workflow execution time limits |
Specific timeouts per the platform performance documentation: regular workflows time out at 5 minutes, batch workflows at 1 minute per batch, external API calls at 40 seconds, and record locks at 30 seconds. If a transaction exceeds the time limit, the entire transaction is rolled back. Deluge execution is limited to 5,000–50,000 statements per function depending on your pricing plan. Blueprint changeStage and executeTransition are limited to 50 statements each. Batch workflows help by splitting large datasets into manageable chunks (10–1,000 records per batch) with per-batch rollback on failure — but only one batch workflow can execute concurrently per account, 15 consecutive failures terminates the workflow, and several standard Deluge operations are restricted within batch workflows — aggregate functions except distinct, getUrl/postUrl and client functions are not supported. |
Use batch workflows for high-volume repetitive processing (they can overcome the per-function statement limit). For complex multi-step processes that don't fit the batch model, break into chained stages with a status field to track progress and allow resumption. Minimise external API calls within workflows to avoid holding locks for extended periods. |
| Workflow action call rate limits |
A maximum of 120 workflow action calls per minute per IP address — this includes form on-load scripts, on-user-input scripts, formula expressions, filtered lookups and button clicks. The per-app limit is 250 requests per minute collectively across all users. Portal limit is also 250 per minute collectively. |
Design high-traffic forms with these rate limits in mind. Minimise on-load and on-user-input scripts where possible. For apps accessed by many concurrent users, these limits can be hit faster than expected. |
| Locking, deadlocks and rollback behaviour |
Creator employs record-level locking (30-second timeout) and form-level locking during schema changes. Deadlocks can occur when two workflows update the same records in different order — one workflow will fail. On timeout or script error, data operations within the workflow (record adds, updates, deletes) are rolled back. However, external side effects that already fired — API calls, emails, SMS — cannot be rolled back as they've already been sent. This means a workflow that sends an email in step 2 and fails in step 3 will revert the data changes but the email is already delivered. Batch workflows offer per-batch rollback (a failed batch's data operations are reverted without affecting others). |
Use consistent record update ordering across workflows to avoid deadlocks. Place external actions (API calls, emails) as late as possible in your workflow scripts — after all data operations that might fail. This minimises the risk of sending notifications for data changes that get rolled back. Keep workflows short to minimise lock duration. Refer to the platform performance best practices for optimising execution time. |
| Subform record limits |
Subforms are not designed for hundreds of rows. Performance degrades significantly and there are hard limits on row counts. |
Use related child forms via lookup instead of subforms for anything that could grow beyond ~50 rows. |
| Lookup/dropdown 5,000-choice scroll limit |
In live mode, dropdown, multi-select and lookup field pick lists only display up to 5,000 choices. Beyond that, users must use the search bar. Formula fields also don't reflect changes made in lookup/subform subfields across forms. |
For large reference datasets (e.g. product catalogues, customer lists), plan for the 5,000 display limit from the start. Consider filtered lookups or alternative UX patterns for very large datasets. |
| Form field count limits |
The number of fields per form depends on character limits. At default 255-character single line fields, you're capped at ~60 fields of that type. Reducing character limits increases field count (e.g. 100-char limit allows ~160 choice fields). Max 4 display fields per lookup. |
Design forms with field counts in mind. For complex entities, split across related forms via lookups rather than cramming everything into one form. |
| Report operation limits |
Only 1,000 records can be bulk-selected for edit/duplicate/delete in live mode. When importing with "Execute scripts" enabled, workflows only run for the first 3,000 records. Export limits: 50,000 records max for HTML, PDF and print, 150MB/70MB for XLSX (existing/new users), 12MB and 5-min rendering timeout for PDF. Reports won't load when a subform/multi-select lookup has more than 2,500 values mapped to a record. |
Design for these ceilings when planning data migration, bulk operations and report-based exports. For large imports that need workflow execution, process in batches under 3,000 records or use batch workflows. |
| Grid/spreadsheet report workflow conflicts |
Grid and spreadsheet reports silently fall back to list reports if the underlying form has Deluge scripts in On Edit > On Load or On User Input workflow blocks, or if a lookup field has "Set Filter" configured. This is undocumented in the form workflow setup — you only discover it when the report type changes unexpectedly. |
Be aware of this interaction when adding On Load or On User Input scripts to forms that power grid or spreadsheet reports. Test report rendering after adding these workflow types. |
| Page capabilities and constraints |
Pages have two scripting mechanisms with very different capabilities. Page Scripts (the dedicated feature) are limited: no custom function calls, no write operations, no email/postUrl/openUrl, one script per page, max 50 variables, and scripts can't be shared across pages. However, HTML/ZML Snippets embedded in Pages can execute full Deluge — including data fetching, record manipulation, API calls and function triggers. Other Page-level limits: HTML snippets capped at ~500KB, charts plot only the first 200 data points, and pages containing pivot charts, pivot tables or iframes cannot be exported as PDF. |
Use HTML/ZML snippets for dynamic, data-driven page elements rather than relying on the limited Page Script feature. Be mindful of the performance best practices — Pages are common interaction points for multiple users, so write operations from snippets can cause concurrency issues. For heavy computation, move logic to workflows and display results in Pages. |
| API rate limits |
Integration tasks and external API calls (e.g. invokeUrl to Zoho or third-party APIs) are rate-limited per minute and per day. Heavy integration workflows can exhaust limits quickly. |
Batch API calls where possible. Distinguish between native cross-app functions (no API quota impact) and external API calls (rate-limited) when designing integrations. |
| Connection limits |
In Creator 5, each user is limited to 100 active Zoho OAuth connections — exceeding this silently deactivates the oldest connection. OAuth authorisation is valid for only 90 seconds. Connections invoked within nested functions (functions called inside other functions) are not displayed in the Connections slider or tracked as references. Custom OAuth connectors cannot be imported/exported across data centres. |
Track active connection counts in integration-heavy apps. Be aware of the nested function blind spot — connections used there won't appear in the management UI. For cross-DC deployments, avoid reliance on custom OAuth connectors. |
| Deluge 5MB file handling limit |
Deluge cannot handle files larger than 5MB. This directly impacts document management architecture — you can programmatically upload/download via Deluge to WorkDrive only if files stay under 5MB. Larger files require manual handling or external tooling. |
Factor file sizes into your document architecture early. WorkDrive integration works well for metadata-driven workflows, but automated file processing at scale needs a realistic assessment of what Deluge can actually move. |
| Custom Function size limits |
Individual Deluge functions are limited to approximately 5,000–50,000 statements depending on your pricing plan. You cannot build monolithic utility libraries. Recursive functions are capped at 75 calls. |
Keep functions focused. Accept some duplication rather than trying to build an abstraction layer Creator won't support. Batch workflows can be used to overcome the per-function statement limit for data processing tasks. |
| Cloud function limits |
Cloud functions (Node.js and Java) have a 40-second maximum execution time. A single Deluge transaction can invoke a cloud function no more than 5 times. Cloud functions are not available in CN, JP, CA, SA and UAE data centres. |
Don't rely on cloud functions for heavy orchestration — 5 invocations per transaction is a hard ceiling. Use them for specific compute-heavy tasks that Deluge can't handle efficiently. Check data centre availability before architecting around them. |
| 150-field report export limit |
Duplicating an application or exporting its DS file is not supported when a report displays data from 150 fields or more. This directly affects backup and migration strategies for complex apps. |
Monitor field counts in reports. If approaching 150, split into multiple reports before the limit blocks your ability to export or duplicate the app. |
| Data centre feature availability |
Feature availability varies by data centre. Payment workflows are not available in CN and UAE. Cloud functions are not available in CN, JP, CA, SA and UAE. AI modeler is unavailable in CN, JP, SA and UAE. Zia assistance is restricted in CN, JP, SA and UAE. Only the IN data centre has no feature restrictions. This is a hard constraint you cannot work around. |
Check your account's data centre before architecting around features like payment workflows, cloud functions or AI capabilities. If you're building for a global client base, verify feature availability per DC early. |
| Backup limitations |
Scheduled backups do not include files (images, file uploads, audio, video, signatures) — only immediate backups do. Backup is only available for production environment apps, not development/stage. Compressed size limits apply (meta: 50MB/100MB, data: 1GB, files: 3GB). Restored apps lose shared user access and published components. Backup is not supported for installed apps. Forms with 30+ multi-select/checkbox fields may cause backup failures. |
Don't rely on scheduled backups for file-heavy apps — you'll only get the data, not the files. Build a separate file backup strategy if files are business-critical. Factor environment restrictions into your disaster recovery planning. |
| Audit trail blind spots |
Records updated via Deluge scripts are not captured by the audit trail. Audit data is only retained for 6 months. Several field types are excluded from auditing (subform, rich text, URL, formula, signature, text area, file upload, image, audio, video). Pivot report exports/prints are not logged. |
If compliance or data lineage matters, do not assume the audit trail covers script-driven changes — it doesn't. Build your own logging for automated workflows if you need a complete audit history. Plan for the 6-month retention limit. |
| No interactive debugging |
No breakpoints, no step-through execution, no stack traces. Debugging relies on info statements, runtime error messages with line numbers, and try-catch blocks. Application Logs can surface workflow failures but lack granularity for complex logic debugging. |
Write smaller functions. Log aggressively with info statements. Use try-catch to handle and log expected failure modes. Build admin reports that surface workflow failures from Application Logs. |