Hey Stuart Thomason‌, What I have done in the past. is to setup hidden column in my content type.

And then build the logic into the workflow to copy the content to the hidden column.. EG

Create Item, and it has a due date.. the first run the of the workflow will copy the due date to the hidden column and do what every else needs to be done. . Then on modify have a helper WF that kicks off when anything is modified. Set the logic in this WF to check the current values of the Due date and the one in the hidden column. If different, well you know that the initiation user just modified the due date and the appropriate actions can be taken (Notify project owner, notify manager, change reminders, send update to project server etc etc etc.. )

Thanks for the reply.  I believe this could do the job but it seems like a workaround.

If NWF can detect that a specific field has changedand even offers the option to look for such change as a condition of starting the workflowthen it would seem what I need exists already. And without the need to duplicate the information as you've done. I've attached a copy of those conditions and want to know where Nintex stores those with (previous value) and how to get at them.

Is this a secret that cannot be unlocked?

NWF$ is jQuery in disguise. It uses standard browser Document Object Model events which are fired when something changes in the memory of the client browser. Therefore, you can get the initial values from NWF$('.your-class#your_id').val() for example.

Thanks, Alexey.  Probably too sophisticated of an approach than I want to take because the person taking ownership of the workflow later would have no idea how to maintain or even understand this. For this reason I need to keep things as intuitive and simple as possible since our corporate workflow support infrastructure is still evolving.

Hey Stuart,

I just posted this : Nintex Workflow - What Changed UDA - Vadim Tabakman

I like Dan's idea.  This is just another way of doing it

cheers,

Vadim

Impressive. Not for the timid developer but I like the broad possibilities this exposes, particularly when audit trail requirements exist. Obviously this will take some effort to get working right, which I'm going to try after I go buy a bag of courage and a block of time.

Seems my hope for a straight-forward option are dashed but that's ok. For now, I'll pursue the suggestion Dan offered and then look to a develop a more robust and reusable option like you have on your blog.

Stu From: "vadim.tabakman@nintex.com" <community@nintex.com>

To: Stuart Thomason <esthomason@yahoo.com>

Sent: Thursday, January 8, 2015 3:09 PM

Subject: Re: - Capturing what changed

Capturing what changed

reply from Vadim Tabakman in Dev Talk - View the full discussionHey Stuart, I just posted this : Nintex Workflow - What Changed UDA - Vadim Tabakman  I like Dan's idea.  This is just another way of doing it  cheers,Vadim

This email was sent by Nintex Community because you are a registered user.

You may unsubscribe instantly from Nintex Community, or adjust email frequency in your email preferences

Hi Stuart,

I do very much like Dan's suggestion.  It is a lot easier than what I have built out.

With my blog post, I broke it up into User Defined Actions.  You don't really have to worry about the logic itself.  Although I do recommend you get a feel for it.

Instead, when it comes to your workflow, you simply drag the User Defined Action on the workflow, and it will do all the heavy lifting for you and let you know what fields have changed, and what their previous values were.

The only two requirements are:

1. add a field to your list called "ChangeXML" - text

2. Before you publish the two UDAs, make sure you update the Call Web Service action to use the credentials, or preferably a Workflow Constant, that would work in your environment.

Once you've published the UDAs, anyone can use the UDAs and they won't have to build all that logic.

UDAs are great for black boxing somewhat complex logic.

I hope you find a solution that works for you.

cheers,

Vadim

Will changing the content type used to collect and act on list fields affect an existing workflow? That is, if I create a custom content type with the hidden fields described above, will I need to revisit all my workflow items to ensure its looking for the right information? That is, will I need to reassign the references that are leveraged? I know SharePoint does some things with list IDs and the like that screw things up when substantive changes are made.

Changing a content type, shouldn't affect the workflow, unless the workflow is looking for fields that no longer exist on the list.  If the fields are still there on the list, but the items content type changes to something else, then it'll be fine.

cheers,

Vadim

In the end, I found the use of collection variables to solve my specific problem proved too complex and quite confusing, particularly when laying in the use of indices. Instead, I leveraged a combination of approaches found within existing documents or blogs to meet the need.  One thing that's clearly needed is a more fundamental guide to the use of collection variables and using an index, but I'll save that conversation for later.

The Problem Statement

Be able to track one or multiple changes to a set of separate fields of different types within a single list item as the item is modified.

How This Was Resolved

1.  Create the hidden fields that hold the original values so that change comparisons can be made, as mentioned by Dan in the first part of this thread.

2.  Set the workflow start condition to meet your specific situation and conditions.

3.  In the order most appropriate for your list item or needs, start your workflow with 'Set a condition' to compare a specific field to the copy (original) version of that field. If they're different, add the appropriate actions to that condition. I:

• Increment a counter to flag that a change was detected (used later in the workflow)
• Use 'Set a variable' to copy into a reusuable varible that captures the before and after state
• Use the 'Build string' task to add this into a table that will be used later in a notification
  • {WorkflowVariable:varItemChangesAggregated}<tr><td width="20%">{WorkflowVariable:varContactType}</td><td width="40%">{WorkflowVariable:varContactBefore}</td><td width="40%">{WorkflowVariable:varContactAfter}</td></tr>
  • Notice the changes simply get added to the exist variable, a technique spelled out in Dan Stoll's  tutorial found here.
• Use 'Set field value' to then update the copy to the new value so future changes can be detected
• Log the change in the history list

4. Repeat (3) for each field to monitor. Because you're adding to the string with each iteration, you can re-use the before and after variable.

5. Now, there was one field that intentionally starts blank and then gets updated when an attorney is assigned to the work. Because notifications and a task are already sent when that attorney is to be and is assigned, it's unnecessary to take any actions or send any noticies unless other changes are also made. Hence the use of the counter.

• When the workflow gets here it checks to see if the original value is blank. If it is then I capture that (create and set a variable to 'Yes').
• Increment the counter
• Later near the end, using a 'Run if', if the change counter = 1 and the var above is 'Yes' then I know only the attorney assignment was made and I can stop the workflow.

6. After running through each of the field comparisons, use a 'Run if' to determine the change counter is > 0 whether anything (after checking whether it was only an attorney assignment as described in 5 above.

• Build a new string to actually construct the table, again using the technique described here.
• Add any other actions needed, such as notifications or what have you.

Summary

One concern I had with using collection variables was with simplicity.  They are not easy to explain to people without a programming background, and meaningful ("late beginners") documentation and training material is in short supply. It's either too basic or too complicated, such as showing their use with web services or SQL queries. I got the coll vars to populate but never did crack the code on how to extract the data afterwards.

While there may be more efficient methods to solve this problem, I find my approach is easy to reconstruct, explain, and maintain.