Configure your Nintex Gateway .NET Core and .NET Framework proxies.
Nintex Articles
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
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
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.
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).
How to integrate Nintex Workflows for SharePoint (OnPremise) and Nintex Workflow Cloud
Question
How to integrate Nintex Workflow for SharePoint (OnPremise) and Nintex Workflow Cloud?
Answer
Refer to the below articles:https://help.nintex.com/en-US/nintex2019/current/#sp2019/Workflow/Designer/UsingExternalStart.htmhttps://help.nintex.com/en-US/nintex2019/current/#sp2019/Workflow/NWCStart/StartWorkflowNWC-actionref.htm
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
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
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
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.