I have a list-based workflow and I would like to know if and when any of three specific fields are modified. The workflow settings allow me to listen for this condition, recognizing between fieldName and fieldName(Previous) but I can't seem to find the action that allows me to act on them.
What I'd like to know is how to capture and use the previous value. My intent is to display both in an email notification that one of the key fields has changed.
Solved! Go to Solution.
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.
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: "firstname.lastname@example.org" <email@example.com>
To: Stuart Thomason <firstname.lastname@example.org>
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
Reply to this message by replying to this email, or head to the message on the Nintex Community
Start a new discussion in Dev Talk by email or directly in the Nintex Community
Following Capturing what changed in these streams: Inbox
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
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.
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.