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



When Hide formatting rules execute on a form, controls lose their placement.




The below form contains a Choice control titled Colors. When ‘Colors’ is selected, either Red or Green will determine what controls show and what controls are hidden.


Here is the Nintex Form in Design Mode:



When Green is selected, the Multi Line textbox and two Single Line textboxes will be hidden:


The second rule, "Hide Red", will hide the Single Line textbox 1 and the Single Line textbox 3:



In Runtime, when the ‘Hide Red’ rule is selected, you will see how the bottom ‘Hide When Green’ single line text boxes ‘jump’ on the Multi Line textbox and do not align correctly after the above controls are hidden:





  • Add a Panel control and nest the two bottom Hide When Green controls within the panel.
  • Remove the ‘Hide’ rule from the controls (Select the Hide Green Rule drop down and select ‘Remove from selected controls’).
  • After you have nested the Hide When Green controls, select the Panel control and then apply the Hide Green rule to the Panel and NOT the individual nested controls (Select the Hide Green Rule drop down and select ‘Add to selected controls’).


Below is the corrected form in Design Mode:



Since the controls are now nested within the Panel control, the form will render correctly:



Products: SharePoint 2010/2013


Recently a case came in where the company needed to locate where a feature had been activated within a specific Web Application as it was causing troubles with a Web.Config file.


We were able to use this script to locate the sites with the features enabled.


Run the below (attached as well as a *.txt file for your convenience) PowerShell script (PowerShell ISE works well) from a SharePoint Server:

