Nintex Articles

Workflow Start Threshold and Throttling

Topic

 
Nintex Workflow Cloud (NWC) tenants have Workflow Start threshold of 10,000/hour per tenant.
 

Additional Information

 
Why does this threshold exist?

To provide a high-performance environment for all customers, in a fair usage environment. 
Ensure our service operates reliably and predictably for all customers.
Avoid performance degradation incidents.
The threshold level is well above the typical usage for most customers.  97% of our O365 & NWC customers have workflow starts below 5,000/hour.

 
What is considered a ‘Workflow Start’?
Any request to start a workflow through any of the following channels: Manual start, Form Submission, Start Event (i.e. item added to SharePoint list), Component workflows (i.e. started from NWC API, Start Workflow action, etc.), or a Scheduled start.
 

How can the threshold be avoided?

Optimize request operations:

Add more granular conditions for a request to start workflows
Fewer requests per hour
Stagger requests throughout the day
Reduce the frequency of requests

 
What happens when the threshold is reached?

External starts (API calls, component workflows, etc.) – No new workflows start;  Returns a 429.
Start Events – Workflow start is queued and retried in next hour.
Form submissions – Workflow start is queued and retried in next hour.
Scheduled workflows – Postponed until the next hour.

 
Additionally, an in-app banner message in Automate page will be displayed stating the following:
 
Due to higher volumes within the past hour some workflows have not yet started and are queued to commence shortly.  For more information, please visit the manage workflow starts help document.
 

Nintex Gateway Proxy Configuration

Configure your Nintex Gateway .NET Core and .NET Framework proxies.

Remove The Account To Configure Azure Active Directory Identity Federation After Completed The Setup

Topic

Can we remove the Admin account that is used to configure the Azure Active Directory identity federation after the setup has been completed? 
 

Additional Information

Yes, you can remove this Admin account after successfully finishing the setup and it will still work even after the account has been removed. 
 

Related Links

https://help.nintex.com/en-US/nwc/Content/Settings/ConfigureAzureAD.htm
 

Nintex Workflow Cloud Forms – Data Source Variable FAQ

Topic

Frequently asked questions about Data Source Variables in Nintex Workflow Cloud Forms.
 

What are Data Source Variables?

Data Source Variables are a new capability that is available within Nintex Workflow Cloud Forms that enables designers to source data from external systems into their forms design and use that data across various different controls and rules. Like the Data Lookup control, Data Source Variables leverage existing data sources within Nintex Workflow Cloud to connect to external systems but aim to provide more flexibility with the data than the drop-down styling of the Data Lookup control.

 

Can anyone create a Data Source Variable?

Designers that have been given permissions to a data source within Nintex Workflow Cloud can create new Data Source Variables.

 

Can Data Source Variables be used with any control type in Nintex Workflow Cloud?

Currently Data Source Variable values can be used with Label controls and can be set as the value of Text – Short, Text – Long, Email, Currency, Number, or Geolocation control via rules. Support for additional controls such as Choice – Single and Choice – Multiple will be available in the future.

 

Can any data source be used to create a Data Source Variable?

Currently Data Source Variables only support SharePoint Online and Azure Active Directory data sources, however additional data sources will be made available in subsequent releases.

 

Can a custom Xtensions based data source with Data Source Variables?

Not yet, but this functionality should be available soon.

 

Can I use my Data Source Variables within my workflow?

While any values that are used in a control will be passed to the workflow as a start event variable, the Data Source Variable itself is only available within Forms at this time. If a workflow designer would like to access the same information, they can use a ‘Query’ action as this will return the same object/data as the Data Source Variable.

 

Additional Information

 
 

Related Links

 
 

Remove The Account To Configure Azure Active Directory Identity Federation After Completed The Setup

Topic

Can we remove the Admin account that is used to configure the Azure Active Directory identity federation after the setup has been completed? 
 

Additional Information

Yes, you can remove this Admin account after successfully finishing the setup and it will still work even after the account has been removed. 
 

Related Links

https://help.nintex.com/en-US/nwc/Content/Settings/ConfigureAzureAD.htm
 

read more

