Ultimate Forms runs in two environments:
- On-premises SharePoint, where it executes directly on your organization's servers
- Microsoft 365, where it runs on shared Azure infrastructure.
The two versions are nearly identical in what they can do. But the Microsoft 365 version operates under constraints that the on-premises version does not. Understanding those constraints helps administrators design their solutions to run reliably, and helps them diagnose issues when something does not behave as expected.
Why Throttling Exists in the Microsoft 365 Version
The Microsoft 365 version of Ultimate Forms uses Azure Functions to execute background processes: Actions, Alerts, Import, Associated Items Summary columns, and Item ID.
Because this infrastructure is shared across all Ultimate Forms customers, a single customer's configuration can in theory consume a disproportionate share of available resources. An action that updates thousands of list items every time it fires, or an import profile that runs continuously at high volume, creates load that can affect the performance of other customers on the same infrastructure. And can also trigger Microsoft's own API throttling mechanisms, which apply rate limits to any application that makes too many requests to SharePoint in a short period.
To prevent both of these problems, Ultimate Forms operates its own throttling layer on top of the standard SharePoint throttling. This monitoring runs constantly, and it applies to actions, alerts, and other components that run in the Microsoft 365 environment.
How Update Rate Monitoring Works
The most common throttling scenario occurs when a large number of list items change in a short time. For example, when a bulk data import creates hundreds of items at once, or when an action running on one list triggers a cascade of updates across other items in the same list.
Every item change in a list that has event-based Ultimate Forms features configured — Actions or Alerts set to fire on item creation or update — generates a function execution request on the Azure infrastructure. When many changes happen within the same minute, the number of concurrent requests can exceed the threshold that ensures stable performance for everyone on the platform.
Ultimate Forms monitors the number of changes occurring in each list per minute. The throttling logic works as follows:
Normal operation — when the number of item changes per minute stays below the threshold (100 changes per call), all events are processed normally.
First overage — Ultimate Forms allows up to twice the normal limit (200 changes). If the count falls between 100 and 200, all changes are still processed, but an exception is registered in the throttling system. If the count exceeds 200, all changes are disregarded and an exception is registered.
Consecutive overages — once the first overage has occurred, any further consecutive spikes result in changes being disregarded immediately, without the doubled allowance.
This logic is designed to tolerate occasional spikes — a bulk operation that completes quickly and then returns to normal — while preventing sustained high-volume usage that would degrade performance for other customers.
What this means for administrators
If you are running a bulk operation — importing data, mass-updating records, or running a script that creates many items at once — and your list has actions or alerts configured to fire on item changes, you may encounter throttling. Items processed while the throttle is active will not trigger those actions or alerts.
The recommended approach for bulk operations is to use Ultimate Forms Bulk Update Mode, which temporarily suspends event processing during large batch updates and re-enables it afterward. This allows the data operation to complete without generating excessive API requests, and without losing any action or alert triggers for items that were individually submitted through normal form use.
How Execution Time Monitoring Works
In addition to update rate monitoring, Ultimate Forms tracks how long each individual action and import profile takes to execute. This is a separate throttling mechanism from the update rate monitor, and it applies regardless of how many changes are happening in the list.
The execution time limit varies by license tier. Larger licenses — covering more users and broader deployment scope — are allocated higher execution time limits. In all cases, the absolute maximum execution time for any single action is 500 seconds. If multiple actions are configured to respond to the same event, the execution time is measured from the moment the first action begins, not individually per action.
What happens when an action exceeds the time limit
When an action runs longer than the permitted execution time, Ultimate Forms triggers an execution error within the action. If the action is configured to write to the Action History log, the error message will read something like "Exceeded maximum allowed execution time."
If the action is in the process of updating multiple list items when it is stopped, the items already updated will retain their changes. The items that had not yet been reached when the action was terminated will not be updated. There is no automatic rollback of changes already made.
This behavior is important to understand because it can produce partially completed results. If an action is updating 500 items and times out at item 320, items 1 through 320 will be updated and items 321 through 500 will not. The action history will show an error, but the list will contain a mix of updated and unupdated items with no automatic indication of which are which.
How to avoid execution time throttling
The most effective approach is to reduce the number of items an action processes in a single execution. Ultimate Forms Actions support conditions that restrict which items are evaluated. Adding a condition that limits the action to items meeting specific criteria — a particular status, a date range, a department, or any other column value — reduces the scope of each execution and the time it takes to complete.
Other approaches include:
Incremental processing — designing actions to process a manageable subset of items per execution rather than attempting to update all qualifying items at once.
Avoiding unnecessary recalculation — if an action performs calculations or lookups for each item it updates, reducing the complexity of those operations can significantly reduce execution time.
Monitoring the Action History — if an action is approaching the execution time limit, this will often be visible as increasing execution times in the Action History log before a timeout error occurs. Monitoring this log proactively allows administrators to adjust the action's scope before the throttle is triggered.
Monitoring Throttling in Your Environment
Ultimate Forms provides an API monitoring page that gives administrators visibility into the volume and rate of SharePoint API requests being made from their environment. This page displays request data by component, by site, and by time — with up to 24 hours of history available — making it straightforward to identify which lists, actions, or import profiles are generating the highest API volume and to assess whether any are approaching throttling thresholds.
This monitoring capability is available in the Ultimate Forms administration area in the Microsoft 365 environment. It is the most direct tool for diagnosing throttling-related issues and for verifying that adjustments made to action configurations have had the intended effect on API usage.
Practical Guidance for Common Scenarios
Running large data migrations — use Bulk Update Mode to suspend event processing during the import, then process any necessary post-import logic as a separate, scoped action run after the migration is complete.
Actions that update many items — add conditions to restrict the action's scope to the minimum set of items that actually need to be updated. Review the Action History log after initial deployment to understand typical execution times before the action is processing real production volume.
Import profiles at high frequency — if an import profile runs pulls large volumes of data, consider whether the data can be filtered at the source to reduce the number of records being imported per run.
Diagnosing unexpected action failures — check the Action History log first. If errors reference execution time or throttling, the API monitoring page will show whether the list was under high request volume when the failure occurred.
A Note on On-Premises Deployments
All of the throttling behavior described in this article applies only to the Microsoft 365 version of Ultimate Forms. The on-premises version — available for SharePoint 2019 and SharePoint Subscription Edition — runs on your organization's own servers and is not subject to these limits. Administrators of on-premises deployments have full control over the server resources available to Ultimate Forms and are not affected by shared infrastructure constraints.
For full documentation on Bulk Update Mode, the Action History log, and the API monitoring page, visit Documentation.