PowerShell Script
  1. foreach ($site in $(Get-SPWebApplication http://yourUrl).Sites)
  2. {
  3.         foreach ($feature in $site.Features)
  4.         {
  5.                 if ($feature.DefinitionId -match [Guid]'00000000-0000-0000-0000-000000000000')
  6.                 {
  7.                         $site
  8.                 }
  9.         }
  10. }




  • Replace http://yourUrl with the URL of your Web Application.
  • Replace 00000000-0000-0000-0000-000000000000 guid with the Guid of the FeatureDefinitionId to be located.


To obtain the FeatureDefinitionId's of all features in the SharePoint farm you can run this Cmdlet: Get-SPFeature

Have You ever had the situation in Forms Designer that the minimal width of a list lookup control is too big for your form?


In this example I wanted to insert a list lookup for 'unit of measure' to the right of the 'quantity' field.

But the width of the inserted control is too big and I could not shrink it in Forms Designer. What to do?

CSS is your friend. Assign a class name to the control, e.g. 'measure'


and enter a little piece of CSS in the form settings:

Now the form looks as exspected:

You have to play with the number of pixels for width und position. For the width its important to use '!important' in CSS!

I think you can use this also for other controls.


Hope that helps someone



The “User Interaction” category of workflow actions in Nintex Workflow provides extremely useful functionality for human interaction with workflows.  These actions handle assigning tasks, prompting for information, and sending alerts to users.


The “Assign To-Do task” workflow action assigns a workflow task and sends a notification to one or more users to complete.  The task assignee must perform the task and mark it as complete via a workflow task form before the workflow can continue.  The action configuration allows workflow designers to use an existing or create a new content type that inherits from the “Workflow Task” parent content type.


The workflow task form that is generated for the “Assign To-Do Task” action uses the default SharePoint workflow task form, even if you create a new content type via the Nintex user interface. In order to complete the task, a user must change the Status field to “Completed” (see the images below).  My experience so far is this process is not very intuitive and often confusing to assignees. And let’s face it, this is a pretty ugly form that also contains several unneeded fields.


SharePoint 2010 task form


SharePoint 2013 task form




Design a Better Form

In this post, I want to share with you how to create an “Assign To-Do Task” workflow task form that the assignee can complete by just clicking a button and that has only relevant fields.  In order to accomplish this, we need to create a new content type via the “Request Data” workflow action that we can use in the “Assign To-Do Task” workflow action.  So let’s get started!


  1. Create a new list or library workflow.
  2. Add a “Request Data” action to the Workflow Designer and configure it with the following settings:
    • Collect data from – Add a user (I would suggest using yourself).
    • Content type – Select the “Create new” option and enter a name for your content type (for example, “Complete To Do Task”).
    • Content type fields – Do not add any fields. Select the other settings you would like, such as “Only show fields with variables assigned”, “Display link to workflow item on the task form”, “Display the item properties panel on the task form”, and “Allow attachments”.
    • Task name – Enter what you would like (for example, “Complete this task”).
    • Leave all the other fields as they are defaulted.

      Nintex Workflow 2010 Request Data action

      Nintex Workflow 2013 Request Data action
  3. Click the Save button in the General tab of the Ribbon menu to save your changes to the “Request data” action.
  4. Publish the workflow – In order for the new content type to be created, you must publish the workflow.
  5. Add an “Assign To-Do Task” action to the Workflow Designer and configure it with the following settings:
    • Assignees – Add a user (I would suggest using yourself).
    • Task description – Add some content.
    • Content type – Select the “Use existing” option and choose the new content type you created in Step 2.
    • Content type fields – Do not add any fields.  Select the other settings you would like, such as “Only show fields with variables assigned”, “Display link to workflow item on the task form”, “Display the item properties panel on the task form”, and “Allow attachments”.
    • Task name – Enter what you would like (for example, “Complete this task”).
    • Leave all the other fields as they are defaulted.

      Nintex Workflow 2010 Assign To-Do Task action

      Nintex Workflow 2013 Assign To-Do Task action
  6. Click the Save button in the General tab of the Ribbon menu to save your changes to the “Assign To-Do Task” action.
  7. Disable or delete the “Request Data” action – This action was only used to create the new content type when you published the workflow in Step 3, so it is not needed at this point.
  8. Publish the updates to the workflow.
  9. Test the workflow by starting it on an item in your list/library.
  10. The workflow will assign you a “To Do” task to complete, so open it in your browser.
  11. Complete the task by clicking on the “Complete task” button.

    Nintex Workflow 2010 Complete Task Form

    Nintex Workflow 2013 Complete Task Form
  12. That’s it! The new “Assign To-Do Task” form is much simpler to complete.


Follow these steps if you would like to edit the “Complete To Do Task” content type you just created.


  1. Add a “Request Data” action to a workflow and configure it.
  2. Click on the “Edit the content type” link under the choice in the “Content type” selector.
  3. Click OK when you receive the message that says “Changing the content type may break other applications. Are you sure you want to continue?”.
  4. Make the appropriate changes to the content type. You can add, edit, or remove fields in this content type.
  5. Click the Save button in the General tab of the Ribbon menu to save your changes to the “Request data” action.
  6. Publish the workflow – In order to apply the changes to the content type, you must publish the workflow.


This solution applies to both the Nintex Workflow 2010 and 2013 versions.

The Flexi task is one of the most popular workflow actions and we are eagerly awaiting its arrival in the o365 version.  For something so powerful, how much of it do you really know?  How many of the options have you used?


Today I want to concentrate on the behaviour section:

1 Behaviour.PNG


What do these options actually mean?


Like most of you, I suspect we accept the default behaviour “First response applies” and carry on happily knowing that a single person is going to make a decision on an action and their decision is final.  Things, however, start to get a little trickier when multiple people are involved.

Let’s start by way of an example:


We have a situation where the flexi task is has two outcomes (Approve and Reject) and it is sent to two people.  In order to continue, we want both of these people to approve the task.  If either of the people reject the task, we want the workflow to manage the outcome as if it was rejected.  Sounds simple enough right?  Surely you just select “All must agree on a specific outcome”, set the outcome to “Approve” and away you go?

2 Approve Outcome.PNG


Let’s try it out.  I’ve configured the flexi task exactly as above and run the workflow.  When both people approve the flexi task, we get the expected outcome as per the picture below:

3 Approved.png


However when one person rejects the flexi task, something strange happens:

4 Rejected.png


What on earth is going on here?  Why didn’t it execute the tasks in the Reject branch!?  The key here is understanding the fine print and I refer to our friendly Nintex User Guide for the exact wording:


All assignees must select the outcome specified in the 'Outcome' drop down list. If any assignee chooses an alternative outcome, all pending tasks will be set to 'not required', the 'outcome achieved' variable will be set to 'no' and the overall task outcome will be blank.


That’s right - what the user guide is telling us is if the people disagree, there is no outcome.  It doesn’t default to rejected as you might have suspected.  Initially that doesn’t seem to make sense.  Surely if the outcome isn’t approved it must be rejected?


The logic only becomes apparent when you have three or more outcomes (e.g. Approve, Reject, Escalate).  If the assignees disagreed, how would Nintex know which branch to follow?  This is why the User Guide states that the overall outcome is blank.  It even provides a method of telling you that no outcome was reached by optionally setting some variables:

5 Store Outcome.PNG


With this new found information you can check the status of that outcome variable and adjust your workflow accordingly.  There are many ways of handling this depending on your exact requirements.  The Run If and Set a condition actions come in quite handy here but I’m sure many of you will have other methods you can suggest.

6 Run If.PNG


The same “no outcome” applies for the other behaviours:  You will reach no outcome under the following conditions:

Behaviour selectedFlexi task results
Majority decidesA majority is not reached.  E.g. there is an equal amount of reject and approve replies
Majority must choose a specific outcomeA majority is not reached.  E.g. there is an equal amount of reject and approve replies
All must agreeJust one person submits a different answer to the rest


As long as you are aware of the “no outcome achieved”, your life will be much easier when dealing with multi-recipient flexi tasks.

So what was the final solution for my original example where we have two outcomes to choose from (approve and reject) and if one person disagrees, we should execute the reject actions?  We could submit a request to the team at Nintex to create a default outcome field or for the next best thing: include an “other” branch which you will find in the Advanced Options and move all reject actions to this branch.  If an outcome is not achieved, the other branch (if it exists) is executed.


7 Other branch.PNG


8 Final solution.PNG


Hope this helps!


Chris | Provoke Solutions

Although somewhat non-trendy nowadays, XML processing is still very much relevant in the SharePoint space. Nintex Workflow is very kind to offer us actions to make Web request or Call web service.


It's not obvious, but the Query XML action can do both a GET HTTP request to retrieve some XML data and produce multiple XPath and XSLT outputs in a single action.


The native SharePoint owssvr.dll endpoint that exposes the URL Protocol comes in handy when all you need is some selection of data from a SharePoint list or library. It lets you easily filter the data you want both vertically and horizontally: by some Field equals Value condition and a selection of Fields to output (without the clutter that a Lists.asmx web service call necessarily returns).


So imagine you only need the people who have pending tasks assigned to them, then you need and format to say:

Tell me, in the XML format, (Cmd=Display&XMLDATA=TRUE) who (Query=AssignedTo) has tasks in this list (List={GUID}, for example from a link on Site settings - Site lists and libraries) that are not started (FilterField1=Status&FilterValue1=Not Started).


Note that

  1. We need to provide the Internal names of the fields we query or filter on, spaces are replaced with _x0020_ and international characters may also be encoded this way. Fields in the query can be joined either by space or plus separator: Query=ID+Title or  Query=Editor Modified.
  2. We can ask for all fields with Query=*, but that defeats one of the benefits.
  3. We can filter on multiple fields at once, numbering them accordingly (FilterFieldN=...&FilterValueN=...), implicitly disjuncting them with AND logical operator (no need to specify it in the query).
  4. We cannot use operators other than "equals" or conjunct conditions with OR.
  5. We cannot use the FilterName=ID&FilterMultiValue=1;2;3 construct to select multiple items


Here's a sample URL this could sum up to:

{WorkflowContext:Current WEB URL}/_vti_bin/owssvr.dll?Cmd=Display&XMLDATA=TRUE



&FilterField1={WorkflowVariable:The internal name of the field, such as Title or ID orSome_x0020_Field}

&FilterValue1={WorkflowVariable:What you search for}.

Hopefully, you'll find this helpful.

In this post I will be running through the process of creating a customisable weather feed using Nintex Workflow and the Content Query Web Part (CQWP). I've seen quite a few weather web parts out there but for the most part I have found them to look quite dated. Nintex Workflow introduces a Live Catalog of actions that can be installed and provide the ability to interact with various services on the web. One of these actions provides the ability to retrieve data from the Weather Underground. In this example we will populate a SharePoint list with the data retrieved from this service and then use this to drive an attractive weather feed.


The final result will look something like the screenshot below, since we are styling this with XSLT it offers us an additional level of flexibility by being able to customise it to our liking.


Create the list

Create a custom list with the following columns, this can be called anything you like, I imaginatively called mine ‘Weather’.


Column NameTypeRequired
CitySingle line of textYes
CountrySingle line of textYes
TemperatureSingle line of textNo
ForecastSingle line of textNo
Last UpdatedDate and TimeNo


Populate the list with one or more entries, include the city, country and the unit that you would like the temperature to be returned in (Celsius or Fahrenheit).


Create the workflow

We will create a site workflow that reads in the city names from the Weather list and then fetches the associated weather observation data and then writes this information back.

  1. Start creating a site workflow by clicking the settings cog and select Nintex Workflow 2013 > Create Site Workflow.
  2. Create the following variables, these variables will be used throughout the workflow.
    Variable NameType
    ForecastMultiple Lines of Text
    Last UpdatedMultiple Lines of Text
    UnitSingle Line of Text
    City List ItemSingle Line of Text
    City NameSingle Line of Text
    CountrySingle Line of Text

  3. Drag the Query list action on to the workflow designer and configure it as follows.
  4. Next we will use a For Each loop and configure it with the following settings.
  5. Add a Query List action within the For Each loop and configure it with the following settings.

  6. Now that we have gathered the city details we can query the Weather Underground service. If you haven’t added this action to your environment it will be necessary to open the Nintex Live Catalog and add the action. The availability of this feature is dependent on whether it has been allowed/enabled in your environment. If all is good, you should see a ribbon icon for the Nintex Live Catalog while in the Workflow Designer.

  7. Click the Catalog icon and do a search for ‘Weather’, the following action will appear. Click the Add button, once complete it will show as Added.
  8. Close the Catalog window and add the Wunderground Weather action to your workflow. This will sit inside our For Each loop and will occur after querying for the City details. Open the action and configure it with the following details.
  9. The last step in the workflow is to update the list item with the current observation data. Drag an Update Item action into your workflow, still within the For Each Loop and configure it with the following settings.

Use the Content Query Web Part to display the results on a page

I’ve created the following basic XSL template, the cool thing about this is that you have full control to easily modify the way the weather appears on your page. This provides you with a heap of control, much more than you would otherwise have if you used a third party web part.


The Content Query Web Part by default uses styles that reside in the Style Library of your site collection. The template below will be added to the ItemStyle.xsl.


 <xsl:template name="Weather" match="Row[@Style='Weather']" mode="itemstyle">
 <xsl:variable name="icon">
       <xsl:when test="@Forecast = 'Chance of Flurries'">chanceflurries</xsl:when>
       <xsl:when test="@Forecast = 'Chance of Rain'">chancerain</xsl:when>
       <xsl:when test="@Forecast = 'Chance Rain'">chancerain</xsl:when>
       <xsl:when test="@Forecast = 'Chance of Freezing Rain'">chancesleet</xsl:when>
       <xsl:when test="@Forecast = 'Chance of Sleet'">chancesleet</xsl:when>
       <xsl:when test="@Forecast = 'Chance of Snow'">chancesnow</xsl:when>
       <xsl:when test="@Forecast = 'Chance of Thunderstorms'">chancetstorms</xsl:when>
       <xsl:when test="@Forecast = 'Chance of a Thunderstorm'">chancetstorms</xsl:when>
       <xsl:when test="@Forecast = 'Clear'">clear</xsl:when>
       <xsl:when test="@Forecast = 'Cloudy'">cloudy</xsl:when>
       <xsl:when test="@Forecast = 'Flurries'">flurries</xsl:when>
       <xsl:when test="@Forecast = 'Fog'">fog</xsl:when>
       <xsl:when test="@Forecast = 'Haze'">hazy</xsl:when>
       <xsl:when test="@Forecast = 'Mostly Cloudy'">mostlycloudy</xsl:when>
       <xsl:when test="@Forecast = 'Mostly Sunny'">mostlysunny</xsl:when>
       <xsl:when test="@Forecast = 'Partly Cloudy'">partlycloudy</xsl:when>
       <xsl:when test="@Forecast = 'Partly Sunny'">partlysunny</xsl:when>
       <xsl:when test="@Forecast = 'Freezing Rain'">sleet</xsl:when>
       <xsl:when test="@Forecast = 'Rain'">rain</xsl:when>
       <xsl:when test="@Forecast = 'Sleet'">sleet</xsl:when>
       <xsl:when test="@Forecast = 'Snow'">snow</xsl:when>
       <xsl:when test="@Forecast = 'Sunny'">sunny</xsl:when>
       <xsl:when test="@Forecast = 'Thunderstorms'">tstorms</xsl:when>
       <xsl:when test="@Forecast = 'Thunderstorm'">tstorms</xsl:when>
       <xsl:when test="@Forecast = 'Unknown'">unknown</xsl:when>
       <xsl:when test="@Forecast = 'Overcast'">cloudy</xsl:when>
       <xsl:when test="@Forecast = 'Scattered Clouds'">partlycloudy</xsl:when>
 <div class="weather">
    <div class="weather-icon">
          <xsl:attribute name="src">
               <xsl:value-of select="concat('',$icon,'.gif')"/>
          <xsl:attribute name="alt">
               <xsl:value-of select="@Forecast"/>
    <div class="city-details">
       <div class="city"><xsl:value-of select="@City"/></div>
       <div class="temp">
          <xsl:value-of select="@Temperature"/>
             <xsl:when test="@Unit = 'Fahrenheit'">
                <xsl:text> °F</xsl:text>
             <xsl:when test="@Unit = 'Celsius'">
                <xsl:text> °C</xsl:text>
          <xsl:text> - </xsl:text><xsl:value-of select="@Forecast"/>


Add the following CSS to the page that you will be displaying the weather on, this can be done in a number of ways e.g. adding a custom stylesheet to your masterpage or adding the CSS directly on the page.


.weather {
  display: block;

.weather-icon {
  padding: 5px 10px 0px 0px;
  float: left;

.city-details {
  padding: 10px 10px 10px 0px;

.city-details > .city {
  font-weight: bold;
  font-size: 1.2em;

.city-details > .temp {
  font-size: 1.1em;


Once you have done this your weather feed is complete. The site workflow can be easily scheduled ensuring the data presented is current and up to date.

Thanks to KuanChiang Lui to provide this Trick.

Below is the example output response from SOAP web request. The return output in XML format.


<?xml version="1.0"

<soap:Envelope xmlns:xsi=""



By using the XPath expression, we able to get the value of [AddListResult] and saved it into variable for subsequent action.


XPath format: //soap:Body/descendant::*[name()='<Node name>']



Try it in "Run Now"


Other example:





<soap:Envelope xmlns:soap="" xmlns:xsi="" xmlns:xsd="">


    <GetUserPropertyByAccountNameResponse xmlns="">








            <Value xsi:type="xsd:string">MyName</Value>













<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:soap="" xmlns:xsd="" xmlns:xsi="">


    <GetListItemsResponse xmlns="">


        <listitems xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:z="#RowsetSchema">

          <rs:data ItemCount="2">


            <z:row ows_EventDate="2015-01-05 11:00:00" ows_EndDate="2015-05-22 12:00:00" ows_fRecurrence="1" ows_EventType="1" ows_Title="Backlog Review Test" ows_Location="Meeting Room" />


            <z:row ows_EventDate="2015-01-30 16:00:00" ows_EndDate="2015-01-30 17:30:00" ows_fRecurrence="0" ows_EventType="0" ows_Title="Happy Friday" ows_Location="Anywhere" />

















2015-01-05 11:00:00

2015-01-30 16:00:00


We have seen this in many sites that we use daily. I had a similar requirement from users to provide help for the choice that is selected from the Drop Down field. It could be description of the field or something else related to that field.


I was just beginning to use Nintex Forms and due to the JScript and CSS capabilities, I wanted to give this a shot. Following things are main components of this solutions:

  1. Creating lookup and calculated field.
  2. Applying CSS to make a picture button.
  3. Generating an Alert with javascript.


A - Setup List for lookup and description

  • Create a list (List1) with 2 columns. Document Type, Description.
  • Add few items in this list.
Document TypeDescription
Acceptance Sheet

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus eros diam, posuere sed risus ac, tempus aliquet justo. Curabitur non fermentum pur

Assembly Drawing

Aliquam bibendum eget libero sit amet condimentum. Nulla blandit sed nunc a malesuada

BETA Trials

Vestibulum mauris felis, aliquet non aliquam at, dapibus id risus. Integer imperdiet, sem laoreet tempor pellentesque


  • Create another list (List 2) which will be used to Save the details. Add The Document Type column as Lookup from List 1.
  • Edit the Nintex form for this list. The form would look as below:



B - Create Help button and apply CSS

Now we can add the Help button next to our Document Type and apply some CSS to make it look like Help.

CSS - Place this in Settings > Custom CSS :



background:url('/../PublishingImages/Question.png') no-repeat;

width: 30px; height: 50px;



Open the settings for the button. Change the Button action to Javascript and expand the Formatting section. Type the name of the CSS in CSS class box.


The form should look something like this:



C - Generate alert with Javascript

The last part is to show the help description.

  • Create a calculated field on the form to retreive the Description from List1 which has mapping to document type. the expression would be something like this: lookup("Document Type","ID",DocType,"Description") [DocType being the name of the dropd down lookup field]
  • Name this field as myDocDescr.
  • Open the settings of the Help Button and add function DocDescr() to the Client Click in Advanced section.
  • On Form Settings, add the following Javascript:



function DocDescr() {

var myDocType = NWF$('#' + myDocDescr);

alert(" " + myDocType.val());


  • Add the following rule to hide the calculated field from the form: myDocDesc!="" > hide.
  • Note: the calculated field will always be hidden as long as an option is available in the drop down. Remember you cannot change the visibility of this calculated field as JScript will not be able to retreive value from it.

That is all. Save and Generate the preview.



Displaying Workflow Tasks

Posted by burkslm Jan 16, 2015

There are times when a user does not want to go through each and every email to approve a task. There are also times when a list item is deleted; however, the task is still out there for that item.


To display the task list for users in SharePoint:


  • Go to Lists->Workflow Tasks
  • Click on the link
  • Copy the URL
  • Create a new item in the Quick Launch and paste the URL there
  • Users can filter the list on their name or check on the status of other users


To display one task link in Nintex email notifications:

  • In your email notification, you can 'Insert Reference' and select 'Workflow Status URL'
  • All the user will have to do is click on 'Respond to Task'


Personally, I give all the users the information they need in the email to approve/reject. In addition, I attach any files. That way they can perform a lazy approval if they so choose to. Where I work, the URLs are disabled from clicking on them. So users have to copy and paste them to open their items.


If you have an orphaned task, it will appear in the workflow task list. You simply find it and delete it.

Mike Matsako's post today on Attach Files to your Discussion Posts, reminded me of another request I get often from the community (and which I've been meaning to post), about locating a draft document or blog post. Sometimes you begin writing a document or blog post, and then save it as a draft to come back later to and realise you can't find it without the direct URL!


Click on the drop down arrow next to your avatar and select Your Content.


And then click on Drafts. Any documents or blog posts you saved as drafts will be in this list.


Hello everyone,


I wanted to make a nice little blog post to teach you all how to add attachments to your replies here on the Discussion boards.  This is a nice way to share your workflows, screen shots, and forms with others (especially for troubleshooting).


Step One:  Click on the "Use advanced editor" link found in the upper right hand corner of your message box.


Step Two:  Click on the "Attach" link found in the bottom right corner of your Advanced Message box:



That's all for now, thanks for reading


PS: Don't forget to like this blog if you have found this little tip useful!

Scenario: I want to query items that were modified in the last 7 calendar days.


How can I query the list to return record IDs: 208, 209, 210

Here with alternatives/tricky solution in creating your workflow.

First solution:

1. Go to workflow designer, drag Calculate date action:


2. Configure the Calculate date as below:



3. Pass the Data and time variable in Query List action:



Second solution:

1. Before creating your workflow, go to your list setting and

  • create a new column (Calculated type) named “Last 7 Days” and
  • formula as "=[Modified]+7"

Note: If you want Date range of 2 days, then you can + 2.


2. After that, the column will be auto shown in your list with formatted value.

Note: The Modified column is auto updated if any changes to the item, the new column that been created will be auto updated as well. Both are not editable.


3. Go to Nintex workflow designer, drag the action Query List and create a “Today date” variable by click on Variables option from Query List action’s ribbon.

4. Click on New button from ribbon.

5. Create “Today date” variable with configuration as below and click save button.


6. Then add a filter rule of “Last 7 days” is greater than or equal to [Today date] in query list action


7. Publish and run the workflow, the result of the Query List action will only return those records that were modified in last 7 days.


8. The result of query will return record ID: 208,209,210

Filter rules: Is greater than or equal to today date (1/15/2015)


Record ID


Modified date compare with today date

Last 7 days(Modified + 7 days)

Is “Last 7 days” greater than or equal
  to today date (1/15/2015)?


4/21/2014 3:55 PM

Modified more than 7 days from today.

4/28/2014 3:55 PM



4/21/2014 3:55 PM

Modified more than 7 days from today.

4/28/2014 3:55 PM



4/21/2014 3:55 PM

Modified more than 7 days from today.

4/28/2014 3:55 PM



5:04 PM

Modified 1 day ago.

1/21/2015 5:04 PM



1/15/2015 10:04 AM

Modified today.

1/22/2015 10:04 AM



10:04 AM

Modified today.

1/22/2015 10:04 AM


A case came in the other day where a customer was unsure of what syntax to use when communicating with Exchange 2010.


When you load up a 'Provision user in Exchange' action in Nintex Workflow Designer, the mailbox container has an option to browse to the Database via an LDAP Picker control:




If you are using Exchange 2003, using the LDAP picker is perfectly fine. If you are using Exchange 2007/2010/2013 you will run into issues with locating the target Mailbox Database.


Instead of using the values the LDAP picker populates, consider using the browser to only retrieve the name of the database and populate the 'Mailbox container' field with this value:





If this action is not configured accordingly you will likely see error messages in your ULS logs that are similar to this:


Category: (Legacy) Workflow Infrastructure

Level: Unexpected


System.ApplicationException: Provisioning user on Exchange 2010 failed. Check the event logs on the Exchange 2010 server to determine the cause.     at Nintex.Workflow.Activities.ProvisionExchangeUserEmailActivity.ProvisionExchangeUserEmail(NWWorkflowContext ctx)     at Nintex.Workflow.Activities.ProvisionExchangeUserEmailActivity.Execute(ActivityExecutionContext executionContext)     at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext)     at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)     at System.Workflow.Runtime.Scheduler.Run()


Additionally, the workflow will fail to complete.

There are times when too many emails go back and forth. When you have a primary and secondary approver, the secondary may not have to approve anything very often because the primary approver may not miss much work. If that is the case, the secondary approver is bombarded by emails for no reason. You can set up for the secondary to receive emails only after so many days, hours, etc. Doing this can reduce all of those unnecessary emails and only notify the secondary approver if for some reason the primary approver hasn't completed a task in x amount of time. To do this, perform the following:


  • Open the Assign Flexi task action
  • Make sure the primary and secondary are in the 'Assignee' on the 'Action' tab
  • Click on the Task Notification tab
  • Click on the dropdown for 'Edit Settings for' and select the secondary approver
  • Click on 'None' for the 'Delivery Type'
  • Click on the 'Reminder' tab and set how many reminders need to be sent and the time between reminders


You do not have to set the secondary up in the 'Reminder' tab because they automatically get notified since they are an Assignee. This is a very useful tip to have in a Nintex Workflow developer's bag of tricks.

Products: Nintex Workflow 2013, Nintex Workflow 2010


We received a request the other day to bulk update Workflow Constants. While it is easy to import-export Workflow constants, it is not a trivial matter to update a great many of them. Typically updating involves logging into Central Administration and/or each site and updating the credentials manually.


Here is a method that takes some of the work out of updating these values by allowing you to edit an exported Workflow constants file using a specific format and persist these changes back into the environment in an automated fashion.


Things you will need:


  1. An export of Workflow Constants in file format.
  2. Some kind of XML Viewer (Notepad++ is what I prefer).
  3. A copy of this script (below and attached).




  1. Export the Workflow Constants you want updated and save them to a file (More information here: NWAdmin Operations - Nintex Workflow 2013)
  2. Open the File in an XML Viewer. This should present you with one long line.
  3. Save a copy of this file in case something goes wrong and you want to revert back to the original values.
  4. Replace all '><' instances with a line break/carriage return to make working with the XML file easier (Notepad++ example below).2015-01-13 12_11_15-_new  8 - Notepad++.png
  5. You should end up with something that looks like this: 2015-01-13 12_14_33-_new  8 - Notepad++.png
  6. Edit each WorkflowConstant's Value node to have a UserName and Password as the new value with a space separating the two values (Important Note: You must have a space separating the username and password to avoid parsing issues):           2015-01-13 12_16_57-_new  8 - Notepad++.png
  7. Any Workflow Constants you do not wish to update should be removed from this file.
  8. Once you have updated the workflow constants file, save it and update the following reference in the PowerShell script (Line 71) to the location and filename chosen: Execute([Nintex.Workflow.WorkflowConstantCollection]::Deserialize([System.IO.File]::ReadAllText("C:\export1.xml")))

  9. Run the script and perform and testing to ensure the values are what they should be.



PowerShell Script
  1. Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
  2. [void][System.Reflection.Assembly]::LoadWithPartialName("Nintex.Workflow")
  3. [void][System.Reflection.Assembly]::LoadWithPartialName("System.Xml.Serialization")
  4. [void][System.Reflection.Assembly]::LoadWithPartialName("System.Text")
  5. [void][System.Reflection.Assembly]::LoadWithPartialName("System.IO")
  6. function ProcessCredential([Nintex.Workflow.WorkflowConstant]$constant){
  7. $credentialValue = New-Object -TypeName "Nintex.Workflow.CredentialValue"
  8. $stringBuilder = New-Object -TypeName "System.Text.StringBuilder"
  9. $serializer = [System.Xml.Serialization.XmlSerializer]($credentialValue.GetType())
  10. $stringWriter = [System.IO.StringWriter]($stringBuilder)
  11. $credentialValue.Password = $constant.Value.Split("{ }")[1]
  12. $credentialValue.Username = $constant.Value.Split("{ }")[0]
  13. $serializer.Serialize($stringWriter, $credentialValue)
  14. $constant.Value = $stringBuilder.ToString()
  15. #$constant.EncryptValueField()
  16. return $constant
  17. }
  18. function ProcessUsageSecurity([Nintex.Workflow.WorkflowConstant]$constant){
  19. if ($constant.UsageSecurity -ne $null){
  20. $constant.UsageSecurity.Update()
  21. }
  22. }
  23. function Execute([Nintex.Workflow.WorkflowConstantCollection]$collection){
  24. foreach($constant in $collection){
  25. $existingWorkflowConstantId = [Nintex.Workflow.WorkflowConstantCollection]::GetWorkflowConstantIdByName($constant.Title, $constant.WebId,$constant.SiteId)
  26. [Nintex.Workflow.WorkflowConstant]$c = ProcessCredential($constant)
  27. if($existingWorkflowConstantId -eq -1){
  28. $newConstant = New-Object "Nintex.Workflow.WorkflowConstant" ($c.Title, $c.Description, $c.Value, $c.Sensitive, $c.SiteId, $c.WebId, $c.Type,$c.AdminOnly)
  29. $newConstant.Id = -1
  30. Write-Host "Adding $($constant.Title) to Workflow Constants."
  31. $newConstant.Update()
  32. }
  33. else{
  34. $newConstant = New-Object "Nintex.Workflow.WorkflowConstant" ($c.Title, $c.Description, $c.Value, $c.Sensitive, $c.SiteId, $c.WebId, $c.Type,$c.AdminOnly)
  35. $newConstant.Id = $existingWorkflowConstantId
  36. Write-Host "Updating $($constant.Title) in Workflow Constants."
  37. $newConstant.Update()
  38. }
  39. ProcessUsageSecurity($c)
  40. }
  41. }
  42. Execute([Nintex.Workflow.WorkflowConstantCollection]::Deserialize([System.IO.File]::ReadAllText("C:\export1.xml")))

Office 365 with SharePoint Online has excellent custom form and workflow options, that is a known fact.

Those who love InfoPath Designer 2013 and SharePoint Designer 2013 can do A LOT of customized workflows, with multiple approval paths, parallel approvals, conditional task and anything else you can think of or not, with the OOTB actions and steps in SharePoint Designer 2013. I love InfoPath Designer and I love SharePoint designer, there is no secondary thought about that. But what you love need not always be what is loved by all.

So in comes Nintex. My first time with Nintex Form and Nintex Workflow.

Straight forward request this time.

There is a Sofware Request form, when a user submits request -> Approver A->Approves->Approver B->Approves->Approver A again for further actions.

Creating the custom sharepoint list with the identified fields is nothing new. Once the list is created with your columns(lookups, person/group, multiline textbox, datetime etc.,) Look at your List tab.

Your will see Nintex Forms and Nintex Workflow ready and available to customize the list with.


Click the Nintex workflow and you will be redirected to the NIntex Workflow


The Gotcha! moment came when I was trying to modify the Assign a task action for the first approval step.

The auto generated Email Body of the task notification conveniently prepopulates the body with required task items along with a link to the related item. {Task:Title} redirects the approver to the Task item assigned to her/him. Now, what if I don’t want to go to the item and then click Edit Item and then Approve adding comments? Sounds pretty exhausting just saying that eh!


Here’s where I was so proud of myselfl, see that Hyperlink button in the yellow box, I used that to insert Edit the task url with the URL of the Task “Edit Item “. Then removed the ID=xyz to ID= Edit Menu Table Start this inserts the {Current Item:: Edit Menu Table Start} which got the dynamic ID of the task and opens the edit item task for the approver!

Not bad for the very first custom Nintex workflow in Office 365 SharePoint Online eh!

Trust this post helps someone looking for the quick edit link as well.

Intrigued about the Lazy approval action in Nintex Workflow. I don’t have IM option for notification in O365 SP Online apps. Who knows, maybe I’ll find it soon and post another blog on it soon.

Cause you know, as a great woman(ahem…me) once said

the more you know

the more you know and

the more you share

the more you care!

Emily Billing Reposting my post here cause I just saw the January mission! Learning and sharing can be super fun!

Hello All,


Here i'm going to share some nice feature in Nintex form to show the confirmation message, once the item added in the List.


Activate the Nintex forms for List at the site collection level, then create a Image file with nice colorful and with your text and place the same in any document library or picture library.  This image file will show once the users submitted the item in the list.


Following to this go to Nintex form settings page, put the image URL in the "Redirect URL" under Advanced section. Click save and publish the Nintex Forms. Now try to added a new item to the list and the colorful image pop after submitting the item.


In addition, we can use Submit button option to show the confirmation message. Control Settings of Submit button, under advance section provide the message in the "Confirmation message" box.




Enjoy Nintexers!





Logging History In Loops

Posted by burkslm Jan 8, 2015

Beware of running 'Log in History List' actions in loops (for each, loop, etc.). Not doing this will clutter the workflow database with logs and impact customers. If you have them, set them to "Hide from workflow status" in the "Common" tab of the for each or loop. In general, there shouldn't be too much logging in your workflows anyway. Its better to use those for troubleshooting and giving general information to the user.



There are many ways to debug workflows while in development and also when live in production. This is an overview of the methods that can be used and tips on when and when not to use them.


Log in History List

The most used method to get quick information about the status of the workflow, or the output of a variable. Be careful not to overuse this action by placing it in loops or leaving debugging information in place while in production.


History is stored in the SharePoint Workflow History list and is truncated by SharePoint after a configurable amount of time. History is also stored in the Nintex Workflow database to allow users to review history much longer after SharePoint removes its list data. This has a great feature, but make sure you are aware and possibly trim history information from databases after some time or databases will fill up too. See Chad Austin’s post on Demystifying Workflow History (Part 1)  for details.


Remove debugging information when going live in production by disabling this action or deleting them.


Have a secondary workflow. One method that can be of assistance is to have a workflow as the primary production workflow that is used on a daily basis. Have an exact replica workflow, but with Log in History List action is key areas that does not start automatically. If you run into an issue, then run the secondary workflow to debug it on the same list item. This could help in finding what may have gone wrong.


Use a switch or condition. In your primary workflow you can have history data logged in reaction to metadata in a list item. For instance, on your custom form, if the user is an admin you can present them a checkbox on the form. When selected the workflow will use log to history throughout the workflow. If left unchecked, history data can be skipped by the condition working around the Log in History List.


Govern your environment. Make use of multiple web applications when developing. If you are not developing workflows in their own farm, make an attempt to have a separate web application so that the workflow runs in a unique App Pool in IIS different from the Production site. This will help production to not be slowed down by development workflows. Use multiple Nintex Databases. In the case of a complex, or many workflow site collection, create a Nintex Database just for this site collection. Use multiple history lists. The more you have, the less chance that one workflow will effect another because of history list usage. And if one workflow’s history is more important than another, having them separated allows easier management of the other.


Common Settings

In most actions there is a Common Settings tab. Within that tab you could find “Message to log on completion”. This value will log a message in the workflow history when the action has completed. Similar to Log in History List, but without a separate action. Very useful, but be aware of the same usage scenarios you could run into as Log in History List.


Error Handling

Some actions have built in Error Handling. This will allow the workflow to capture errors when they occur and allow the designer to react appropriately without causing the workflow to end.


For actions like Web Service calls or Execute SQL, you can follow-up these actions with a Set a Condition action to test if an error occurred. Then you can react in any way necessary. This could be ending the workflow but after a notification is sent out, or try again, but with an updated value.

Be careful of scheduled workflows. I had a nightly scheduled workflow that came back with an error. I knew there was no reason for it to error because it had been running for months with no problems. I contacted the server admins to check into the error on the server for me. They didn't see anything suspicious. I had the workflow running at a specific time. They told me that could cause a problem. I didn't know it but they ran patches and updates at the same time my workflow started. They recommended I ran the workflow outside of that window. This particular workflow had to run midnight or later but before employees arrived at work. I didn't want any employees updating the list while this workflow was running. I changed the time their updates were over. I haven't had any problems since. I also learned there were other workflows scheduled and the times they were running. I found that the workflows were put in a queue so your workflow wasn't guaranteed to run exactly when you wanted it to run. Sometimes my workflow started when I scheduled it and sometimes it would be an hour or later.


When you are creating a scheduled workflow, be sure to know the times other workflows are scheduled and any maintenance on the servers are to be performed. This will save you a headache later.




Lock Down Items In A List

Posted by burkslm Jan 5, 2015

There may be times when you have a list and you want to lock down items in the list to certain people, groups, the creator, etc. due to the sensitivity of the data. This can be done in Nintex Workflow. I am using Nintex Workflow 2010 so it will be based on that version. To do this:


  1. Use the action 'Set Item Permissions'.
  2. Set Item On = Current Item.
  3. Inherit permissions from parent = No.
  4. Check Remove existing permissions.
  5. Users = the users you want to have permissions
  6. Permission = the permission you want them to have.


You can have multiple users with different permissions. You can add them by clicking on 'Add user permission'.



Have you ever had a problem that you knew was possible, you've seen it before, or you just know that the fundamentals of the problem should be solvable.  We I will admit that I had one that stumped me for over two weeks.


I was talking to a friend of mine about using Parent/Child List items and how to automatically tie them together and create them within one form.  Without hesitation, I was like, "Sure that should be simple, just input information into one form, then use a workflow to sift through (loop) and create child items from the one list."  Note to self: Do not commit to a solution before writing it out!


Honestly that sounded really simple in theory and should have been, but when I started down the reality path of developing the solution, it became a real brainteaser.  I thought about using InfoPath, SharePoint, and Nintex Forms, but each time I got stumped at how to exactly get the child items into the list in the first place.   After spending several hours looking through this one night I ended up in tears.  Well let me paint the picture differently, it was so frustrating that I let out a cry for help.   Then as if by a stroke of genius, I figured it out and well, the rest is history.


So I am now writing this to save you from the long hours of pain of staring at your computer screen.  Please dont do that.  Its not worth it, just read through this, see if it makes sense, and then download the attachments and be happy.  Don't stare at endless errors wondering why the form or workflow is not working correctly.



The premise of this is not for everything, but useful when you want to track Parent/Child Items.  What this will allow you to do is create one form for entering the Parent information and the child items, then track those items in two separate list for reporting and other options.


I will not go into the depths of SharePoint or Nintex on this, but communicate the concept and steps taken.  If you dont understand a certain step, shoot me an email and remember what I said above, please do not stare at this stumped its not that serious.  Really, thats why Im writing this, to show it can be done.


Kudos, Props, Much Thanks, Cheers. Hopefully you get the point

First off, thanks to Vadim Tabakman for the start of my solution in his blog.  I'm sure everyone that has looked at doing repeating tables in Nintex has read his blog in some form or another.  If not, umm...what are you waiting on, click here.  It was his workflow piece that I used to get the child items piece for my solution.  After going through each piece of his workflow, I was able to figure out what steps to add in to make the child list work.


Are you ready?  Lets dive in.


Step 1: Lets create our Parent and Child list.

Parent List: Test Repeat is the name I used for my list.  Click here to download the .stp file.



Child List: Child List is the name I used for my list. I know really intuitive huh?  Click here to download the .stp file.


Note: Remember this is a simple concept; you can do much more with this if you desire.


Step 2: Now lets modify the form on our Parent List.  To do this, got to your list, and select Nintex Forms (See screenshot).  If you want to get going quickly, click here to download the list templates which should include the form preloaded.  You can then skip to Step 5.


  1. Delete the forms controls for MyRepeatingSection and DetailTable.
  2. Add a repeating section to your form
    1. repeatingsection.png
  3. Name your repeating section "MyRepeatingSection" and Connect it to the MyRepeatingSection column. (This is a testing step and is not needed if you know how to write XML. I recommend doing this only at the beginning.  This will allow you to grab the XML that you will need later in your query. )
  4. Drag the label and text field for FirstName and LastName into the repeating section
  5. Format it with colors or whatever as needed, then save and publish the form.


If you're a brave soul that wants to figure out some of this manually go to Step 3 first.


Step 3: Create a test item to grab your XML and copy it to notepad to hold it.  Now go back to your form and disconnect your repeating section. Save and Publish it again so that its setup correctly for the workflow.  This is IMPORTANT, so that your workflow will work correctly.



Step 4: Create the form, import the template, save and publish it.


Step 5: Create a Nintex Workflow connected to the Parent List.  Use the blank template and when it opens up click on Import.  Click here to download the workflow to use as a template.  I am choosing not to go into details so that this isn't a really, really long blog.  But, don't fear, I have attached the screenshots for each action in a zipped folder for you.



Step 6: Once the workflow loads, ensure that each action does not have an error on it.  If it does, double click on it and configure the settings.


Based on some feedback and the workflow not importing the UDA correctly, I have added that as an attachment below. The Get Forms Repeating Data UDA needs to be imported before the workflow will work. It will still need configuration, but this should help out.

Step 7: Test your form and workflow.  This should work and you should see an output of the data in the list view as shown below.  If you are not seeing that, go back and make sure you have your fields named correctly and that your workflow ran with no errors.


------- Parent List Output Above -------

ChildListWItems.png------- Child List Output above -------


That's it.  You have just created two list, a form and a workflow that will generate child list for your users.  This application can be used for many things, and hopefully gets you started in the right direction for a solution.  Now that's what I call ninticity which is short for simplicity with Nintex .


Oh yea, one more thing, share your comments and thoughts on it, what would you have done differently, and do you have any cool tricks with the table that you can do?


Happy Nintexing,


I have found this problem very annoying after not knowing what it was and running into it several times. We finally resolved the issue after banging our heads against the wall. If you have a list with a workflow and want to save the list as a list template and save the data you will run into this issue. I even checked the setting to include this data.


What happens is when you have your new list, you try to import your original workflow. You do that because the original workflow does not appear in SharePoint. In trying to be consistent, I try to name the new workflow the same name. An error appears telling me the workflow already exists. Well, how can that be when it does not appear in the workflow list for the list you are working on? However, magically if you go to SharePoint Designer you will find the workflow under the list even though it doesn't appear in SharePoint. You will have to delete that workflow in SharePoint Designer. If you do not, you will have problems with the workflow running actions twice. We ran into emails firing twice. I believe it was because it was running the workflow twice. Be careful of this issue.

Filter Blog

By date: By tag: