Asynchronous vs Synchronous SharePoint Actions

Every event-driven action in Ultimate Forms makes one quiet choice: run after the item saves, in the background, or run inside the save itself. Asynchronous is the default and right for almost everything, which is exactly why the synchronous option matters: it is the only way to block a bad save before it happens, the double booking, the duplicate, the forbidden transition, and the only way to make an action's changes part of the same update, with a single version history entry. This guide explains what the setting actually controls, the two cases that justify synchronous execution, and the mistakes the setting invites. For everything else about actions, start with the automation guide.

One save, two moments

The setting only makes sense against how a SharePoint update works. When a user clicks Save, two events fire around the database write: one before the changes are committed, while the update can still be cancelled, and one after, when the new values are fact and nothing can be reverted.

Everything that automates SharePoint lives in one of those two moments. The after moment is spacious: the save already succeeded, the user has moved on, and whatever runs there can take its time. The before moment is cramped and powerful: the user is waiting, the form is open, and code running there can inspect the incoming values, inject changes into the update itself, or refuse it entirely. Traditionally, reaching the before moment required custom event receivers, compiled code, deployed by developers. The Synchronous setting on an action's Advanced tab is that capability as a checkbox.

The setting applies to list-event triggers only: items added or modified; it changes nothing for timers, manual execution, or the other trigger families, which have no save to be inside of.

Asynchronous: the right default

An asynchronous action runs in the after moment, in the background. The form closes, the user proceeds, and the action does its work with no visual indication and no one waiting, which is precisely the correct arrangement for nearly all automation: updating related items, creating sites, generating documents, calling web services, sending notifications. None of these should hold a form hostage, and none of them needs to.

The default comes with one subtlety worth understanding rather than merely trusting. An asynchronous action often finishes by updating the current item, writing a log value, setting a result column, or because it is an Update List Item action aimed at the item itself. That write is a second update, and a second update would normally fire the list's actions again, whose own updates would fire them again, forever. The platform breaks the loop automatically: secondary updates do not re-trigger actions on the same items. You get the convenience of actions that annotate their own trigger item, without the infinite regress that pattern invites in homegrown automation.

So the honest rule is the one the platform's defaults already encode: make every action asynchronous unless you can name the specific reason it cannot be. There are exactly two good reasons.

Reason one: the save that must be stoppable

Some errors are only preventable in the before moment, because they are conflicts with data the form cannot see. The canonical case is the double booking: two users reserve the same room for overlapping hours, each form individually valid, the conflict visible only against the list's current contents at the instant of saving. A synchronous action checks for existing reservations with the same resource and overlapping period, and when it finds one, raises an error on the form and cancels the update. The second booking never becomes an item; the user gets an explanation while their hands are still on the form; and the race between two simultaneous bookers resolves correctly, because the check runs inside each save, against whatever was committed first.

The same mechanics stop duplicates on any natural key, a vendor's tax ID, a serial number, an email, and enforce cross-item rules no column validation can reach, the pattern the real-time validation article covers from the form side and the Calculate Summary action implements: count the conflicting items synchronously, and raise the error when the count is above zero. The Room and Equipment Reservation solution ships this exact approach, installable as a working reference.

Error messages written for this moment deserve the care of any user-facing text: "This room is already booked from 2:00 to 3:30" turns a refusal into guidance, while a generic failure turns it into a support ticket. The user whose save was blocked should finish the sentence knowing what to change, not whom to call.

Reason two: the update that must be one update

The second reason is quieter and bites teams that never saw it coming: version history. An asynchronous action that modifies its own trigger item produces a second update, and therefore a second version, and in audited environments that matters. The record shows two changes, the user's and the system's, where the business sees one event, and every versioned column, flagged alert, and change log doubles its bookkeeping.

A synchronous action resolves this by injecting its changes into the update already in progress. The user's edits and the action's additions, the stamped date, the computed value, the normalized text, commit together, as one update, one version history entry, one change for every downstream consumer to reason about. When a compliance requirement says "the record was modified once," synchronous injection is how configuration honors it.

The cost, and the discipline

Synchronous execution has one price, and it is paid in the user's time: the form waits for the action to finish. That makes the discipline simple. Keep synchronous actions fast and local: a query against a list, a value check, an injected column change. Never put long-running work in the before moment, multi-item updates, site creation, web service calls, document generation, because a slow synchronous action is experienced as a stuck form, and a stuck form is experienced as a broken system. The long work belongs in an asynchronous action triggered by the same event; the two coexist naturally, the synchronous one guarding and shaping the save, the asynchronous one doing the heavy lifting after it.

Two design habits complete the picture. Pair every synchronous guard with narrow conditions, including after-change conditions, so the check runs only on the saves that could conflict, not on every edit of every column. And when a save triggers both kinds, remember the sequence while debugging: the synchronous action already ran when the item lands in the list; the asynchronous ones may still be running when the user asks why the related items have not appeared yet, and Action History shows both with their timestamps.

The setting is one checkbox, but it encodes the two questions every piece of automation should answer: can this work wait until after the save, and may this save proceed at all. Asynchronous for the first, synchronous for the second, and the rare process that needs both gets both.