Nintex Workflow Cloud Forms – Data Source Variable FAQ

Topic

Frequently asked questions about Data Source Variables in Nintex Workflow Cloud Forms.
 

What are Data Source Variables?

Data Source Variables are a new capability that is available within Nintex Workflow Cloud Forms that enables designers to source data from external systems into their forms design and use that data across various different controls and rules. Like the Data Lookup control, Data Source Variables leverage existing data sources within Nintex Workflow Cloud to connect to external systems but aim to provide more flexibility with the data than the drop-down styling of the Data Lookup control.

 

Can anyone create a Data Source Variable?

Designers that have been given permissions to a data source within Nintex Workflow Cloud can create new Data Source Variables.

 

Can Data Source Variables be used with any control type in Nintex Workflow Cloud?

Currently Data Source Variable values can be used with Label controls and can be set as the value of Text – Short, Text – Long, Email, Currency, Number, or Geolocation control via rules. Support for additional controls such as Choice – Single and Choice – Multiple will be available in the future.

 

Can any data source be used to create a Data Source Variable?

Currently Data Source Variables only support SharePoint Online and Azure Active Directory data sources, however additional data sources will be made available in subsequent releases.

 

Can a custom Xtensions based data source with Data Source Variables?

Not yet, but this functionality should be available soon.

 

Can I use my Data Source Variables within my workflow?

While any values that are used in a control will be passed to the workflow as a start event variable, the Data Source Variable itself is only available within Forms at this time. If a workflow designer would like to access the same information, they can use a ‘Query’ action as this will return the same object/data as the Data Source Variable.

 

Additional Information

 
 

Related Links

 
 

read more

Read and Write permissions to Azure Active Directory is required for User Directory Lookup in NWC

Topic

Why Nintex is requesting to have Read and Write permission to Azure Active Directory for the User Directory Lookup below:
 
https://help.nintex.com/en-US/nwc/Content/Settings/UserDirectoryLookup.htm
 

Additional Information

User Directory Lookup leveraging on our Xtensions functionality for Azure Active Directory and Azure Active Directory Administration connector which requires Write permission.
For this functionality to work, we needed to use Azure Active Directory Administration connections because it provided access to Read the directory permissions.
 
The permissions were inherited because we are using this:
https://help.nintex.com/en-US/nwc/Content/Designer/Connectors/AzureADAdminConnector.htm
 
Connections created in the User Directory Lookup settings page will not be accessible to workflow designers, and thus any write operations using that connection will not be accessible to workflow designs.
 

Related Links

https://help.nintex.com/en-US/nwc/Content/Designer/Connectors/AzureADAdminConnector.htm
 

read more

Form Timeout Values

Topic

Form timeout values in Nintex Workflow Cloud
 

Additional Information

Tokens for authenticated forns are valid for 5 minutes. If 5 minutes is exceeded, a new token is requested upon form submission.
Tokens for unauthenticated forms is 1 day.
Nintex Workflow Cloud has a session timeout after 2 hours, requiring the user to refresh the page and login again. The development team is working on a more graceful way of handling this session timeout in the future.

read more

Salesforce Trial Account with Nintex Workflow Cloud

Question

Can a Salesforce Trial Account be used with Nintex Workflow Cloud?
 

Answer

Salesforce trial accounts do not allow API calls, so they will not work with Nintex Workflow Cloud. You could look at using a developer edition instead(Salesforce Developers).
 

read more

Does Nintex Workflow Cloud have it owns File storage?

Topic

Does Nintex Workflow Cloud have its owns File storage?
 

Additional Information

Yes, Nintex Workflow Cloud provides a ready-to-use and built-in storage solution, which does not require any setup or maintenance from the customer side. 
 

Related Links

Previously Nintex Workflow Cloud is using Default file storage that involved 3rd party (Google Drive, Box, etc) which going to be deprecated soon, and as a replacement Nintex will provide our own file storage.  
 
See below for the details of the deprecation. 
Default File Storage deprecation FAQ 
 

read more

NWC Microsoft SQL Server Connection IP Addresses

Topic

