Skip navigation
All Places > Getting Started > Blog > Authors cazza162
1 2 Previous Next

Getting Started

22 Posts authored by: cazza162 Champion

This works with on-prem Nintex Workflow 2013

Problem:  Upon archiving a document I use workflow to update the date/time field of when the archive happened.  When user wants to un-archive the document, I need to clear the date field to display as empty (or null).

 

Resolution

  1. Create variable vDateArchivedDate as Date and Time with blank default date
  2. Use Convert value action input "1/1/0001" and store in variable vDateArchivedDate
  3. Use Set field value to update the date column with workflow data > vDateArchivedDate

We are yet to purchase Document Generation and forever finding ways to produce documents from list items.  We also don't have Print to PDF for Nintex Forms as we are on standard license, so it all requires rather a lot of work.  Some of the options we have considered in the past are, but not limited to:

  • Document library with columns and quick parts - passing the information from the list into the document library columns and using quick parts inside the document library to populate the document.  The workflow simply uses "create item" and adds the associated columns
  • Document library with content controls - use create item from the list to create a document in a library, and then use "update document" action in the workflow to update the content controls
  • SSRS reports - use reports to look at the list item data that can then be exported to word, pdf as required

 

I recently tried both document library approaches to create a document using a template from workflow and both kept giving me this error when opening in Word:

 

"We're sorry.  We can't open test because we found a problem with its contents"

Details:  No error detail available

 

I thought it was the order in which the document was being created and updated.  Or the information that was being passed in.  I raised a support ticket and we decided it was the table of contents causing the issue. This issue has recently been fixed so we upgraded workflow to no avail.  I wasted days and days and grew a few (more) grey hairs.  Then my lovely colleague and friend, Tosin, noticed that my document template attached to the document library was dotx format (word template).  This seems perfectly reasonable right?  Apparently not with this type of work.  I re-created my templates; one with quick parts and the other with content controls to be docx format.  And voila - they both work!  I haven't seen anyone mention anything like this on the community so I thought I should blog about it so that I can hopefully save others the stress I have had for the past couple of weeks (and also so that I don't forget next time I have a requirement like this).

Roll on the purchase of Document Generation!!

So I made a rooky mistake and thought I would share so that you can all see that I am only human too, and sometimes, no matter what experience you have working with certain technologies, oversights can be made...

I had a very old solution (not mine) that used an InfoPath form and a workflow that run on all updates with a Run if action at the very beginning checking if the email flag was checked.  This had been working fine for a long time but the customer reported that they wanted the form slightly changed.

