SharePoint throttling is one of those problems that tends to surface at the worst possible moment. Approval notifications stop firing. A form submission hangs. An import process that normally completes in seconds takes minutes — or fails entirely. Users report that SharePoint is "slow" or "broken," and the SharePoint administrator has to diagnose a problem that left no obvious trace.
Understanding what throttling is, why it happens, and, crucially, how to identify which part of your environment caused it is an increasingly important skill for any SharePoint administrator. This article covers all three, including a new monitoring capability in Ultimate Forms that gives administrators something they have not had before: a per-minute, per-component view of exactly how many API calls are being made by Ultimate Forms in their environment, and where those calls are coming from.
What Is SharePoint Throttling?
SharePoint Online (like all cloud services) enforces limits on how many API requests can be made within a given time window. These limits exist to protect the service and ensure that no single tenant, application, or user can monopolize shared infrastructure at the expense of others.
When those limits are exceeded, SharePoint begins throttling the requestor. It begins returning HTTP 429 ("Too Many Requests") responses instead of processing the request normally. Well-behaved applications are expected to detect this response, pause, and retry after the period indicated in the response header. Applications that do not handle throttling gracefully may fail silently, produce errors, or simply time out.
Microsoft does not publish exact throttling thresholds, as they vary by tenant size, subscription type, and server load at any given moment. What is known is that limits apply per user, per application, and per site collection. And that hitting them consistently indicates that something in the environment is making more API calls than necessary, or making them too frequently.
What Can Cause Throttling?
Throttling rarely happens without a cause. In environments using automation tools like Ultimate Forms, the most common causes fall into a few predictable categories.
Misconfigured actions
An action configured without appropriate trigger conditions can fire more broadly than intended — executing on every item modification, including modifications made by unrelated processes or by the user correcting a previous submission. At scale, or when multiple users are active simultaneously, an action that fires unnecessarily on each of these events can generate a significant volume of API calls in a short window.
It is worth noting that Ultimate Forms Actions include a built-in tracking mechanism that prevents the most common form of runaway behavior — recursive loops caused by an action modifying the same list it was triggered from. This means an action that updates a column on the same list will not re-trigger itself indefinitely. However, actions that create new items, write to related lists, or trigger cross-site updates do not benefit from this protection, and poorly scoped conditions on these types of actions can still contribute meaningfully to API load.
The most common misconfiguration is an action with no limiting condition — one that fires on every change to a busy list regardless of whether the change is relevant to the action's purpose. Adding a condition that restricts the action to the specific change events it is designed to respond to is usually sufficient to bring the call volume back to an expected level.
Poorly scoped import processes
The Ultimate Forms Import feature can pull data from external sources — email, SQL databases, REST APIs — and create or update SharePoint list items automatically. An import configured to run too frequently, or one that processes a very large number of items per run, can generate a high volume of API calls in a short window.
An import that runs on a large email backlog and processes hundreds of database records at once represents a significant burst of API activity. If the same tenant has multiple imports running on similar schedules, the combined load can easily exceed throttling thresholds during peak overlap periods.
Overly frequent alerts and notifications
Alerts configured to fire on every change to a busy list can generate a large number of notifications in a short period. If each notification involves reading additional list data — to populate the email template with contextual information — the API cost per alert is higher than it might appear. A high-volume list with alerts configured without appropriate conditions can produce significant API load throughout the day.
How Throttling Manifests
Throttling is not always obvious. The most visible symptom is delayed or failed processing — actions that normally fire immediately take minutes or fail without an error message visible to the user. Import processes that normally complete quickly appear to hang. Notifications arrive late or not at all.
At the system level, throttling appears as HTTP 429 responses in application logs. Ultimate Forms components are designed to handle throttling responses gracefully — they detect the 429, back off for the recommended period, and retry. This means the process eventually completes in many cases, but with a delay. In severe throttling scenarios, the retry window may exceed the operation timeout and the process may fail.
The challenge for administrators is that throttling is a symptom, not a diagnosis. Knowing that throttling occurred tells you something is generating too many API calls. It does not tell you which component, which site, or which configuration change caused it.
The Ultimate Forms Throttling Monitor
Ultimate Forms now includes a dedicated monitoring page that gives administrators the visibility they need to diagnose throttling at its source.
The monitoring page shows how many SharePoint API calls each Ultimate Forms component executed, broken down by site and by minute, for any hour within the past 24 hours. The components tracked include Actions, Alerts, Import, Print, Associated Items Summary, Item ID and General (everything else) — every part of the platform that makes API calls in the course of normal operation.
This level of granularity makes it possible to answer questions that were previously difficult or impossible to investigate:
Which component is generating the most API calls? A spike in Actions calls at a specific minute may indicate a misconfiguration. A sustained high volume from Import may indicate a large batch size.
Which site is the source? In environments with many sites, throttling from one site can affect others in the same tenant. The monitor identifies the specific site where the activity is occurring, making it straightforward to narrow the investigation.
When did the spike occur? The per-minute breakdown makes it possible to correlate a throttling event with a specific time — and then cross-reference that time with what was happening in the environment. Did an import run at that minute? Was a bulk update in progress? Did a scheduled action fire?
What changed recently? By comparing API call volumes across different hours or days, administrators can identify whether a recent configuration change has altered the call pattern — a new action, a modified import schedule, or a new alert configuration.
Investigating and Resolving Throttling
When throttling is suspected, the monitoring page is the starting point. The process is straightforward.
Step 1: Identify the spike. Open the monitoring page and select the hour during which throttling was observed or reported. Look for minutes with significantly higher API call volumes than the baseline for that site and time of day.
Step 2: Identify the component. Within the spike period, identify which component accounts for the elevated call volume. A disproportionate volume from Actions suggests a trigger condition issue. A high Import volume suggests an excessive batch size. High Alert volume suggests a notification firing more often than intended.
Step 3: Review the configuration. Navigate to the identified component on the identified site and review its configuration for the patterns described above — overly broad conditions, high-frequency schedules, or unnecessary updates.
Step 4: Make the correction. The fix depends on the root cause identified in the previous step. A misconfigured action firing too broadly is resolved by adding or tightening the trigger condition — restricting it to the specific change events it is designed to respond to. An overly large import is resolved by decreasing the batch size. An alert firing without appropriate conditions is resolved by adding conditions that limit it to the relevant change events.
Step 5: Monitor the result. After making the correction, observe the API call volumes over the following hour to confirm that the spike has been resolved. The per-minute granularity of the monitor makes it easy to see whether the change has had the intended effect.
Prevention Is Better Than Diagnosis
The monitoring page is most valuable as a proactive tool, not just a reactive one. Reviewing API call volumes periodically — before users report a problem — allows administrators to identify components that are trending toward throttling limits and address them before they cause visible impact.
A component that is making a high but not yet excessive number of calls today may exceed the threshold next week when another site is added to the tenant, or when user activity increases during a period of high demand. Identifying and correcting the configuration now costs significantly less than diagnosing a throttling incident after the fact.
Bulk Update Mode: Reducing API Load During Large Operations
When a large number of list items need to be updated in a short time — migrating data, correcting a batch of records, or running a significant import — the actions and alerts configured on that list will fire for each item modification. Even well-configured automation can generate substantial API load when applied to hundreds or thousands of items in rapid succession.
Ultimate Forms includes a Bulk Update Mode that addresses this directly. When enabled on a site, Bulk Update Mode temporarily disables actions and alerts for that site, allowing the bulk operation to complete without triggering the automation layer. Once the operation is complete and Bulk Update Mode is disabled, normal action and alert processing resumes.
This is particularly relevant in two scenarios that commonly contribute to throttling. First, when a large data migration or correction exercise is being performed — importing a historical dataset, bulk-assigning records, or updating a classification column across an entire list. Second, when a misconfigured import or action has already caused a backlog and the administrator needs to correct a large number of affected items without compounding the API load.
SharePoint Throttling Is Manageable
Throttling is not a sign that something is fundamentally wrong with a SharePoint environment. It is a signal that one or more components are making more API calls than necessary — usually because of a configuration that can be corrected in minutes once it is identified.
The Ultimate Forms throttling monitor provides the visibility that has been missing from this diagnostic process. Rather than working backwards from a symptom, administrators can now work forwards from the data — identifying the specific site, component, and time window where the problem originated, and resolving it with confidence.
