Enterprise Edition / Cloud Only

Some action types can have their actions deferred such as the "Run Action Set" and "Search and Run Action Set" actions. Deferring an action means that it will execute at a later time. From a technical perspective, the action will typically run within seconds of being deferred. The main use of deferring is to return the user back to their work without having to wait for the completion of the action(s). Another user is to avoid timeouts.

In one scenario, you may have an Action Set that runs and takes 20 seconds. Normally, the user would have to wait the full 20 seconds to be able to do anything in the system. The "Please Wait" dialog will stay up until the actions are done. If you defer the Action Set then the user will be able to move on to something else without having to wait the full 20 seconds. This makes for a much better user experience.

In another scenario, you might have a long running process which takes several minutes to complete. For this, you cannot have the user wait because the screen will timeout and give them an error message. The system will only wait for 30 to 120 seconds depending on which screen the user is in. By deferring the actions you could get them back to working in seconds while the long processes run in the background.

Things to Remember

You need to keep a few things in mind when using deferred actions. There are some best practices and some limitations inherent in them. If you design your process without these in mind it can result in undesirable outcomes.

Best Practices

Keep these best practices in mind when deciding to use deferred actions.

You need to determine if the user needs to see the results of the actions immediately. If they do need that then you should NOT defer the actions. The reason is that the screen they are on will refresh BEFORE the deferred actions have run so any updates in the deferred actions will not be shown. Users may see this as an error and click the button again and again. The results could range from an annoyance to a process that was duplicated and ruined their data.

Also, you should devise some method to prevent the user from performing the action again until the previous one is done. It could be as easy as using an Add-In, setting an immediate action that sets a value which removes the Add-In button. Then in the deferred actions, reset that value so the button re-appears when it is done. It could also mean redirecting the user to another Web page (Home page) with a message saying their process is running. 

You should also devise a way of letting the user know their process is done. This could mean sending a simple email saying the process is ready. Or it could mean routing an item to them that shows up in the workflow list with an optional email. Either way, there needs to some indicator to the user that things worked or failed.

Limitations

There are some limitations to be aware of when using deferred actions. 

First, the user has no way of knowing if the process worked or failed. You need to devise a way in your process to let them know. As explained above, it could be a simple email. 

Second, throwing exceptions in deferred actions will not alert anyone or cause any notifications. It will log the message in the Deferred Actions Report but that is usually not enough. Instead of throwing exceptions, consider sending an email.

Third, Any external loops that cause deferral to run multiple times will still work but the deferred actions will not have access to external [LOOPACTIONCTR], [LINECTR], [DOCCTR], etc. variables. If your action requires the looping variable values, consider doing the loops inside the deferred action and not outside. 

Fourth, don't forget Deferred Actions are only available in Enterprise Edition on the Cloud. Standard Edition and Premise systems do not have this capability.