What source IP addresses require white listing in order to create a Microsoft SQL Server connection in NWC?
 

Instructions

To run workflows that connect to Microsoft SQL Server databases or related systems, first configure its firewall rules to allow traffic from potential source IP addresses for these workflows. If firewall rules are in place but not configured to allow these IP addresses, then contact does not occur and the workflow fails.
For instructions on SQL Server firewall configuration, see the Configure the Windows Firewall to Allow SQL Server Access Microsoft article or, for SQL Server on Windows Azure, see the Creating Microsoft SQL Server Connection to SQL Azure from Nintex Workflow Cloud Nintex Community article.
Potential source IP addresses for workflows:

US data zone
EU data zone

34.209.77.209

34.213.74.73

34.217.158.68

35.163.119.92

35.167.88.146

35.167.153.210

52.27.43.14

52.27.60.155

52.35.202.214

52.40.23.80

52.42.133.33

54.69.239.31

54.200.171.39

34.246.224.28

34.246.248.53

34.251.78.124

52.49.171.155

52.50.95.219

52.50.119.8

52.50.185.38

52.211.54.96

52.215.75.122

63.35.37.226

63.35.60.132

63.34.75.62

Related Links

https://help.nintex.com/en-US/nwc/Content/Designer/Connectors.htm#MicrosoftSQLServer

read more
Nintex Workflow Cloud Best Practices

Nintex Workflow Cloud Best Practices

Topic

Nintex Workflow Cloud Design Best Practices
 
Workflow Design

Workflow Action Count (Size):

While there is not a “hard limit” on the number of workflow actions that can be used in a Nintex Workflow Cloud design, it is recommended that designers keep the workflow action count under 250 actions. This recommendation is based not on the workflow engine’s ability to handle the number of actions, but instead is the point beyond which managing the workflow design becomes dramatically more cumbersome. After ~250 actions it can become difficult to track down issues in the workflow design if they should arise. Additionally, should management of the workflow need to be handed off to a new owner, this process becomes exponentially more difficult if great care has not been taken in documenting the steps of the workflow.

 

Action Labels

All actions within the workflow designer start with a default label such as “Query list” or “Retrieve a record”. It is recommended that after actions have been configured, the label is updated to reflect what the specific action is doing. For example, “Query employee list for new requests” or “Retrieve opportunity information”. This will not only make it easier to remember what various actions are interacting with without needing to open the action configuration panel, it will also make it much easier for other workflow designers to quickly understand what the workflow is doing directly from the design canvas.

 

Action Sets

It is recommended that workflow designers leverage Action Sets within their workflow designer to help logically group together different parts of the workflow design. This not only helps understand logical break points in the workflow if the workflow is ever broken down into component workflows, but also helps keep the workflow design canvas less cluttered, as action sets can be collapsed to hide the nested actions.

 
For example, these are the same workflow:

 

 
The action sets allow for a much cleaner and more organized approach to workflow development.
 
Workflow Management

Workflow Description

When publishing workflows it is recommended that all workflows have a description that indicates what the workflow is designed to do. This description will be visible from the workflow list within the tenant and will help other workflow designers know what the workflow does without needing to open and review the workflow definition.

 

Workflow Versioning Comments

When working with product workflows, it is best practice to enable Version Comments for whenever a new version of the workflow is published. These comments should indicate what changes were made since the last update to the workflow, and the comments will be tied with the respective version of the workflow in the Workflow Versions history. If a previous version of the workflow ever needs to be restored, the workflow owner can review the comments to see what was changed between each publish and make sure that they are restoring to the correct version. Comments can be enforced from within Settings via the Workflow Settings page.

 

Workflow Tags

Tags can be applied to a workflow either at publish or from the Workflow section under Automate. Tags help group / organize workflows and can make it much easier for workflow developers to be able to find workflows once there is more than a single page of workflows published in the Nintex Workflow Cloud tenant. Tags can be used as filter criteria on the workflow list.

 

Workflow Error Alerting

