Nintex Data
Back in the data of Nintex Workflow for SharePoint or for Office 365, it was SharePoint that was the data store. You would build your workflow and forms around the concept of a SharePoint List or Document Library, being the data repository. On occassion, you built workflows that didn’t run on SharePoint list events, but instead, were scheduled. In that case, the workflow wouldn’t necessarilly have anything to do with data in SharePoint. Instead, it could query some other system, like Salesforce, or a SQL database. But the data would always be in some external system.
Nintex Data to me is a game changer. Workflows can run in the Nintex Workflow Platform as stand alone, or as part of a Nintex App. They don’t require a 3rd party system for data storage now. You can keep it all inside Nintex.
There are obviously some limitations. What system doesn’t have any? You can find more about the limits here : Nintex Data Tables
The field types that you can add to a table are generic enough, that you should be able to do anything you need. I find one my favorite challenges, is to do the crazy stuff that comes to my mind, with the fields, and actions that I have access to. Obviously, when I hit brick walls, there are ways to expand on what is possible, via Xtensions, rest services etc.
Scenario
Prior to buiding out a workflow, or designing a Nintex App, I like to sit down, and break down what data I need to store. I’m going to go back to something that was near and dear to my heart. The Leave Request process. Does anyone these days, not know how a basic leave request works?
When I first got into Presales, this was the best scenario to cover, because jumping on a call with someone to show off your technology, required a specific process. Spending time describing some obscure process was not a good use of anyones time. Leave Request was easy. Jump in, show the user experience, and show the design of it, build it from scratch and then show how easy it is to enhance it. Recipe for success!!
If I’m building one from scratch, with no data repository, what kind of data will I need to store?
Let’s keep it simple.
Nintex Data Tables
- List of Employees (name, email, manager, manager email, isactive)
- Leave requests (name, start date, end date, approvalStatus, submittedDate)
- Archived Leave requests (same structure as Leave requests)
Workflows
- Leave Request
- A user submits the request through a form
- Workflow handles the assigning of tasks and updating the Leave requests table
- Clean Up Requests
- We only want to keep the leaves requests in the Nintex data table that fall into today and the future
- All older leave requests, should be put into a backup/archive table
Here’s an example of one of the tables. It’s the employees :
and the Leave Request table :
There are 3 tables in total in this example. The Archived list is a duplication of the Leave Requests table.
Examples of Data
So here is an example of 3 Leave Request that were submitted. One is currently open and awaiting a response from the manager. The others are Approved and Rejected. If you look at the End Date, it is after today (3rd Nov 2025).
I have create 2 workflows. One that has a form that someone fills in, to submit the request.
Another, which is run on a daily schedule, and it looks for any Leave Request whose End Date is before Today. That means that leave has already completed, whether it was approved, rejected, or currently open. This workflow will then copy those requests to the Archive list, and delete them from the original Leave Request list. Keeping that list neat and tidy.
Above is the Before image of the Leave Requests. Once my scheduled workflow ran, it now looks like this :
and the Archive table, looks like this :
Workflow Designs
The simple workflow for a Leave Request, which uses the Nintex Data table to find the employees manager. In an ideal world, I would add some checks to make sure that I found a manager, because otherwise it woud fail. But this is just for an example, so I’ll assume everything is perfect.
That archiving workflow is even simpler.
It queries the Nintex Data table for any requests where the leave is technically over, then iterates through the results and creates a copy in the Archiver table, and deletes it from the original Request table.
All this done, without the need of another system like SQL, SharePoint etc.