Power Apps/Flow vs. Nintex Forms/Nintex Workflow
As part of an internal project, I implemented a vacation approval process using the technologies Nintex Forms and Microsoft PowerApps or Nintex Workflow and Microsoft Flow.
The use case was kept as simple as possible to ensure a valid basis for a comparison of the two counterparties. The basis for both implementations is SharePoint Online and the data is stored in a standard SharePoint list.
Usability
PowerApps from Microsoft Office 365 offers the possibility to create forms quickly and without any developer background. A simple user interface that integrates all list columns from SharePoint Online into one form from within the standard template. There are many ways to arrange and configure the columns. The form logic is presented in three different levels, “Display Form”, “Edit Form” and “Submit Form”, which can interact accordingly via formulas.
With Nintex Forms you do not have the ability to interact with the forms within the user interface. The advantage is that the navigation between forms does not have to be configured manually by using a formula, because it already works out of the box.
As a beginner, you will repeatedly come across configurations within PowerApps which have to be implemented via formulas. These formulas cannot be derived or reproduced from other technologies and therefore, must be learned.
Connectors
The workflow steps in Microsoft Flow are primarily built through what are known as connectors. Microsoft provides various connectors for this purpose (i.e. SP Online or Exchange Online), but the actions are also limited and not complete. The setup of user-defined connectors for REST APIs is also possible. This must be configured in the administration before the flow is created. Therefore, you have to first navigate away from the flow configuration interface back to the administration to create user-defined connectors. Nintex Workflow, on the other hand, creates a web request from the Designer Canvas. This simplifies user handling when creating a workflow.
Set Records REST API — Flow:
The advantage of Microsoft Flow is that when a REST API process step is created, the fields from the interface are already consumed and visible to the user. Only the contents have to be filled in.
Set Records REST API — Nintex Workflow:
With Nintex the fields from the REST interface must be known or looked up.
Functions / Formula
The basic functions of the two products are very similar, but can become very complex with PowerApps.
In PowerApps there is no way to deactivate fields or columns (standard or custom), depending on other fields or columns. For this purpose, workarounds often have to be created in order to implement the requirements of the form. Contrastly, the deactivation of fields in Nintex Forms can be achieved through the column properties.
In both technologies, formulas must be used to develop certain form rules and logic. For example, the calculated time between two date fields is represented by the formulas “DateDiff(DataCardValue3.SelectedDate; DataCardValue4.SelectedDate)” and “DateDiffDays(StartDate, EndDate)”. Both variants require the user to acquire certain, basic knowledge. The formula generator within Nintex Forms also offers more options, as opposed to creating rules with PowerApps. For example, it is not yet possible to use a “ThisItem” property as part of a rule.
Interface to the Workflow Engine
In order to transfer the entered values to Microsoft Flow in PowerApps, a button must be explicitly created that triggers this flow. This button, which triggers the interface to Flow, must be configured by the user himself. The parameters must also be passed using complex formulas. With Nintex Workflow, the process is simply started via start options:
An advantage of Microsoft Flow is that you can start test workflows and transfer sample content for debugging. This feature enables more efficient testing.
Authentification / Authorisation
A user-defined connector can be set up or managed beforehand in Microsoft Flow. The administration overview of all connectors of the tenant, including authentication status, contributes to the administrability. In Nintex Workflow, the process step must be set up or authenticated directly via a web request and cannot be administered by a central admin in the company (or similar).
A greater challenge with Microsoft Flow is the execution of actions in the context of another user. For example, it is not possible to execute an Exchange Online calendar entry via the connectors on behalf of other users. Therefore, it is simply not possible to implement this action with a service account.
Community
During the research and implementation of this project, it was quite evident that due to the young community for PowerApps and Microsoft Flow, not many blog articles were readily available. Even post completion of this project, there is still scarce knowledge and solution proposals that have been shared so far.
On the contrary, Nintex is a well established and well known technology, which for years has maintained a strong community, frequently sharing solutions and knowledge online.
Conclusion
Microsoft Flow is well suited for beginners who are designing simple processes and for basic business requirements within companies. The intuitive user interface and the one-click execution of test flows simplify the creation of process steps for the user. A further advantage is that the connectors and the associated authentications/authorisations for administration and troubleshooting are clearly separated.
PowerApps, for the creation of forms, is very complex and can become technically challenging for non-coders.
With Nintex Workflow and Nintex Forms, even more complex processes are possible without having to find workarounds. Despite the slightly less intuitive user interface, both Nintex products offer a greater variety of workflow actions and form settings.