In good old fashioned InfoPath style, it informed me changes had been made in the list that needed to be reflected in the form (and rather unhelpfully didn't elaborate on the changes).  I needed to add this change for the customer so I accepted and published.  User was happy for a day or so until they realised that one of the dropdown controls had become unbound...!

I won't bore you with the details, but here is what I did.

  • the column was missing for whatever reason in InfoPath
  • time was limited so I created an additional column in my list, and used that in the InfoPath form
  • Using quick edit, copied the data from old column to new column

 

All perfectly reasonable right?  But what did I forget...?  Oh yeah, that workflow that run on modify of every single item.  That particular workflow emailed about 50 important people in my organisation...  and I sent 65 of them!  (shudder).

So after 24 hours of sobbing and panic, I calmed down and realised that this mistake was a simple one; one anyone could have made.  No process in place would have prevented it as I simply overlooked it.

 

Feel free to make me feel better with your rooky mistakes in the comments below... 

Sometimes we have disconnected data in our form that we do not require in the underlying list, but may need as part of our workflow process.

In this example I show you how to utilise the very helpful Form Data available in Nintex Workflow to pull information from the form that submitted the data in the first place.

 

List Settings

  • Custom list with title field as standard called "FormDataDemo"

 

Form Settings

  • Customise the "FormDataDemo" list using Nintex Forms
  • Add Single Line Textbox control to the form with the following settings:
    • Name:  UnconnectedTextBox
    • Connected to:  Not connected
    • Data type:  String
  • Publish the form

 

Workflow Settings

  • New nintex workflow on list "FormDataDemo"
  • Start when items are created
  • Query XML action:
    • XML source:  XML
    • XML:  {ItemProperty:FormData}
    • Output 1 - XPath:  /FormVariables/UnconnectedTextBox
    • Store result in: New variable "vTextUnconnectedTextBox"
  • Log in history list:  vTextUnconnectedTextBox

 

 

Of course you are likely wanting to work with that value, not just log it to history list, but this was just for demo purposes and to help resolve a question asked on the community.

cazza162

Print friendly Nintex Forms

Posted by cazza162 Champion Sep 11, 2017

Without having Nintex Forms Enterprise and the handy "Print to PDF" functionality, we often spend a lot of time on workarounds for this.  My good friend and colleague Gary Powell-Jones came up with this solution that he has allowed me to share with you all:

Print friendly Nintex Forms

Designing the form

The form can be designed to allow items to not be printed (e.g. appear only on screen) or appear only when printed (such as a disclaimer).

For print only items, add a css class of printonly to the control or element

For no print items, add a css class of noprint to the control or element

Note that the JavaScript below will work even if there are no controls or elements with these css classes

Form custom JavaScript

Include the following snippet in the form custom Javascript. It adds a function called ‘PrintFormHtml’ to print the form, a function to hide print only elements when the form is initially loaded.

 

function PrintFormHtml(){

 NWF$('#suiteBar').hide();

 NWF$('.noprint').hide();

 NWF$('printonly').show();

 window.print();

 NWF$('#suiteBar').show();

 NWF$('.printonly').hide();

 NWF$('.noprint').show();

 return true;

}

 

NWF.FormFiller.Events.RegisterAfterReady(function () {

  NWF$(document).ready(function () {

   NWF$('.printonly').css('display','none'); //THIS HIDES PRINT ONLY ELEMENTS

  });

});

Print Button

Add a button to the form, using the JavaScript action. The action will be PrintFormHtml();. Optionally, the button can be made visible on the SharePoint ribbon using the standard Nintex settings

Operation

When the button is clicked it

  • hides the suitebar
  • hides items with the CSS class of ‘noprint’
  • shows items with the CSS class of ‘printonly’
  • calls the printer dialog

 

After printing, it resets the form:

  • showing the suite bar
  • hiding the print only elements
  • showing the no print items

I have been working with Nintex workflows for a long time now and have only just started using this action.  It is so simple but so powerful and has saved me doing this painful step in a lot of my workflows:

 

Scenario

I have a workflow that runs for all types of users entered into a list.  Most of the workflow is relevant to all types of users but there are some things that I would like to be done only if the user type is Employee.  Yes, I could use a Run If action, but I am using this fairly simple scenario to explain the filter action.

 

The Filter Action

As opposed to a Set a condition action where only one branch is executed, or a Run if action where the contents are run only on a condition being met, this action literally only executes the actions below it if the condition is met, otherwise the workflow is ended.  No need to add actions to a Run if container, or to add actions to one branch in a Set a condition action and an "End workflow" action in the other!

Action Configuration

Very similar to the Set a condition and Run if actions, you can specify:

  • Condition:  what you are comparing (i.e. current item, variable, metadata etc)
  • Comparison:  equals, not equals, contains, greater than etc.
  • AND/OR conditions

For my specific example I have the configuration as follows:

 

I have designed a lot of my previous workflows using the very first image on this post but will have to keep the filter action in mind going forwards as it does the same thing and is often overlooked!

Many of you, like me, will have seen and used this feature many times.  What does it do?  Well it allows you to add a shortcut to your start workflow page directly on the item context menu.

These are the settings you need on workflow settings:

 

This then, when the workflow is published, displays as such on the item context menu:

 

Now I have been using this awesome feature for many years and then Paul Crawford asked me why he seemed to be limited to only adding four workflows to the menu?!  I have never needed to add this many before so wasn't aware of any limitation... 

I won't pretend I solved it, because I didn't, but he came up with a quick fix that I wanted to blog about so that neither of us forgot this simple trick:

 

Rather than using Menu item position: 0, 1, 2, 3, etc

Have Menu item position: 100, 101, 102, 103, etc

Following on from the success of January 2017 Mission "What is your Nintex New Years Resolution", which was all about what bad habits you have when using Nintex that you would like to dispel of, we have created a positive spin in this months mission!

 

So what do you have to do to get the loot?  Simple really, share your quick top tip for any of the products in the Nintex suite, easy right?! 

 

top tip may

A simple couple of lines as a comment below about your top tip will do the job.  For your trouble, you pick up the badge pictured, and 100 points!

 

Why are we doing this?  In the hope that your top tip might be something that users in the community have never even heard about - and imagine if you could save them time and less headaches by simply sharing yours...

 

 

 

Here is mine:  Use the "Log in history list" action.  Simple enough I know, but for the first eight months of developing workflows I didn't know it was there and I used to bombard myself with emails trying to debug my workflow and get the values from my variables!

So I have had this blog post on my "to do list" for some time now and the list is now beginning to get scroll bars so I have to tackle it!  I have seen a lot of questions posted on the community (and asked in my workplace) about workflows incurring an error without much detail as to why this has happened.  The thing that I would always offer to anyone with these problems is to use the inbuilt error handing within Nintex workflow actions wherever possible.  Why?  Well a number of reasons actually:

  • If a workflow errors it notifies the initiator (unless those settings are changed).  Normally the initiator is a user in the business unaware of the design of the workflow, and sometimes unaware of the workflow altogether.  The last thing these users want is a ghastly email that says a workflow, that they may not be aware, has errored with some hideous details that they don't understand:

  • The details given when a Nintex workflow errors are sometimes completely non-descript and offer no help or direction in where you, as the workflow developer, should look to find the issue and resolve it.  An example of this helpful error is here:

  • OK sometimes errors in the workflow are the end of the world(!!) and will mean that the workflow will need to be terminated and started again.  However, sometimes, an error in an action wouldn't mean the end of the world and you might be happy to just catch and log the error without having to visit the workflow on the item, terminate it and restart it.

 

Actions with Error Handling

My understanding of the Nintex workflow actions is that the following all have error handling in their configuration (please correct me if I have missed any):

  • Call web service
  • Execute SQL
  • Find users by status
  • Get user status
  • Query BCS
  • Query Excel Services
  • Query LDAP
  • Query XML
  • Update XML
  • Web request
  • Convert document
  • Copy to file share
  • Copy to SharePoint
  • Create item in another site
  • Create list
  • Delete multiple items
  • Submit record
  • Update multiple items
  • Convert value
  • Add user to AD group
  • Create AD group
  • Create AD user
  • Create site
  • Create site collection
  • Decommission AD user
  • Decommission site collection
  • Delete AD group
  • Delete site
  • Enable Lync / OCS
  • Provision user in Exchange
  • Remove user from AD group
  • Update AD user
  • Create appointment
  • Create task

 

Configuring error handling

All of the above actions have in-built error handling available in the configuration of the workflow actions.  Error handling looks like this in the workflow action:

By default it will be set to capture errors = No.  You have three choices here if you want to catch errors:

  1. catch if an error occurred:  "Store error occurrence in"  a simple Boolean value that will indicate if an error occurred in the execution of the action.
  2. catch the details of the error:  "Store error text in" a text value for the error returned in the execution of the action
  3. catch both (my general approach)

So to use these options you need to create some variables to store this information.  I normally create a Boolean (yes/no) variable and a single line of text variable and configure my error handling as follows:

 

Note be sure to change "Capture errors" to Yes.

 

Dealing with errors

Well this is a very personal thing and entirely depends upon the design of your solution as to whether the error is a deal breaker or just something to be made aware of.  Generally if it's not a big deal I have a piece of my workflow directly after the action as follows:

This way the workflow will continue but I will be notified of the error returned.

If it is a deal breaker error, I would normally add an "End workflow" in that "Run if" after the email.

 

Workflow error notifications

By default the initiator will be notified if the workflow errors and has a status of "Error Occurred".  If this is not acceptable to you (which it never is to me), you can change these setting by navigating to Site Settings > Nintex Workflow > Workflow error notifications

Here I would change "Send notifications to the workflow initiator" to "No" and specify alternative email addresses to be notified instead.

 

How do you deal with errors?

I am interested to hear from you guys...  how do you deal with errors?  Do you use this built in error handling functionality?  What do you do when an error occurs?

Background

In our organisation we have the nintex workflow actions tightly controlled as follows:

  • Untrained users:  no access to any actions
  • Trained users:  access to subset of actions
  • SharePoint support users:  full access to all actions

The reason for this is governance (which I will get round to blogging about one day I am sure).  We do not allow the trained users any actions that can loop that with poor configuration could maybe bring down the environment or affect the performance in some way.

 

Problem

These trained users almost always have a requirement for a "reminder" workflow of sorts, to notify people when a document is due for review, or if a task is outstanding and x days overdue (like many users on the community).  Anyone on the community with this requirement will have been sent by me to my blog post Site Workflow - Document Review Date Approaching Reminders or to the solution on Nintex Xchange™ Document Review Reminder Process.  However, these users are not allowed any looping actions so are unable to use the for each and so, at the moment, have to come to SharePoint support staff to get the solution they require.

 

Solution - Site Workflow UDA

Inspired by Nintex Xchange™ and a UDA solution posted by Vadim Tabakman I decided to see if I could create a site workflow UDA whereby the UDA could do the looping for the user and it therefore wouldn't matter that they do not have access to the actions inside the UDA.  This is one of the best things about UDAs - it's a fantastic way of empowering your users to do something cool without "letting" them develop it themselves.  This way you have control of these more complex actions and can be confident that the environment won't be impacted by their configuration.  Well, if they do impact environment performance, then you know who is to blame - haha.

I called the UDA "Notification Date Reached UDA" and configured it as follows:

Parameters:

NameTypeDirectionComments
List NameTextInputThe name of the list that the items need to be pulled from when meeting the date specified, I.e. "Procedures"
Date Field NameTextInputThe name of the date field in the {List Name} to compare with the specified date
Email SubjectTextInputSubject of email to be sent
Email To FieldTextInputThe name of the column used to locate the recipient of email
Email MessageTextInputBody of email to be sent
ErrorTextOutputTo be used to store any error messages
Number of Days AfterNumberInputIf date comparison is not for today, but for x number of days after the event
Number of Days BeforeNumberInputIf date comparison is not for today, but for x number of days before the event

 

Variables:

NameTypeComments
vCollReturnedIDsCollectionInside the UDA, the query list of the specified list name will return 0 or more items and store the IDs into the collection
vDateComparisonDate and TimeThe date calculated based on the parameters above to compare with the list and filter the returned items
vTextCurrentIDSingle line of textThe current item in the collection (stored as text for the CAML query) used to query the given list name to find the {Email To Field} value
vTextNotificationContactSingle line of textUsed to store the value for {Email To Field}

 

Workflow:

I do some checking of the "number of days after" and "number of days before" parameters.  If both are zero then it would indicate that the user would like to match for items where {Date Field Name} = today's date.  So in this instance I set variable value vDateComparison = Common:CurrentDate.  If both parameters are not zero then it would imply that the user either wants to send a notification x days before the {Date Field Name}, or x days after.  This logic does just that:

 

OK, so now we have our comparison date I go ahead and query the specified list matching where the specified date field = specified date.  I do this using CAML query and return the IDs into the collection variable vCollReturnedIDs:

Using for each to loop through my collection, I use the current item in the collection (vTextCurrentID) and query the specified list again to get the specified {Email To Field}. This is again done with a CAML query as follows and outputs the variable vTextNotificationContact:

Still in the for each I send an email to the variable value returned using the subject and message body specified in the parameters.  Job done.

 

Using this UDA

To use the UDA I created a brand new site workflow, added the UDA and configured it as follows:

and the list looked like this:

 

When I run the site workflow today (20/02/2017) I get three emails!

 

 

Flaws

Ok so this is early days and there are many! 

  1. The fact that I need to use the internal names in my parameters (because of the CAML query).  I don't want these users to loop for fear they don't understand looping, so do I think they will know how to find the internal name of a column?!
  2. This is only bringing back some dynamic data from the list - the rest is static.  This could be extended to suit and pull additional information about the item due for review - but there doesn't seem to one size fits all approach when I have no idea what sort of list it will be used on
  3. At this point I have only set it up for either a date before or a date after.  In reality most people want to remind before the date, remind on the date, and remind after the date!  This can be easily overcome.
  4. (enter yours in the comments)

 

The solution will be posted on Nintex Xchange™ shortly.

cazza162

Managing Workflow Tasks

Posted by cazza162 Champion Jan 5, 2017

I recently put together a slide deck to present to the team I am part of to offer understanding of the different ways to manage workflow tasks when offering support to users in the business.  The main driver for this is that we always get calls from users "never receiving" the email notifications sent from Nintex.  My thoughts on whether they are "not received" or more simply "deleted" shall be kept quiet here...  users eh!  Anyway, prompted by a question recently posted on the community I thought it might be a good idea to put the information in one place on here too.

 

Nintex Workflow Web Part - My Workflow Tasks

This web part can be added to a page in any site and can be scoped to look at tasks assigned to the logged on user as the site, site collection or farm* level.  This will include tasks assigned to SharePoint groups the user is a member of (only when individual tasks are assigned in the task config in the workflow action).

Nintex Workflow Web  Parts – Workflows I’ve Started

This web part can be added to a page in any site and can be scoped to look at workflows started by the logged on user in the current site, site collection or farm*.

Nintex Workflow Task Delegation

Task delegation can be set to site owner only (i.e. checkbox not selected on action to allow delegation), or delegation can be set to assignee and site owner (i.e. checkbox selected on action to allow delegation).

This is particularly useful for support staff to know when a call is raised that a process is held up by the wrong approver being selected, or the approver being unable to respond in a timely manner.  The fact that even when delegation is not selected on the configuration in the workflow the site owner can still do it is a little nugget of information that not all workflow designers know about.  I wrote a whole blog post on delegation so I won't go into it too heavily here - All things Delegation.

Also for support team awareness I mentioned the availability of long term delegation for approvers to turn on themselves before periods of absence where someone can be delegated to respond to tasks for a set period.  Of course if this period of absence if unforeseen, there is also the ability for support staff to set long term delegation for specified users.  This is also covered in the above blog post.

Task Aggregation in My Sites

As standard there is a link on my sites called "Tasks" which displays all tasks assigned to the user across all site collections.  This has to be direct assignment (i.e. not to a group you are a member of).  This is another way users can find all of their tasks in one place (similar to the nintex workflow web parts).

 

* Requires Nintex Workflow Enterprise version.

 

 

Further Reading / References

My Workflow Tasks

Workflows I've Started

SharePoint 2013: Task Management in My Sites

I had these notes stored from a couple of years ago - they helped me at the time with a problem I had been banging my head with for ages, but I haven't needed to use them since.  Not sure if any use to anyone, but in the process of getting all my blog posts in one place, and what better place than the Community

 

Believe it or not, this is not straight forward.  For this blog I will paint the picture.  I have a request list which uses Managed Metadata to store Business Units.  I have a list on another site which stores approved and completed items from the original request list.  On this list, the same Business Unit Managed Metadata column is used.  I tried using the "Create item in another site" action in Nintex Workflow but could not just simply map the field from one list to the other.  Instead I had to query the TaxonomyHiddenList of the target site collection to get the ID and GUID for the term.  To find the hidden taxonomy list, simply use "Lists/TaxonomyHiddenList/AllItems.aspx" on the end of your URL after the site collection.

 

There can be multiple terms for the same value in the TaxonomyHiddenList (if it exists in a few of the term stores), so you need to be able to pass the IdForTerm in when querying the list which is achieved by using a regular expression action.

 

Firstly I use the Set Variable action to store the value from the managed metadata field in the original list into a variable.  In this example I called it vTextBusinessUnitMM

Then I used a Regular expression action to find the "IdForTerm".  The configuration below changes the variable value above to the format of the IdForTerm and stores it in the same variable.

 

 Then I use Query list to query the TaxonomyHiddenList of the target site to get the ID and the IdForTerm.  I store the returned values in variables.

Finally I use the Build String action to format the values returned:  ID;#Value|IdForTerm.  This is what needs to be passed to the destination site when inserting or updating an item with Managed Metadata field.

 

cazza162

All things Delegation

Posted by cazza162 Champion Aug 19, 2016

A question was posted about delegation the other day and it made me realise that there is quite a lot to know about delegation that can be picked up along the way, so thought I would blog about everything I have learnt to date!

Tasks that allow delegation:

Assign flexi task

In the configuration of this action the workflow developer has a few of options for delegation:

Action tab – Allow delegation

AFT-ActionTabDelegate.PNG

The help for this option states:

When this option is selected, the assignee at runtime can delegate the task to another user. Changing the 'Allow delegation' option on the 'Action' screen is the same as changing the 'Allow delegation' option for all assignees on the 'Task Notification' ribbon option.

This means that when the task assignee opens the task to respond, they will see a link to delegate the task to someone else.  They can choose this person on a task by task basis.  The link will look something like this:

DelegateTaskLink.PNG

Task Notification tab – Allow delegation

AFT-TaskNotificationTabDelegate.PNG

The help for this option states:

When this option is selected, the assignee at runtime can delegate the task to another user.

This means that when the task assignee opens the task to respond, they will see a link to delegate the task to someone else.  They can choose this person on a task by task basis.

 

Escalation tab – Escalation type = Delegate task

AFT-EscalationTabDelegate.PNG

The help for this option states:

Delegate task will re-assign all pending tasks to the nominated user after the specified time.  Escalation occurs after all reminders have been sent and the specified "Time to escalation" has elapsed.

 

Assign to-do task

In the configuration of this action the workflow developer has a few of options for delegation:

Action tab – Allow delegation

ATDT-ActionTabDelegate.PNG

The help for this option states:

When this option is selected, if the assignee field of the task is changed, Nintex Workflow will record the change as a task delegation and the new assignee will receive the Response Required Notification. If this option is not selected, Nintex Workflow will not track the change to the assignee and Nintex Workflow reports and web parts will not reflect the new assignee.

Task Notification tab – Delegate task when 'Assigned To' changes

ATDT-TaskNotificationTabDelegate.PNG

The help for this option states:

When this option is selected, if the assignee field of the task is changed, Nintex Workflow will record the change as a task delegation and the new assignee will receive the Response Required Notification. If this option is not selected, Nintex Workflow will not track the change to the assignee and Nintex Workflow reports and web parts will not reflect the new assignee.

Escalation tab = Escalation type = Delegate task

ATDT-EscalationTabDelegate.png

The help for this option states:

Delegate task will re-assign all pending tasks to the nominated user after the specified time.  Escalation occurs after all reminders have been sent and the specified "Time to escalation" has elapsed.

 

Request approval

Action tab – Allow delegation 

RA-ActionTabDelegate.PNG

The help for this option states:

When this option is selected the assigned approver at runtime can delegate the task to another user.

This means that when the task assignee opens the task to respond, they will see a link to delegate the task to someone else.  They can choose this person on a task by task basis.

Task Notification tab – Allow delegation

RA-TaskNotificationTabDelegate.PNG

The help for this option states:

When this option is selected the assigned approver at runtime can delegate the task to another user.

 

Request data

Action tab – Allow delegation

RD-ActionTabDelegate.PNG

The help for this option states:

When this option is selected, the user whom the task was assigned to will have the option to reassign it to another user.

This means that when the task assignee opens the task to respond, they will see a link to delegate the task to someone else.  They can choose this person on a task by task basis.

Escalation tab = Escalation type = Delegate task

RD-EscalationTabDelegate.png

The help for this option states:

Delegate task will re-assign all pending tasks to the nominated user after the specified time.  Escalation occurs after all reminders have been sent and the specified "Time to escalation" has elapsed.  

 

Request review

Action tab – Allow delegation

RR-ActionTabDelegate.PNG

The help for this option states:

When this option is selected the assignee at runtime can delegate the task to another user.

This means that when the task assignee opens the task to respond, they will see a link to delegate the task to someone else.  They can choose this person on a task by task basis.

Task Notification tab – Allow delegation

RR-TaskNotificationTabDelegate.PNG

The help for this option states:

When this option is selected the assignee at runtime can delegate the task to another user.

 

Delegate workflow task

This action is designed to work alongside “Request Approval”, “Request Data” and “Request Review” actions by delegating those tasks (using their Action ID) to a specific user.  As example where this might be used if after a specific delay an assigned user has not responded, the task can be delegated to another user such as their superior.

DelegateWorkflowTask.PNG

This delegation can applied to all pending tasks, or to the first pending task dependent on the requirement.

 

Delegate page:

DelegateTask.PNG

Delegate:  Use the address book or enter the name of the person you wish to delegate the task to.

Comments:  Required field.  Use this to add comments to be sent to the Delegate explaining why the task has been delegated to them.  This information is added to the notification sent to the delegated user.

The task will be updated to reflect the delegated assigned user.  I have noticed that this always changed the status of the task to “In progress”.  

 

Personal Delegation

A user can set up delegation for a period of time to be scoped at different levels.  This is accessible from the logged on user name dropdown, selecting Nintex Workflow 2013 and Task Delegation:

TaskDelegation.png

Choose "Delegate tasks to a user between specific dates":

 

PersonalAddDelegation.PNG

From this screen the user can select the dates for which the delegations should occur and who should be delegated the tasks during that period.  The scope can be changed to apply only to tasks from the current site, or the entire SharePoint farm.

NOTE:  If a task is delegated to a user, the long term delegation is ignored (so isn’t re-delegated).

This ability depends on the Global Setting “Long term delegation

Site administrators can set up long term delegation for other users if the Global Setting “Site administrators long term delegation” is enabled.

 

Call web service for Delegation

Using the workflow.asmx web service you can surface the DelegateTask method to delegate a task.

This is outlined in more detail by Dan Stoll here:

https://community.nintex.com/community/tech-blog/blog/2016/04/01/the-gentle-art-of-delegation

 

NWAdmin Operations for Delegation

Information taken from the PDF located here:

https://community.nintex.com/docs/DOC-1026

DelegateAllTasks

This operation is used to reassign all tasks from one user to another. It can be scoped to a single site, or the entire environment. Note that tasks can only be delegated to individual users, not groups.

Note: This operation uses the Nintex Workflow web service, and requires credentials to connect to the web service.

Usage

NWAdmin.exe -o DelegateAllTasks -currentUser domain\username -newUser domain\username [-siteUrl urlToSharePointSite] [-sendNotification] [-comments] [-username username] [-password password] [- domain domain]

Parameters

nwadmin.PNG

Site Owners and Delegation

Even if you have not selected delegation on your actions, site owners should still be able to see the link to delegate a task on behalf of another user.  This is especially handy if someone goes out on leave or sick and the workflow cannot continue without delegation, the site owner can just in there and delegate the task on a case-by-case basis.

 

So as you can see there are a lot of options for delegations in Nintex Workflows, and I am sure I haven't covered all of them!  Feel free to comment and let me know if I have missed anything! 

I recently had a requirement where I had two lookup fields on my Nintex Form where one had to be filtered by the other, and both had to allow multiple selection.

I thought that this was going to be really difficult to implement, and was using all sorts of disconnected controls in order to try and achieve the result, and then I discovered that Nintex Forms just works when you use list column types "Lookup".

Wanted to share with everyone how powerful this was, and hoped it may help with this thread:

https://community.nintex.com/message/45415?et=watches.email.thread#comment-45415

 

So I have the following lists:

Custom List:  luDivisions

Fields:  Title

luDivisions.PNG

Custom List:  luBusinessUnits

Fields:  Title, Parent Division

Parent Division = Lookup to luDivisions:Title

luBusinessUnits.PNG

 

Finally I have my main list, where I want to use the Nintex Form to capture data:

Custom List:  Demo Lookups

Fields:  Title, Division(s), Business Unit(s)

Division(s) = Lookup to luDivisions:Title, allow multiple

Business Unit(s) = Lookup to luBusinessUnits:Title, allow multiple

DemoLookups.PNG

 

Then in Demo Lookups I customise my form using Nintex Forms designer.

The out of the box form gives me this:

oobform.PNG

 

So I want the Business Unit(s) to be filtered by the Division(s) so I double click the control for Business Unit(s) and add the following configuration:

FilterControlSettings.PNG

 

Now when I add a new item, the Business Unit(s) list is dynamic based on the Division(s) list.  Seems so clever yet is so simple!

Form1.PNG

Form2.PNG

I appear to come across the same scenario time and time again.  A request of some sort is made.  It goes through one or multiple lines of approval.  Whilst it is in the approval process the item is set to read only so that no amendments can be made while it is in review.  Upon final approval, the item/document is updated to reflect the approved/rejected status.  The permissions on the item at that point do not allow for this update.  Or upon approval an item is added to another list that the “initiator” does not have access to contribute to.  So I thought I would discuss the different options that can be used for dealing with permissions inside a workflow:

Set item permissions

This action allows you as the workflow designer to decide to inherit or create unique permissions on the current item on which the workflow is running.  This works well in state machine workflows where the permissions at each state need to change (i.e. the current approver needs the ability to update an item whilst everyone else only has read access).  You can choose to inherit the permissions from the parent or stop inheriting as well as choosing to keep or delete any current item permissions (i.e. when someone needs adding to the permissions at a certain point).

SetItemPermissions.PNG

Pros

I like this action because you can define exactly which roles/people/groups can have access to an item at any given time during the workflow process.

Cons

If a workflow fails for whatever reason the permissions stay at the most recent set item permissions action.

It is difficult to control permissions to lists when the items have item level permissions.

Run as Workflow Owner

The action set action allows us to choose a configuration option of “Run as workflow owner”.  This means that all actions inside the action set container will run under the permissions of the account which published the running workflow.  This is a great workaround when you know that you have God-like permissions to do everything on your farm and don’t want to give any users access to certain lists of libraries.

ActionSet.PNG

Pros

Saves using the Set item permissions action and doesn’t impact on the item level permissions of the item the workflow is running on

Cons

This doesn’t work inside a state machine workflow; only a sequential workflow.  So if you are running a large process that you have designed with a state machine where the final approval means an item update, you cannot access the “Run as workflow owner” checkbox inside action set when it is placed on a state machine branch.

Created By and Modified By are always the same person for all instances of the workflow.  When running as workflow owner the credentials of the person who published the workflow are used.  This means that any items created or updated are effectively done by that person so you cannot quickly see who ran the workflow in the first place (and if you work in a blame culture, you will find people quickly asking you why you updated or modified an item!!).

If the workflow publisher leaves then the credentials and permissions will no longer work.

 

 

Call web service

An alternative way to deal with inserting and updating items without giving the initiator access to do so is to use web service calls which can run as a specified account.  As long as the account the web service is using has the permissions to perform the actions you are asking of it then there are no worries around who the initiator is and what permissions they may have.

Call Web service.PNG

Pros

Do not have to worry about the permissions that the initiator may have to perform the insert or update required.

Cons

A lot trickier to configure to achieve the same result.  I find that the Call web service action quite tiresome (because I don’t use it very often) so have to read up on what services and methods to use and spend a lot of time testing.

Again, if the account that the web service is using becomes locked out or deleted then the workflow will fail.

 

There are a lot of options for dealing with permissions in workflow.  I lean more heavily to the Set item permissions action although it doesn’t sit comfortably with me.  I would be really interested to hear your approaches here so please leave some comments and I may well revisit and update this blog post with your best practices.  

Filter Blog

By date: By tag: