How to show/hide specific columns in the ‘Item Properties’ panel displayed in the Nintex task edit form?



In Global Settings for Nintex Workflow in Central Administration, there is a setting called Task form properties view – the default value is Workflow Task View.

If a view of this name is found on the list or library the workflow is running on, then only the fields specified in this view will be displayed in the item properties panel.


A Nintex workflow task approval form has an Item Properties section that will show all the columns from the current item in a list/library from where the workflow is running.  When you have more columns / don’t want to show specific column from the current list item in the Item Properties panel you can show or hide based on our requirement.

To do that follow the below steps:

  • Go to the list/library where the workflow is attached.
  • Open and modify the “Workflow Task View”.  If this view does not exist, create a new view with the name “Workflow Task View”.
  • Add or remove the necessary columns, then click OK to finish.

The Item Properties panel on workflow task edit form will now display the columns in the Workflow Task View.


Important Notes:

  • In the Item Properties Panel, we cannot remove / hide the “Workflow Status” column and it will be the first item in the Item Properties panel.
  • Workflow Task View has to have at least one column in the view.


When the user clicks on any of the workflow tasks list item created by Nintex Content Type, it takes to the Nintex approval page for approving/rejecting.  I would like to open the actual SP list item for which the workflow task is created instead of the default Nintex WF task list item or to open a custom page with query string values


Item name URL: Specifies where the user is direct to when they click on the list item name in the web part. 

  • Task display form: Directs to the view page of the task item. Please note: The default view form for ‘Request approval’, ‘Request review’ and “Assign a Flexi task’ has the same behaviour as the edit form.
  • Task edit form: Directs to the edit page of the task.
  • Item display URL: Directs to the item that the task is associated to.
  • Custom: Specify a custom page to direct to. The following place holders can be added to the query string:

{TaskListID}: The GUID of the task list.

{TaskID}: The ID of the task item in the task list.

{ListID}: The GUID of the list that the workflow associated to the task is running in.

{ItemID}: The ID of the item that the workflow associated to the task is running on.


  • Edit the Nintex My task webpart
  • Go to Item URL Settings and change the Item name URL to Custom and pass the URL you wish to navigate with the Query string


Business Requirement

We have a nintex workflow, where in user EDRTest1 will fill the form. So EDRTest1 is the workflow initiator. Once the form is submitted by EDRTest1 we have to set read access to the EDRTest1 and set the contribute permission to user EDRTest2 on that item. Then a task will be assigned to the user EDRTest2 using assign flexi task action. After EDRTest2 approves/rejects the task we have to update an item.


How many of you know update item action would execute under the permissions of the initiator?

The workflow runs as the user who initiated it because this is the way Microsoft designed SharePoint workflow. We cannot change this behavior.

So in this workflow after EDRTest2 task approval, update item action is trying to update the current item with the read access to EDRTest1.

Because of this you will get the access denied problem with the below error.

“The workflow could not update the item, possibly because one or more columns for the item require a different type of information.”

How to solve this issue?

  • Drag on a “Call web service” action instead of update item
  • Configure the url to be your site url/_vti_bin/lists.asmx.
  • Click the padlock icon next to the username field and select the credentials defined above. (Be sure to select a user has contribute access to the item)
  • Press ‘Refresh’ next to the web method drop-down box.
  • Choose “UpdateListItems” from the list of available methods.
  • Click the SOAP Editor button option
  • Paste in the following XML. This particular example updates a field called ‘Status’ to be “Approved”. Note it uses references to define the list name and the ID of the item to update.

 <?xml version=”1.0″ encoding=”utf-8″?>

<soap:Envelope xmlns:xsi=”; xmlns:xsd=”; xmlns:soap=””&gt;


<UpdateListItems xmlns=””&gt;



<Batch OnError=”Continue” ListVersion=”1″>

<Method ID=”1″ Cmd=”Update”>

<Field Name=”ID”>{ItemProperty:ID}</Field>

<Field Name=”Status”>Approved</Field>







Impact of this approach

This approach will change the modified by user value with the user name credential which we are passing to this web service action. But our requirement is to see the last modified by user as EDRTest2.

So what is the work around?

If this is the case the only other option would be to give the user permissions to the item via set permissions action, then a commit pending changes, then the update and then another set permissions action removing the permissions.

Business Requirement

Our requirement is to create sub-sites under the site collection based on user request using nintex workflow.  We have attached this nintex workflow in the request form. So whenever an item created to this list, our workflow will run and create a sub-site.

Since the workflow is running with the current logged-in user, it is adding the current logged-in user with full control in site permissions in the site which is created by the workflow. But customer requirement is to remove the current user permission given directly to site. So we wanted to remove the logged-in user from the site once the site is created.

To do this first we have to check the exception in the create site action, if no exception we have to remove the user using RemoveUserFromWeb web method of usergroup.asmx web service.

We wanted to configure this web service action with workflow owner identity so we tried to use Action Set for this. But when we tried to configure the action set the “Run as workflow owner” option was disabled.

This is our development scenario. Please find the screen below


But we solved this by configuring the Service Admin account in Override credentials section of the Create Site action.

Use of Override credentials 

The site will be created using the current security context of the workflow by default.  This can be the rights of the initiator or the rights of the workflow owner.

If an override username and password is provided, the workflow action will use the permissions of the provided account to create the site instead.

Why “Run as workflow owner” is disabled in Action Set? 

This is an expected behaviour of Action Set control. Only actions at the root path of the workflow will have the Run as Workflow Owner option.  If you have an action in any branch, this option will not be available.

What is Task delegation?

The most valued feature of Nintex Workflow is the “Task delegation”. With task delegation, a user can delegate his task to someone else. If the task owner feels that this task is not relevant to me, he/she can delegate the task. When a user is in out of office mode, he/she can setup the task delegation feature as well.

Problem / Bug

Nintex Version: Nintex Workflow 2010 (

We have a nintex workflow with delegation functionality. Initially the task is assigned to user “Radhika Radhakrishnan –CNTR”. Once the task is assigned, this user will get the task notification e-mail. In this e-mail we have configured the nintex provided variable “{Common:ApproverName}” to show the display name of the task owner/approver.

We have configured the nintex provided common variable “{Common:DelegateUrl}” in our task notification e-mail. So that the task owner/approver will click on this link and go the delegation page without opening the task edit form when he/she feels this task is not relevant to me.

Now the user “Radhika Radhakrishnan –CNTR” delegating the task to “Joseph Velliah –CNTR”. At this point of time the same task notification will be sent to the new task owner with the delegator’s comments.

The problem what we faced is; when the task is delegated to “Joseph Velliah –CNTR”, the nintex provided “{Common:ApproverName}” is not changing the display name of the newly assigned task owner. It’s still showing the old approver name in our task notification e-mails.

Please find the screen shot below for the same:



We raised this issue to nintex we got the below response:

“We can confirm that we have replicated this behaviour and it has been raised as a bug. Currently due to the nature of the bug there isn’t a work around to resolve this behaviour in the short term unfortunately”.

“Currently we cannot give a direct time frame to when this issue will be resolved as the bug resolution process can be lengthy and vary dependent on the solution required, code development and testing”.

So Let us hope this bug will be fixed in their next build / version.


User requirement is to show the progress of a SharePoint Workflow Request in a graphical display to make the end user to understand more easily.


You have followed the following steps to achieve the above mentioned requirement. The request status was created and updated with the help of an InfoPath form, and I have used a 3 level approval Nintex Workflow which will start when an item is created and modified.

The Request Progress Bar is built by the Workflow in the background at run time, one status image which is used at that starting point of the workflow(that is when an item is created), and the remaining Request Progress Bar images are calculated based on the status change.

To map this, I have created four individual images, one for each stage in the process. Example images are included below.

Status 1: Submitted statusbarlevelfirst

Status 4: Completed statusbarlevelfour

These images were uploaded into the Images library and the mapping list was created as shown below: mapping

The Workflow will build the appropriate HTML to show the status bar based on the status change. Nintex Workflow is used to generate this HTML as shown below.

The HTML output generated by the workflow is shown below:

This HTML content is now updated by the workflow on a multiline plant text. But when we view this in SharePoint list view through the browser it will not get interpreted by the browser as an image.

From Christophe’s post I came to know that using CEWP we can convert the plain HTML content into browser understandable HTML content. To do this, you have to add a CEWP at the bottom of the page where you want to show the status and paste the following script into the HTML source editor.

var theTDs = document.getElementsByTagName(“TD”);
var i=0;
var TDContent = ” “;
while (i “) >= 0)) {
theTDs[i].innerHTML = TDContent;
function ExpGroupRenderData(htmlToRender, groupName, isLoaded) {
var tbody=document.getElementById(“tbod”+groupName+”_”);
var wrapDiv=document.createElement(“div”);

var theTBODYTDs = wrapDiv.getElementsByTagName(“TD”); var j=0; var TDContent = ” “;
while (j “) >= 0)) {
theTBODYTDs[j].innerHTML = TDContent;

So, with the help of this script the Request Status Bar now displays the image. Thats it 🙂

final output


I am trying to read the XML data from an InfoPath form which is located in a form library. I am using the Nintex Query XML action and passing a XML file URL to the form that I want to read. When I run the workflow, I got the following error:

“Error processing XML. The remote server returned an error: (401) Unauthorized.”


This is because we have InfoPath Forms Services in the farm environment, the request for the InfoPath xml file was getting redirected.

Upending  “?NoRedirect=true” at the end of the URL to the XML file as a query string stopped the redirection and allowed me to read the XML data from the InfoPath file.

Check this useful info from msdn – How to: Use Query Parameters to Invoke Browser-Enabled InfoPath Forms?