How can we improve Nintex Workflow?

Get previous field value in workflow

As start workflow option to start a workflow you can set the "value differs from the old value" option. Nintex Workflow obviously has access to this information. Within the workflow you can not load the previous value into a variable or something else. That would be nice.

Actually you have to use multiple hidden fields storing the previous value to use in for workflow porposes.

381 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Philipp Hammer shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Open for voting  ·  Jon Hardy responded  · 

    Without going into the technical detail; the previous value made available in conditional start is actually the current value just before any updates are made to the item. When the item is updated, we lose the ability to get the value prior to the update.

    To restate the workaround as indicated in the idea; create an additional column in the list or library and update this with the current value of the column of interest. Then when the actual column is updated, the previous value is still available in the additional column. Of course one need not make this additional column visible in the view or Form so the users are not confused.

    10 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Jonathan Sterner commented  ·   ·  Flag as inappropriate

        This was so powerful from the 2013 version of NINTEX. It is also clear then the NINTEX DEV team is having some issues adding all of the old features to the online version.

      • K Mikesell commented  ·   ·  Flag as inappropriate

        When using Site Collection Reusable workflow it is not possible to run on condition, so it would be necessary to know the previous field value. Cannot use conditional start. If version history is enabled on listitem you have all of the previous values.

      • Naval verma commented  ·   ·  Flag as inappropriate

        Suppose a workflow is having previous value condition check in conditional start(creation/update). For this we need to add additional column to store previous value of the given column and we also need an extra workflow to continuously update that additional column when item is updated or created. This additional workflow needs to start first and must update the previous value column before the main workflow starts.
        How to achieve this?

      • Mark Uden commented  ·   ·  Flag as inappropriate

        I also find it hard to understand why this wouldn't be a feasible function. If a workflow can be initiated based on a change in a particular field, surely it must be possible to retain the previous values in some way at that stage and make them available to the workflow? Alternatively, for lists with versioning, it should be possible to create an action that would make it easier to extract values for a field at each version into a collection variable.

      • Reed Carr commented  ·   ·  Flag as inappropriate

        Jon Hardy - This isn't making any sense. If the value is gone once the item is updates, and workflows that run when items are updated can detect the "previous value" even if the value changed during edit, then why are the values not available during workflow actions in addition to workflow initiation? Put another way. If the workflow initiation condition can evaluate after the value has changed, why can't conditions evaluate based on the same value(s) after workflow initiation? Many of the business processes I work on need this for not just 1 or two field, but dozens. It would be a huge value add to be able to access that data. Please add it to the path!

      • philipplucas commented  ·   ·  Flag as inappropriate

        How about writing the previous value in the database on item update to make it available afterwards. This will not be necessary if versioning is enabled on the list/library as one should be able to receive the previous value from a previous version. Additionally this could be an optional setting so safe some DB space if not required.

      • Kelly Linton-Selkirk commented  ·   ·  Flag as inappropriate

        This would solve so many synchronization issues. I have 5 services , each service has a main project window that creates the standard tasks for the services in a team task list. When tasks are completed I update the main project list for that service in order to track project completion. I use 2 fields from the team task list to identify the correct record in the project list. But if those 2 fields are changed I need to sync the change to the Project list but I cant do that without knowing the previous value to ensure I am updating the correct record.

      • Alan McCollough commented  ·   ·  Flag as inappropriate

        I would love to see this functionality, and you know it already exists. Workflows allow for testing against previous values as part of the conditional execution evaluation. Use that same logic in the "Set a Condition" action. Either that or provide a mechanism for assigning previous values to Nintex variables that we can use within the workflow.

      • Bart Evers commented  ·   ·  Flag as inappropriate

        We would love this functionality as we need to send an email with specific changes of an item to people. And we don't want to send all the fields because they don't know what has changed nor we want to send an email on any change.
        It is right there in conditional start after modified, when used in an action or even notification (send only changed fields), it would make lists more easy and we don't have to clone lots of columns (one for old , one for new value).

      • Peter Beyer commented  ·   ·  Flag as inappropriate

        Adding this functionality to Nintex would be extremely helpful as we often need to do an update to a list item when one or more field values are changed. We have other basic activity to do within an update and being able to know these field value changes would easily allow us to work any adjustments to our basic update code.

      Feedback and Knowledge Base