Question

Answer

There are several areas to take note of when building workflows with Nintex for Office 365. Be sure to also review the Nintex Migration White Paper for migration considerations.
 

Workflow Size

Nintex recommends keeping the number of actions within a workflow design in Office 365 less than 200 actions. While business processes can range from simple notifications to complex ETL processes, there are some guidelines around workflow size that you will want to follow:

• There is no hard limit in the number of actions that you can add to a workflow design, however, there are hard limits on how large a workflow definition can be within SharePoint Online put in place by Microsoft. You can read more about the SharePoint workflow thresholds and boundaries here.
• The reason that there is no hard limit on the number of actions that can be added to a workflow design is that each action has a different "weight" within the workflow definition. While a Log to History action may only add 2 KB, a Query List action may add 7 KB to the definition size.
• As Nintex workflow definitions are compressed when exported from the designer, it can sometimes be hard to tell the true size of the workflow definition. 
• To better understand the true overall size of the workflow definition you can decompress the NWF file via the steps below:
  • In the Workflow designer, open the workflow.
  • Click Export in the ribbon. The browser determines if the site is trusted and then initiates the file download process.
  • Respond to prompts from the web browser to download and save the workflow to a location.
  • Within the File Explorer, modify the workflow's file extension from .nwp to .zip (this will cause a warning prompt, be aware that once the file is extracted it cannot be re-compressed into a .nwp file)
  • Extract the newly created .zip file, and the size of the resulting folder is the true size of the workflow definition within SharePoint Online.

Workflow Manager Considerations

While the SharePoint on-premises versions of Nintex Workflow continue to utilize the Legacy Workflow Infrastructure, workflows designed with Nintex for Office 365 now use the Workflow Manager system (also known as the SharePoint 2013 Workflow Engine).
 
Things to be aware of with Workflow Manager:

• Like everything in SharePoint Online, Workflow Manager is a shared resource, and as such it has several 'defensive' mechanisms built in to prevent workflows from using more of the shared resource pool than they are allowed.
  • Note: We take a look at workflow throttling later in this article.
• While Workflow Manager is a more efficient system than the Legacy Workflow Engine (it can do more with less), it is also far less extensible than the Legacy Workflow Engine. Because of this, there is not parity between the available actions within Nintex for SharePoint on-premises and Nintex for Office 365.
• You can track the health of the Workflow Manager system through your Office 365 service health page, or through the Workflow Health section of Workflow Settings within your SharePoint site.
• Should an issue be encountered while using Nintex such as 'Workflow Manager is Unavailable', it is possible to verify if the issue is related to Workflow Manager by attempting to publish a SharePoint 2013 workflow through SharePoint Designer. Often when there is an issue with Workflow Manager, the workflow will appear to publish but never appear within the SharePoint site.
• Workflow Manager uses a Workflow History list to track events within a workflow's execution. If you would ever like to review the status of the Workflow History list, by default it is located at:

http://sharepointsiteurl/lists/Workflow%20history/AllItems.aspx

Workflow Throttling

One of the most prevalent issues caused by poor workflow design within SharePoint Online is workflow throttling. Below are some of the causes of workflow throttling, and ways to avoid throttling events.

Note: Much of this information will be the same as Microsoft's documentation around how to avoid workflow throttling within SharePoint Online.

Best practices to avoid throttling

• Reduce the number of operations per request:
  • When multiple workflows are running at the same time, if workflows are waiting for a wake-up event, make sure that this event will only affect the workflow running on the current item.
    • Example: When using the Wait for Event in List Item action; if any item on the list is interacted with, workflows waiting on this action will wake up, resulting in a high number of calls being made to the SharePoint environment.
    • The preferred alternative would be using an action like Wait for Field Change in Current Item. This action will only wake up the workflow instance if the item it is running on is interacted with instead of any item on the list.
  • Breaking workflow definition into smaller parts, and calling these child workflows through the Start Workflow action. This will help reduce the number of requests per workflow instance.