By default, if a workflow encounters an error and fails, Nintex Workflow Cloud will automatically alert the user who published the workflow, however you can configure more customized workflow alerting from within Settings under the Alerts page. This can be configured to alert the most recent editor of the workflow, all of the workflow’s owners (defined at time of publish), or a specific set of users, such as the admin users within the tenant.

 
 
Connection Management

Connection Service Accounts

When connecting to third-party SaaS systems, such as Salesforce, Dynamics CRM, or Google Drive, it is recommended that a designated service account is used for production workflows. While connections to these services can be made with personalized credentials (as long as a user has permission within Nintex Workflow Cloud to create new connections), it is recommended that connections with personal credentials only be used in development scenarios. Connections created with personal credentials will only have the individual’s level of access to the third-party systems, and if credentials are updated outside of Nintex Workflow Cloud (such as a password change), this would cause any workflows using the personal credentials to fail until the connection has been re-established in the Nintex Workflow Cloud Connection Manager.

 

Connection Permissions

Similar to workflow permissions, users who create SaaS connections have the ability to manage which other users have access to use the connection within their workflow design. This can be critical when leveraging service accounts that might have access to sensitive information that you do not want all workflow designers to have access to. Even if a workflow designer has access to a workflow, but not access to the connection, they will find the SaaS actions unconfigured within the workflow designer if they open the workflow definition. You can update connection permissions within the Automate section on the Connections page. Connections can be shared with individual users or Nintex Workflow Cloud groups.

 

Removing Unused Connections

Because all connections to 3rd party SaaS systems are created using either personal credentials or service accounts, it is recommended that admins regularly audit the connections that have been built in tenant and remove any connections that are not actively being used by workflows.

 
 
Workflow Publishing

Workflow Versioning Comments

When working with product workflows, it is best practice to enable Version Comments for whenever a new version of the workflow is published. These comments should indicate what changes were made since the last update to the workflow, and the comments will be tied with the respective version of the workflow in the Workflow Versions history. If a previous version of the workflow ever needs to be restored, the workflow owner can review the comments to see what was changed between each publish and make sure that they are restoring to the correct version. Comments can be enforced from within Settings via the Workflow Settings page.

 

Update Existing Production Workflow From Development

As part of the workflow development cycle, some organizations have a dedicated “development” tenant where all changes must first be made, tested, and approved before they can be deployed into production. If the number of changes between production and development are substantial, the workflow owner may want to simply import the updated workflow from development into production. Andrea O’Hara has written a blog post on the exact steps that can be taken to complete this process.

 
 
Additional thresholds to be aware of while using Nintex Workflow Cloud

Maximum number of users in a group: 200
Maximum number of groups a user can be included in: 20
Maximum number of published / draft workflows in a tenant: 2,000
Maximum versions of a workflow: 500
Maximum number of conditions in a single form rule: 15
Maximum number of controls on a form: 2,000
Maximum number of items in a workflow collection: 250

 
 

Additional Information

 
 

Related Links

 
 

read more

Nintex Workflow Cloud Security Best Practices

Question

What security-related best practices are Nintex Workflow Cloud users responsible for?
 

Answer

Users of Nintex Workflow Cloud are responsible for the following:

Understanding and complying with their contractual obligations to Nintex.
Immediately notifying Nintex of suspected or confirmed information security breaches such as compromised user accounts or passwords.
Developing disaster recovery and business continuity plans that address their ability to use or access Nintex Workflow Cloud.
Protecting end-points to thwart malicious software from entering the Nintex Workflow Cloud execution environment.
Notifying Nintex of changes made to technical or administrative contact information in a timely manner.
Designating internal personnel who are authorized to request user additions, deletions, and security level changes.
Managing the user access controls for provisioning and deprovisioning user accounts. This includes enforcement of password policies, management of shared accounts, and authorization approvals.
Restricting administrative privileges to approved need-to-know personnel.
Securely managing the connectors including confidential management of account credentials, disabling connections no longer required, and managing need-to-know access to shared account information.
Understanding and defining data storage requirements. Securely configuring any EFSS systems or other systems where files are eventually stored.
Managing the confidentiality and integrity of the distribution of authentication tokens used to start component workflows.
Managing the need-to-know and least privilege when sharing workflows.

 

read more