Deep Dive - asynchronous vs synchronous actions in Smart Action Pro | Infowise

Hello,

Today I would like to talk about the different ways in which actions in Smart Action Pro can be executed. There are 3 different types of triggers that would cause actions to run:

1. List events - triggered when items are added, modified, deleted, or, in the newer versions, checked-in/out, moved or attachments added/deleted.
2. Timer - based on any date column within the item (e.g. "2 days before Due Date") or daily/weekly/monthly at a predefined hour.
3. Manual - by clicking on the execution column, or, in SharePoint 2010/2013 ribbon/context menu button.

You can even combine #1 and #2, having the same actions both respond to events and run on timer.

If you switch to the Advanced Settings tab of the action, you will notice that you can set an action to run synchronously. By default, actions run asynchronously; also, this setting only matters for event-based action, it does not change anything for timer-based or manual actions.

To understand what this setting means, let's explore how SharePoint updates work. When you add/edit your list item and click on Save, there are two events being triggered, one before and one after the actual database update. The Before event (such as "ItemAdding") happens before anything is actually written to the database, you even have the ability to cancel the update at this stage. The After event (such as "ItemAdded") happens after the update, so there is no way of reverting the change at this point.

When you set your action to run asynchronously (which is the default), it will continue running in the background even after the triggering form has closed (if it takes that long that is), it causes no visual delay to the user and is basically unnoticeable. So it's great for any long running operations, such as updating multiple items, creating sites or calling web services. Bear in mind though, that asynchronous action might still need to update the current item when done. Such update could be logging the execution result (which you can actually turn off, but it's on by default) or, if configured so, modify the current item. This second update can still be picked up by other actions set to respond to this event type, which could cause additional actions to run. You should plan your actions carefully not to cause unintended execution.

Synchronous actions run differently. They will actually execute before the database is updated, so if the action takes a long time, the form could appear to be stuck. Don't plan any long-running action to execute synchronously, it's not a good idea. But there is a bright side to it: because the built-in update has not actually happened yet, we can piggyback on that update, injecting any updated column values we need right into this update, so no second, action-initiated update is needed. No secondary update, no problem with unintended execution. And, as an added bonus, you have the ability to cancel the update when your action fails and even show customized error message to the users. Imagine that your action update an external DB with the same data that goes into the list. If that external DB is for some reason unavailable, you would want to prevent creating the SharePoint item as well, to keep the two in synch. Another example would be resource booking, when you want to prevent double-booking (read more here or download our Room Reservation solution that implements this approach).

So as you see, there are multiple different options that give you precise control over how and when your actions get executed, adding to the power of Smart Action Pro, the indispensable tool for any SharePoint developer.