Skip navigation
All Places > Getting Started > Blog > 2015 > April

The much awaited Nintex Lazy Approval action for Office 365 SharePoint online is here making your approval process SUPER FAST! All we have to do now is to simply type 'Ok' or a few other accepted keywords (covers almost all words I could think of for saying yes or no) in the assigned task notification and hit SEND. Right from your inbox without going to your SharePoint environment.

Here's something I tried and sharing for you to try in your cloud as well(weather permitting ofcourse - just kidding!)

App Requirements:

Your organization has purchased a few training resource licenses and your rock-star team of devs/engineers/architects/students/runners/movers/shakers...well you get the idea, want a process in place that will track requests allowing users to avail training for two weeks and then release the hold, so others can book the same.

Create a list, setup a workflow, assign a task when resource is requested. Pause the process for two weeks, then continue the process by assign a task for returning the item. On return, release the hold for the resource.

List columns:


Training Requests SharePoint list columns.
Training Requests SharePoint list columns.


Leaving out the default columns(Created, Created By, Modified, Modified By and Title ofcourse we now have

  1. StartDate - defaults to Today
  2. EndDate - calculated by adding two weeks to StartDate
  3. ServiceRequested - Lookup list with names of available resources
  4. Reason- multiline textbox for explaining why you need the resource.
  5. TrainingRequestWorkflow(well, this is your column with status of the workflow)
  6. Requester-You, when you submit the request. Set the default view to show image and title

Customize with Nintex Forms to show the fields as shown below. (I set Requester name to current user and StartDate as Today on form load)

Submit a request for training resource
Submit a request for training resource

Now we are ready to assign requested resources to users via lazy approval process. Image below shows workflow steps.

  1. Set workflow status to In Progress
    Set workflow status
  2. Add Time to Date-Assign that to workflow variable dtEndTime
    Add two weeks, set variable dtEndDate and set it to field EndDate
    Add two weeks, set variable dtEndDate and set it to field EndDate
  3. Set field in current item- Assign value of dtEndTime to EndDate field in the listSet value of EndDate field.
  4. Assign a task-This is where you set Lazy Approval4a
    Assign a task action values in detail4c4b 4c 4d Set your Default Outcome to (Ok/No), OOTB default is Approved/Rejected.Check the Allow LazyApproval to enable the same. What this does is to email the user when a task is assigned seen in email below.4e4f
  5. If the user replies with OK then set the following actions in the workflow path
    -Set field in the current item-Title with EndDate
    -Set Workflow Status to Assigned-Paused And Pause until EndDate
    -Pause Until Date5c
  6. After pausing the workflow for two weeks,  Assign a task just as in step 4. Except, when the user replies with OK, Set the workflow status as Hold-Released. Reset the Title  as ‘Training Available’6a6b
  7. After two weeks/end date, you will receive a notification again reminding you to release the item.9a9b
  8. Once the user replies OK then the list item is updated, and task is marked as complete.7a
  9. If the user replied with ‘No’ then Set Workflow Status as ‘Extend-Hold’ and then Reset Title as seen in the value below. Workflow task is completed.6c7b

Thats it! You are done.  And here is the quick snapshot of all steps at a glance.


Quick snapshot of all the steps.
Quick snapshot of all the steps.


Lazy Approval really makes approval process and task completion faster for users.

This is just an(my) example and one way of solving a request/task assignment scenario with Lazy Approval enabled. As we all know, there are multiple solutions for any task/requirement. Choose what best fits your needs and have fun working smart!

We have two option to schedule workflows depending on the type of workflow that you need to schedule here i am going to explain you how to Schedule Site Workflow on SharePoint / Nintex 2010


  1. Click on Site
    Action  menu
  2. Click on Nintex
    Workflow 2010


3) Click on Schedule site workflows option


Now WorkflowSchedules.aspx page will appear 

Click on Add Schedule


After clicking button you will get create a new workflow schedule for a site workflow window



  • Select the workflow
  • Select a workflow for this schedule
  • Put Start time
  • Schedule End
  • Click on save


Finally your workflow has scheduled and it’s appeared in schedule section like above image view .




How to execute a SP2013 REST API request with Nintex Workflow