• Reduce the frequency of calls:
  • If loops are being used within workflow designs, add a try/catch that will pause the workflow after a specified number of loops. This can be accomplished by adding a Pause action inside of a conditional Run If action within the loop that will pause the workflow every X number of loops (for example after every 20 iterations of the loop, the workflow will pause for 1 minute).
  • If a workflow contains any loop logic (loop/for-each/state machines) consider leaving out actions such as Log to History List as they can quickly fill a workflow history list if left unchecked, and result in a large number of calls being made to the SharePoint environment.
  • Split large workflows with many actions into smaller sub-processes with fewer actions:
    • While the final design of how to break down individual business processes will be up to your design team, and the various business owners involved; most workflows have logical breakpoints within the design where a split could be made. Here are some common breakpoints where a workflow could be potentially broken down:
      • Within State Machine – Each branch can function as an independent workflow
      • Within Parallel Blocks – Similar to State Machines, each branch of the Parallel Block can sometimes be broken into its own process
      • After conditional checks – Based on the outcome of the condition the parent workflow may start one child workflow vs. another

Nintex Live and Live Workflow Actions

In order to bring additional functionality to the SharePoint Online workflow platform, Nintex has leveraged our Nintex Live service to help extend the available actions within our workflows that are running within SharePoint Online. 
 

Actions that utilize Nintex Live 

• * Assign a Task (with LazyApproval enabled)
• Adobe Sign
• Document Generation
• Execute SQL
• Office 365 workflow actions
• * Pause for Duration (when 'with business hours' is enabled)
• Query XML
• Send an Email
• * Start a Task Process (with LazyApproval enabled)
• Start Workflow
• Start Workflow in Nintex Workflow Cloud
• Terminate Current Workflow
• Translate Document
• Update XML
• Web Request 

The actions below also use Nintex Live, but are acquired through the Nintex Store inside of the designer:

• Amazon workflow actions
• Bing workflow actions
• Bitly URL shortener
• Box workflow actions
• DocuSign workflow actions
• Dropbox workflow actions
• Exchange Online workflow actions
• Facebook wall post
• Google workflow actions
• LinkedIn workflow actions
• MailChimp workflow actions
• Microsoft Azure workflow actions
• Microsoft Dynamics CRM workflow actions
• OneDrive workflow actions
• Rackspace workflow actions
• Salesforce workflow actions
• StrikeIron workflow actions
• Twitter workflow actions
• WordPress new blog post
• Wunderground weather
• Yammer workflow actions

Live Action Considerations

The actions that work with Nintex Live bring incredible extensibility to the workflows that can be designed within Office 365. Here are a couple points to remember when using the Live actions:

• Action execution time:
  • Due to the actions making authentication calls, and the web service calls to various parts of SharePoint Online, Live actions may take slightly longer than a native workflow action to execute. This can vary from one minute to five minutes depending on the particular Live action.
• User Authentication:
  • As the actions are making calls out to Live and then returning data back into SharePoint, the actions each have part of their configuration that calls for user's credentials.
  • The user specified within the configuration will need permissions to perform the respective workflow action (if using the Office 365 Create List Item action, the user specified within the configuration must be able to create a list item).
• Security between Office 365 and Nintex Live when an action is executed:
  • All communication between Office 365 and Nintex Live is through Transport Layer Security (TLS)
  • Below is an outline of how communications between Office 365 and Nintex take place:
    • At Design Time:
      • The workflow designer configures the relevant Live actions from within the Nintex Workflow designer.
      • When the workflow is published, any sensitive configuration options are encrypted from within the Nintex for Office 365 application. Nintex for Office 365 is built to automatically treat credential passwords as sensitive information and encrypted.
      • All encryption is in memory. There is no storage of unencrypted credentials as part of the workflow publishing process.
      • The published workflow definition contains the encrypted item, not plain text.
    • At Run Time:
      • When the workflow executes, the workflow sends the action configuration, including the encrypted information, to Nintex over secure TLS.
      • The credentials are then decrypted in memory before sending it to the Nintex Live routing engine also within the Nintex Live/Windows Azure infrastructure.

Related Links