cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
esthomason
Nintex Newbie

Re: Capturing what changed

Jump to solution


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.

Reply