With all the Nintex Workflow actions, we can achieve lots of great workflows. Sometimes, we'd like to build more complicated, technical, reusable workflows. For these workflows, we need more actions and possibilities that can be achieved by calling SharePoint ASMX web services or SP2013 REST API requests.

As the ASMX web services are deprecated in SharePoint 2013 and SharePoint Online, it is recommended to use SP2013 REST API instead when it is possible (not all functionalities of the ASMX web services are available in SP2013 REST API).

I'd like to help you building your SP2013 REST API requests.

There are two categories of SP2013 REST API requests :

  • POST : to update, create or remove information in SharePoint,
  • GET : to retrieve information from SharePoint.

The process to execute these two types of requests is different.


How to execute a GET request


To execute a GET request, a "Web request" action only is needed. The configuration of the action should look like this :




It is possible to select a text variable in the "Store result in" field to get the response of the request and then use a "Query XML" action to extract the information needed.



How to execute a POST request


The execution of a POST request is more complex. A request digest is first needed in order to pass the security information to the server when sending the POST request.

To get the request digest, the following "Web request" action should be executed :




A text variable has to be selected in the "Store result in" field.

Then the request digest has to be extracted from the response of the request.

To extract this information, a "Query XML" action has to be configured to execute the following XPath query :





Once the request digest is stored in a variable, it is possible to execute the POST request via a "Web request" configured like the following :






Example : How to update a list item using REST API


Before executing the POST request used to update a list item, the request digest and the list item entity type full name are needed.

To get the request digest, follow the steps explained above.

To get the list item entity type full name, execute the following "Web request" action (where "txtListName" is the title of the list where the list item to update is) :




The next step is to extract the list item entity type full name from the response of the above request using the following XPath query :



The last step is to execute the POST request with the following "Web request" action (where "numID" is the id of the item to update) :





I hope that this will help the community !


Caroline Jung

When using Nintex Forms for submissions of surveys, promotions, or orders where a user must meet a certain age, Nintex Forms has you covered with Validation rules. For this example, we are opening a contest for a free bottle of a tasty beverage (which in the United States requires you to be 21 years old).



If a user enters a birth date that is less than 21 years old, they will receive an error message:



To create a validation rule against the Date Picker control, we need to write a rule around the length of one day. To do that, you can use a calculated value control:




“Birthday” in the Formula field is the DatePicker control, named “Birthday”.

When previewing the form you will see that calculations of dates through integers are in milliseconds.



Now that we know the value of a date picker control, we can build a form variable to get the value required (NOTE: ensure data type is Integer):




We can then build a Validation rule as follows to ensure that the Form Variable “birthdayCheck” is greater than 662688000.



You can use the following SQL query to find workflows inside the Nintex Content database based on their state. Simply modify the "WHERE" argument to look for workflows in other states.


SELECT DISTINCT i.workflowname, i.webid, i.siteid, i.listid, p.CurrentActivityTitle, p.TimeStamp
FROM dbo.workflowinstance i
  inner join WorkflowProgress P
  on I.InstanceID = P.InstanceID
WHERE i.State = '2'


Here are the different states you can query:

when 2 then 'Running'

when 4 then 'Completed'

when 8 then 'Cancelled'

when 64 then 'Error'



Andrew Beals

I needed to use state machine for my workflow, but for 1 reason or another, I cannot make it work. It's always stuck on the 'State Machine' part, where it doesn't even process a single branch/state. I read a few suggestions on how to solve these problem, but as it doesn't apply to my situation, so I looked for a workaround. Please do note, this is not an elegant solution, but it works, and it seems to work fast!


Solution concept: State machine is like an infinite loop, it keeps repeating/jumping states until certain exit conditions are met. Ergo, I can create an infinite loop using the various looping options (although For-Each is used as it seemed to by-pass the Safe Looping feature), until I want to loop to terminate. I'll use switch to go to different 'States' but other branching will work as well.


Example State Machine

Let's say we have 3 number of steps (States) that need to be met before proceeding further into the workflow, like illustrated below




In the above example, if conditions in State 1 are met, then it moves to State 2, and so on, until it reaches State 4 in which it exits the State machine and proceed with the rest of the workflow. In practice, it can jump in any order of the States as needed or keep staying at the same State.


Equivalent using For Each, Collection, and Switch


