Limits
Nintex Automation Cloud has the following limits to maximize stability and performance. Limit levels are significantly higher than typical usage for most customers. If you anticipate exceeding the limits, reach out to your account manager to discuss alternative solutions or best practices.
Jump to:
User and authentication limits
| Product area | Functionality | Value | Details |
|---|---|---|---|
| Platform | Custom domains in an organization | 150 | The number includes both verified and pending domains. |
| Platform | Groups in a tenant | 200 | The maximum number of groups that can be created per tenant. |
| Platform | Groups in a tenant that a user can be a member of | 20 | The maximum number of groups a user can be a member of in one tenant. |
| Platform | Client applications per tenant | 200 | The maximum number of apps that can be created per tenant. |
| Platform | Personal access tokens per tenant | 200 | The maximum number of personal access tokens that can be created per tenant. |
Xtensions and connections limits
| Product area | Functionality | Value | Details |
|---|---|---|---|
| Xtensions | Connections per tenant | 1,000 | The maximum number of connections that can be created for a tenant. |
| Xtensions | Data sources in a tenant | 200 | The maximum number of data sources that can be created per tenant. |
Forms limits
| Product area | Functionality | Value | Details |
|---|---|---|---|
| Runtime | Total file upload size across all upload controls | 625 MB |
The maximum combined size of all files uploaded to file upload controls in a form. Up to 25 MB per file. Up to 25 files. |
| Designer | Controls in a design | 1,500 | The maximum number of form controls that can be in a form design. |
| Designer | Maximum number of pages | 10 | The maximum number of pages that can be in a form. |
| Designer | Maximum number of rules | 500 | The maximum number of rules that can be in a form. |
| Designer | Maximum number of variables | 500 | The maximum number of variables that can be in a form. |
| Designer | Maximum number of rows in a repeating section | 50 | The maximum number of rows that can be in a repeating section in a form. |
Workflow limits
| Product area | Functionality | Value | Details |
|---|---|---|---|
| Engine | Maximum iterations of a loop | 1,000 | The maximum number of iterations in a loop. |
| Engine | Maximum duration of a workflow | 1 year | The maximum duration the workflow can be in progress. |
| Engine | Action executions | 10,000 | The maximum number of action executions in a workflow. This is not the number of actions, but the number of action executions. For example, a single loop action with 100 iterations would result in 100 action executions. |
| Engine | Workflow payload size | 500 MB | The amount of stored data generated by the workflow. For example, a workflow stores generated output data objects — through actions like querying a list — to be used throughout the workflow. |
| Engine | Workflow variable size | 100 MB | The maximum size of all variables in a workflow. If a workflow contains variables totaling in excess of this value, it will terminate. |
| Send an email action | Maximum size of email | 30 MB | The total size of the email body content and attachments. |
| Workflow design | Workflow definition size | 20 MB | The total size of the workflow definition, including all action configuration and forms that are part of the workflow. Users cannot save or publish workflows if the limit is exceeded. |
| Start Workflow Events | SaaS provider with polling | 5 minutes | If webhooks are not supported, the event manager will poll to the SaaS provider at the end of every 5 minutes. |
| Emails | Send an email and Assign a task to multiple users actions | 30,000 / day | The maximum number of emails that can be sent per day from Send an email or Assign a task to multiple users. |
Start workflow limits
| Product area | Functionality | Value (Standard and Trial) | Value (Enterprise) | Details |
|---|---|---|---|---|
| Engine | Maximum number of workflow starts (includes calls to component workflows) | 1,000 / hour | 10,000 / hour | The maximum number of triggered workflows that can start per hour. Once the limit is reached, event-triggered workflows are queued and retried in the next hour (resume events are excluded from this limit), and no new externally-started* workflows can start until the next hour. The returned header message will provide the time after which the workflows can be retried. |
* An externally-started workflow is one for which the start is triggered by another workflow or an NWC API call.
Tasks limits
| Product area | Functionality | Value | Details |
|---|---|---|---|
| Tasks | Maximum duration of a task | 1 year | The maximum duration of a task. |
Storage limits
| Product area | Functionality | Value | Details |
|---|---|---|---|
| Tenant data storage | Workflow instance files | 10 GB (10000 MB) / tenant | Used for storage of files for workflow execution when the File upload storage setting is set to Indefinite. |
Table limits
| Product area | Functionality | Value | Details |
|---|---|---|---|
| Tables | Tables per tenant | 50 | The maximum number of tables that can be created per tenant. |
| Tables | Columns per table | 25 | The maximum number of columns per table. |
| Tables | Rows per table | 10000 | The maximum number of rows per table. |
| Tables | Text column character limit | 500 | The maximum number of characters that can be entered in a column of type Text. |
| Tables | Rows returned by Query a table action | 1000 | The maximum number of rows returned by the Query a table action (for the Beta release). |
| Tables | Maximum number of requests | 600 |
The maximum number of table requests that can be executed in 1 minute. To change this limit for your tenant, contact customer support. |
Workflow throttling
Throttling is common in cloud services and follows the principle that when a resource is requested too many times in a defined period, future requests will be throttled (slowed) or denied (terminated) to ensure other users get fair access to the resource. It is enacted by a third-party application (like SharePoint or Salesforce) due to high tenant usage and can often result in error 429. Throttling may occur if any of the limits noted above are exceeded. While this is uncommon, the following best practices can help to prevent workflow throttling.
Add specific workflow start event conditions
Your workflow might be triggered to start every time an item is modified, which can cause a lot of starts depending on the volume of data and how frequently items are changed. If your workflow only needs to run when certain conditions are met for item modifications, you can add those conditions into the trigger conditions of the workflow.
Stagger or reduce the number of workflow starts per hour
Consider staggering major events within your organization to spread out or normalize the workflow starts. For example, if all employees will be required to fill out a form, send the form to groups of employees at different hours throughout the day or after business hours so that not all employees will fill out the form in the same hour. If using the Nintex Automation Cloud API, reduce the number of starts per hour via the Nintex Automation Cloud API.
Reduce the frequency of your workflow starts
Consider reducing the frequency of workflow starts by scheduling them based on conditions. For example, if you have a non-critical or non-urgent workflow which runs whenever an item is modified, you can instead schedule the workflow to run during low traffic times (such as after business hours) if you update it to first query your list for all modified items since the last scheduled workflow run.
Reduce loops or add a pause
If calling component workflows within your main workflow (a call to a component workflow counts as a workflow start), reduce the number of loops as much as possible to reduce the number of starts, and add a Pause for duration action to the workflow after approximately 20 iterations (this number can vary). Add the Pause for duration action inside of a conditional Run if true action within the loop. (For example, after every 20 iterations of the loop, the workflow will pause for 1 minute.)
Avoid looping workflow start events.
More best practices for workflow design
Some additional best practices can be employed to optimize your workflows for their best performance.
Reduce the number of actions per workflow
If a workflow design has a lot of actions, break the workflow into smaller component workflows, and call these component workflows using the Call a workflow action. Most workflows have logical breakpoints within the design where a split can be made. Common breakpoints where a workflow can be broken down include:
-
Within a Branch by stage or Run parallel paths action: Each branch can function as a component workflow.
-
After conditional checks: Based on the outcome of the condition, the main workflow may start one component workflow or another.
Look for opportunities to create component workflows where reusable patterns or processes are repeated within multiple workflows. For more information, see Nintex - Component workflow.
Reduce the number of loops and iterations
If loop actions are being used within a workflow design, optimize the workflow by reducing the number of loops and/or iterations within the loops to the absolute minimum.
Add a pause to long workflow loops
If loop actions are being used within a workflow design, add a Pause for duration action to the workflow after approximately 20 iterations (this number can vary). Add the Pause for duration action inside of a conditional Run if true action within the loop. For example, after every 20 iterations of the loop, the workflow will pause for 1 minute.
Reduce the workflow payload size
If a workflow has a large payload size, reduce the payload size by following these best practices:
-
Reduce the output size for queries and/or web service calls. For example, in a Query a list action, you can reduce the size of the query or retrieve the minimum number of records needed instead of the full data set/object. You can reduce the size of the query by using And conditions to only retrieve the applicable records.
-
Reduce the number of query and/or web service actions that retrieve a high number of records.
-
Use fewer branches or nested branches, in addition to the two points above. Design a sequential workflow, if an available option.
-
Use loops with fewer actions that retrieve a high number of records (see the first two points).
-
If multiple unique workflows can be created, break the workflow into separate and unique workflows.
-
Refer to your third-party application's help for guidance on reducing payload size.