In my last post, Did You Know: Understanding Nintex in a Cloud Near You, we explored where Nintex’ infrastructure is hosted and the reasoning behind it. That’s a great start in understanding information flows and data sovereignty compliance.
One question that comes with that, though, is not just where data is stored, but WHAT is actually stored in Nintex’ cloud infrastructure. This is particularly important when you start using Nintex Analytics, the workflow analytics platform.
So, let’s dive right into it and break this down into lenses, the data collection process, and the data model.
What is a Lens?
A lens in Nintex Analytics is a version of the truth, so to speak. I compare it to looking at dice. The total count of dots on one “die” is 21. Depending on your point of view, your version of the truth is only a subset. Maybe just two dots, maybe nine dots — if you look at the corner of “6” and “3.”
Nintex Analytics operates in the same way, collecting all sorts of information from your Nintex Workflow platform. Applying a lens to the information gives you a focus point and one version of the truth, a subset.
Currently, there are three Analytics lenses, one due for release in the coming weeks:
- Usage Lens – gives you an understanding of key consumption metrics and the return on your Nintex investment.
- Inventory Lens – gives you an understanding of key governance and operational aspects of the Nintex Workflow platform, such as workflow status, ownership, designer proficiency, reach and impact of workflows, and the like.
- Intelligence Lens – shows you process efficiency, business insights, and helps you optimize the processes in your portfolio.
How Does the Data Collection Process Work?
Data collection is straightforward. Once your Nintex environment is connected to Nintex Analytics, data extraction will start pretty much automatically. The Usage and Inventory lenses collect information every time a workflow:
- Gets published;
- Is initiated;
- Changes its state;
- Executes an action; or
- Executes a task.
The Process Intelligence (PI) lens relies on some of the information gathered from one of the events listed. However, the main purpose of the PI lens is to extract business-relevant information. Because this relies heavily on the actual business process and the information an organization wants to track, this can’t happen automatically.
That’s where the Nintex Analytics Beacons come into play. There are three beacon actions in your workflow toolbox, each for a different purpose.
They have one thing in common, which is the ability for a workflow designer to emit any kind of data being used or created during the workflow lifecycle. For an expense approval process, this can include approval times, expense amounts, cost centers, processing times, and more.
Understanding the Data Model
Now that you have an understanding of lenses and the information being collected, let’s get to the important bit. The most critical part for organizations that work with cloud services is knowing what information is kept on these platforms. You could now open up a Power BI dashboard that is connected to various lenses in your environment and explore the data model. But hey, why make it hard for you?
With the GDPR legislation coming into play in May 2018 in the European Union, and various other regulations and laws already in place, it is also important to understand the personal information being collected. I have highlighted the relevant data points.
Below is the list of data points collected, broken down by each of the events I mentioned earlier:
- Workflow is published (or republished):
- Workflow name
- Publisher name
- Publisher email address
- Publisher login name
- Location (string detailing path to the workflow home)
- Location URL (link to the workflow location)
- Type of the workflow (i.e.: list, site or tenant)
- Assigned Use of the workflow (i.e. Production or Development)
- Publish date & time
- Current version number (if applicable)
- A Workflow is run (instance) or its state changes:
- Workflow name
- Workflow version
- Instance start date & time
- Status of the workflow (values vary depending on the underlying workflow technology)
- Date/time of the last action in the workflow
- Instance end date & time (only if completed)
- Initiator name *
- Initiator email address *
- Initiator login name *
- An action executes:
- The action type
- The action name
- Start date & time
- End date & time
- Status of the action
- Outcome of the action
- Estimated duration of the action
- A task executes:
- Initiator name *
- Initiator email address *
- Initiator login name *
- Start date & time of the task
- End date & time of the task
- Outcome of the task
* Initiator details are not always available; for example an anonymous form submission triggering a workflow will not have an identifiable initiator or initiator email.
As mentioned, the data emitted to Nintex Analytics via a workflow beacon depends entirely on the workflow designer. Any data point collected or used by a workflow can be part of the information hosted in your Nintex Analytics tenant. If you are a workflow designer, I highly recommend you seek advice from your internal workers’ council, legal team or other appropriate sources to ensure compliance with laws and regulations.
It is important to understand that each organization using Nintex Analytics has its own tenant. This ensures that data is separated from other organizations and you have full control and ownership. No one has access to your data other than people specified in the user management page of your tenant. All of the information is encrypted during transport and rest, ensuring the highest level of security.
I hope this helps you understand the ins and outs of Nintex Analytics, what a lens is, how data collection works and the information collected within your own Nintex Analytics tenant.
Visit the Nintex Community today to learn more and engage in conversations with fellow Nintex and Nintex Analytics users!