Solution break down:


  • LoopCol - collection type used for looping
  • LoopTxt - Single line for getting values from LoopCol
  • KillLoopYN - yes/no for killing or continuing loop
  • StateTxt - Single line for storing State



  1. Initialize LoopCol by adding an arbitrary value (ex. Add 1)
  2. Set Initial state of StateTxt (State 1)
  3. Set KillLoopYN to No
  4. Configure ForEach loop with
    • Target Collection: LoopCol
    • Store result in: LoopTxt
    • Stop Processing: KillLoopYN
  5. Similar to the State Machine example, check for the desired condition. If you want to continue the loop, Set the desired State (StateTxt), Set KillLoopYN to No, Add an entry to the collection (LoopCol)
  6. To terminate the loop, either immediately set KillLoopYN to Yes, or change the State to the exit State (State 4 in this example)


I hope this helps those who are having trouble with State Machine. It's still better to use State Machine if it's working, but at least we have a work around if it's not. Thanks. My first post so please pardon me if not helpful. Thanks again.

To followup with further functionality from Using the Format this Value Feature , on-premise formatting of dates can be accomplished within actions on the fly. In the previous post we see how we can specify a return value for Person or Group values from fields or variables. Here I wanted to quickly show that this is also available for Date fields and variables as well.


In this example I am using a Set Variable action to set a Single Line of Text variable the value of a DateTime workflow variable. By selecting the ellipsis to the right of the variable drop down I can then specify the return type to save to the text variable. The available options are As String, ISO Formatted, Long Date, Long Time, Short Date, and Short Time.


If you are not seeing your Nintex Workflow / Forms buttons on a list where the site features have been enabled and you are able to use Nintex on other lists in the site then its  more than likely this is being caused by the web part settings for that list.


To resolve this issue you simply need to ensure that the web part settings for "Toolbar Type" are set to "Full Toolbar". You can change this setting by selecting "Edit page" and selecting the web part that displays the list and then either clicking "web part properties" in the ribbon or selecting the "Web part menu" drop down arrow. This will open a menu that looks similar to the image below. Once there, change the following option:




You must have "full toolbar" enabled as the Nintex Icons are treated as an "addin" according to SharePoint and is therefore hidden when the toolbar is not set to "full toolbar". If you are still having issues please submit a support case.




Andrew Beals

This conversation was started by Ronda Palmer and it's a pretty hot topic! A lot of you have joined in, and we'd all love to hear more about your experiences, let us know in the comments below!


How do you control who is allowed to create forms and workflows? Do you allow all site owners to do their own or do you have a group that creates them for the entire organization?


Some of the responses from community members:



  • "I've seen both as a consultant. Site Owners in some places, or a defined group of designers in others. The decision comes down to Governance.Though it is easy to begin creating workflows in Nintex for anyone, there are a few things to consider when designing. Use of History data, number of workflow running at once, database use, and many others. It can come down to many small decisions too. Such as, how many workflows to you envision will be created? If you think 50, or some imaginary number of significance, you may want to consider the side effects (like lists with 200,000 items because no management is considered for history data, or there was an endless loop)." - Andrew Glasser


  • "Its different for different organizations. Ours is based on our governance document. You just don't want any user to have this capability. If they do something wrong, they can crash the servers. We have site owners for each dept. Those site owners have to go through specific SharePoint training. Workflow training isn't required." - burkslm


  • "This is a great topic and as Andrew said, it is often overlooked by many organizations.  Governance is about guidelines that do not restrict users, but enable them to be productive within boundaries.

    How you approach who can or cannot create workflows depends on the structure of the organization, the knowledge and experience level of the users, and the processes in place for day to day business operations.  While implementing technical controls such as only site owners can create workflows is a good idea, it is a bad governance policy if it creates a bottleneck of productivity for content owners waiting on a site owner to create a workflow for them.

    I have often mentioned on here that people should be cognitive of creating technical solutions or trying to make Nintex and SharePoint do things to correct or create workarounds for broken business processes.  Its like putting a bandage on when you need surgery.  Governance is about creating policies and procedures that put the right mechanism in place whether it is operations, technical or managerial.  Nintex is just part of that equation, and a very vital part I may add.  The conversations should never start there though, or you will always find yourself implementing solutions that are governed by rules that simply don't fit and cannot be enforced." - Eric Harris


  • "Well, we always get this question when we present Nintex to our potential Customers. For the IT people, they want to Enable business users from creating their own workflows. and for business users they want the same. From our Experience, Business people dont play around with Nintex when it is on the live environment, nevertheless, they always revert back to the IT people to create the workflows they want. My Recommendation is to enable the workflows for site owners, at least they use SharePoint from a development perspective. There is a difference between a user who uses a list and the user who knows how to create the list so you need to target the one who knows how to create a list. Finally, this is a case by case scenario, and it is up to you to decide with the customer, but keep the information above on mind." - Mohammed Qattan


Thanks Christof Meyer and Ingo Ehlers for your questions and comments too!


This blog post was generated from the following discussion: Who creates forms and workflows in your organization?


Let us know what you think, and share your experiences in the comments section

We've had a couple of people request the ability to pull back information on the workflows in their farm. This script will return the results of all workflows found inside of the Nintex databases associated with your farm.


There are a couple of things to note:


  • Workflows that have been designed, but never run will not show in the results (no record of them in the Nintex DBs)
  • If you have performed a recent purge on the Nintex databases, the workflows may not show up.
  • If you receive errors when running the script, please allow it to run to completion. The script uses what It finds in the Nintex DB and resolves certain information (SiteID > Site collection URL, Etc.) and may error if a Site Collection/Site/List and/or workflow is not found. This will not affect the results of the workflows that are found.





#                                         ### Nintex Workflow Statistics Query ###

#                   This script will use the Nintex Assembilies to query the Nintex databases and find workflows.


#        Please ensure you run this script as Administrative account that has rights to each Nintex database

#Adding SharePoint Powershell Snapin
Add-PSSnapin Microsoft.SharePoint.PowerShell -EA silentlycontinue

# The Line below will suppress error messages, uncomment if you are seeing errors but still receiving results.

#$ErrorAction = 'silentlycontinue' 

# Loading SharePoint and Nintex Objects into the PS session

# Grab Nintex Config database name

$CFGDB = [Nintex.Workflow.Administration.ConfigurationDatabase]::OpenConfigDataBase().Database

# Creating instance of .NET SQL client
$cmd = New-Object -TypeName System.Data.SqlClient.SqlCommand

$cmd.CommandType = [System.Data.CommandType]::Text

# Begin SQL Query
$cmd.CommandText = "SELECT
FROM dbo.WorkflowInstance I
inner join WorkflowProgress P
               ON I.InstanceID = P.InstanceID
Inner join [$CFGDB].dbo.publishedworkflows pw
on i.WorkflowID = pw.WorkflowId
GROUP BY GROUPING SETS((i.siteid, i.webid, i.listid, i.workflowname, pw.Author), ());"

$indexes = @()

# Call to find all Nintex Content Databases in the Nintex Configuration Database, then execute the above query against each. 
foreach ($database in [Nintex.Workflow.Administration.ConfigurationDatabase]::GetConfigurationDatabase().ContentDatabases)

$reader = $database.ExecuteReader($cmd)

# Creating a table
$row = New-Object System.Object

$Site = $(Get-SPSite -identity $reader["SiteID"])

$SubSite = $Site.Allwebs[[Guid]"$($reader["WebID"])"]
$List = $SubSite.Lists[[Guid]"$($reader["ListID"])"]

#Adding Query results to table object
$row | Add-Member -MemberType NoteProperty -Name "Workflow Name" -Value $reader["WorkflowName"]
$row | add-member -MemberType NoteProperty -Name "Database" -value $Site.ContentDatabase.Name
$row | Add-Member -MemberType NoteProperty -Name "Site Collection" -Value $Site.Url
$row | Add-Member -MemberType NoteProperty -Name "Subsite" -Value $SubSite
$row | Add-Member -MemberType NoteProperty -Name "List" -Value $List.title
$row | Add-Member -MemberType NoteProperty -Name "Author" -Value $reader["Author"]

$indexes += $row

#Print results on screen
$indexes  | FT -autosize
Write-host "Total Workflows in all DataBases:" $indexes.Count


You receive the following error when publishing your workflow in Office 365:


2015-08-18 16_53_43-Nintex Workflow for Office 365.png

(Error publishing workflow. NW-2-002)


This error occurs when trying to publish a workflow and the "Workflow Tasks" list does not exist or may have been deleted. Normally, the "Workflow Tasks" list should be created upon opening the Nintex Workflow Designer. If this was not successful or perhaps that list was deleted while you were in designer you will receive this error.


To resolve this error simply close the workflow designer and review your site contents to ensure the workflow tasks list has been created or not. If the workflow tasks list has been created simply open the designer again and publish your workflow.



Andrew Beals

Hello there.  If you're reading this post, I hope that you had the opportunity to read Part 1: Work Flow Purpose.  and Part 2: WWYSYDH.  In part two of this series, I introduced the concepts of using the right actions to get the right results.  At the end of it I promised to go even deeper and provide an example Training Calendar solution for you with a list and workflow incorporating what I've been covering in this series.  Well, I did it .  I built it all out, typed this long blog, included screenshots and even remembered to attach the files.


I will say this post is rather lengthy, but no solution is good without documentation and I wanted to explain each step so you would learn as you went along.  If you’re as excited as I am…let’s get going!

Part 3: Meet Mr. Wilson.

Scenario: I had a customer, whom I will call Wilson.  Wilson called me one day with an issue using his workflows.   He had been working on a calendar list for training and was wanting to make it automate notifications when training events are created, updated or canceled.  He also wanted to setup a reminder notification to be sent out one day prior to the events start date.


Seems easy enough right? So let’s see why I’m using Wilson as an example for my blog.


Outside of the obvious that he’s a celebrity and has been coveted since his debut in Castaway, Wilson has some things he wants to do better.  What I discovered when I look at his SharePoint site was quite interesting. Not bad, just….well that’s the reason he called me.


So let’s see what Wilson did…


Wilson created three workflows for each scenario listed above.  He had a workflow running when a new event was created, a workflow when the event was changed, and a workflow when the event was cancelled.  Are you seeing what I’m seeing? That’s slight overkill for the events and his process.  Not a bad thing, and he certainly can do that, but that makes things difficult if he’s wanting to be efficient.  Hmm… let’s keep going.


If you remember, Wilson wanted to send a reminder out for the day before the events date to remind attendees.  The problem that he was facing was trying to send the reminder without causing the other workflows to fire which would send additional notifications.  Okay, I can see how this can occur, so how am I going to fix that?  Just for your reading pleasure, there wasn't anything special about his list, it was a standard out-of-the-box Calendar list, and I attached a copy below for you.


So where did I start?

I needed to get him the reminders and as an added benefit, eliminate some redundancy?   I also knew he had a busy schedule with interviews and special appearances and didn't need to spend so much time managing three workflows.  This is too much fun writing about Wilson, but he is enjoying the press as well. So keep reading...


Here’s how I approached it.


Step 1: Assess the purpose and the logic

My first step was to look at his workflows.  After realizing they were all similar I knew I could eliminate one of them easily. The image below shows what actions were in his workflow (nothing spectacular):


So as you can guess, Wilson had three workflows that would run on new item creation and on changes to the item.  I knew that was part of the problem, so I wrote out the logic using the DUCERIM Process worksheet to be sure I didn't redo his looping affect:

  1. Notify a group of people when a new event was created
  2. Notify a group of people when the event was changed/updated
  3. Notify a group of people when the event was canceled


Step 2: Reconfigure the logic to ensure efficiency (2 workflows instead of three)

My next step involved two separate things.  The first part of step 2 was to reconfigure the New Event Workflow settings to ONLY run for new events.  This is important because by doing this I could then isolate the logic of what happens when the event is new.  See the workflow setting below:


How are you doing so far? I hope you’re following my logic; at least it made sense to me and Wilson at that time :-).


My rationale is that I know when a new event is created in SharePoint, it can only be a “New Item” once.  This means I do not need any additional conditions to be checked or validated against. I also added in a status column so that when things are changed, the workflow running on modified would know what to do with that information as well.  This possibly could be eliminated, but I left it in here for my own sanity. 


The results of the reconfiguration produced the following workflow that only runs once when the event is first created. 


New Event Workflow Explanation

The workflow runs on new > sends a notification to the appropriate group > updates the item’s status > calculates the pause date, pauses until the pause date > sends the reminder notification.


Wow!!! So why did I build it this way?

As I mentioned this workflow is solely meant to run once, and if nothing else happens to this event, such as an update or change, this is the only workflow that will run.  Therefore adding the pause until made sense because I can pause the workflow until the day before the event’s date and then have it run again to send out the reminder.


So I got this one done, now what?  Well, I had to test it to make sure I had it built correctly.  After running through two events, Wilson was quite thrilled to see the reminder working as well.


The second part of step 2 was to get the Changes and Cancellation Workflow built out correctly.  My challenge here was to fix the logic of one workflow, and if possible eliminate the other workflow.


Let’s see how I did that…

Ideally I wanted this workflow to ONLY be triggered when the event is modified.  This is important because this isolates my logic to a certain action that I know and can plan for and wont cause this one to run when the event is new.  To achieve this I modified the Workflow Settings and ensured that it only ran on event was modified.


The next thing was to keep the actual workflow process simple.  I decided to use the run parallel actions. This gave me the chance to run both conditional test simultaneously and only complete the correct action each time. I know some people would try to use the run if action and you could do that, but I like to try and keep process as simple as possible and keep my workflow as short as possible.


After I figured that part, I used the set a condition action because I wanted it to do a single task; check the status field for either “Change” or “Canceled”. Based on the status it would then perform the remaining actions accordingly. For a modified event to be considered a change, the user could update the event item, and change the status to reflect that it was changed.  The logic I was aiming for was to have the workflow process that change.  See the image below.


The next part was processing for Cancellations. Hmm... I already had the actions that I wanted to use for changes, and technically the cancellation is very similar to the change so I did this:


Hidden below is a BIG TIP and one reason I absolutely love Nintex.

I know that set a condition is similar to an action set in that it groups all the actions underneath it.  So I simply clicked on the little down arrow to the right of the set a condition action and selected copy.  I then went over to the branch on the right, click on the little node and selected paste.  I hope you caught that tip (you can copy and paste actions).  Literally within 2 seconds I had the same actions in both branches and all I needed to do was to configure the right side branch to process for Cancellations.


I want to see you do that with a SharePoint Designer Workflow. Oh wait…you can’t .


Wilson was also impressed by how quickly I had this logic built out.  So lets keep going, we’re almost finish with this workflow.


I removed the first send notification, the calculate date and the pause until actions as I didn't need those for a cancellation.  Since an item was canceled, I wanted to show the users that it was canceled.  This would help them identify the canceled events from the current ones.  I decided that to achieve this I would update the title of the event by appending “- canceled by Initiators Name” to the end of it.  That was it, and I was able to achieve that by using the update item action.  After that action, it would send the notification to all attendees and end.  Think that’s cool, see below:

I now how all the information and logic correct, both branches are filled out and it seemed to be legitimate; however, a workflow that is not tested is not a good workflow.


Testing the Change and Cancellation Workflow:

To test this one accurately, I took an event previously created for the New Event test and I modified the event dates, added a different description just for fun, and set the status to “change”.  I knew I could do this because the logic of this workflow would only run when an event was modified. I also knew that the New Event workflow would not run again so this event was a safe test.


The results of this was as expected.  I received the first notification that the event was changed, then it paused until the notification date.  Because I ran the pause for the same day, I received the reminder 5 minutes later which told me that it worked as it should.  If nothing else changed on this event, that would be the only time it would run and complete.


The next test was to take another event that I had created and process it for canceled.  For this I simply edited the event and changed the status to cancel. Seems simple right.  The results again were successful.  That means I had a good workflow and I can now reveal it to you.  Here is the complete workflow altogether.



Well that’s it, I had two workflows running and notification being sent to the attendees at the right times, but my job wasn't quite done.  While I did leave Wilson quite speechless with how nice it turned out, and how fast I built it, I couldn't leave his site in that manner.


What I mean is that I had test data out there and it needed to be cleaned up.  So in following the DUCERIM process, I went through and purged the workflow history along with the items in the events calendar that I had created.  This allowed Wilson to start with a clean slate and get back to whatever he was doing before he called me.


I hope you enjoyed this fun but real life example of using Nintex to achieve an automation process with a Training Calendar.  There is a lot more that I could have done from adding a registration component, ensuring only active events are showing and so much more; but this was long enough. If you want to know more about the DUCERIM process or have questions, ask me and happy #nintexing.





P.S.  I may have a Part 4 but who knows...

Filter Blog

By date: By tag: