How to Set a User Lookup Field to the Current User using a Workflow Process in Microsoft Dynamics 365 - Part 2 | Magnetism Solutions | NZ (Auckland, Wellington, Christchurch and Dunedin)

Dynamics 365 is Better with Infinity Buttons. Try it for Free for 30 Days

How to Set a User Lookup Field to the Current User using a Workflow Process in Microsoft Dynamics 365 - Part 2

Colin Maitland, 25 October 2017

In my previous article, I demonstrated how to configure a Workflow Process to set any User Lookup field to the Current User using the standard Modified By field to set a custom field named Last Updated By.

image

In this article, I provide additional important information that you should be aware of.

Real-Time Workflow Processes

When using a Real-Time Workflow Process, there is an option to configure the Workflow Process to automatically start either after or before a Contact has been updated.

It is important to ensure that the Workflow Process is configured to automatically start After, instead of Before the designated fields on the Contact are changed otherwise the Contact Modified By value used to set the Last Updated By field will contain the previous User who modified the Contact, instead of the current User. This will result in the Last Updated By field being incorrectly set.

image

Here is what happens when the configuration for automatically starting the Workflow Process is set to Before the Contact is updated; i.e. Before Record Fields Change.

image

When creating a new Contact the Last Updated On and Last Updated By fields are correctly set to the current Date/Time and User.

image

However, if another User now updates one of the designated fields on the Contact the Last Updated By field is incorrectly set to the User who previously modified the Contact rather than to the current User.

e.g. incorrectly to this …

image

… rather than correctly to this …

image

Background Workflow Processes

If using a Background Workflow Process, there is no option to configure the process to automatically start Before a Contact has been updated. A Background Workflow Processes that is configured to automatically start when a Contact has been updated will always start After the Contact has been updated.

image

Real-Time vs Background Workflow Processes

In this example used in Part 1 of this article, I chose to use a Real-Time Workflow Process instead of a Background Workflow Process to ensure that the update of the Last Modified On and Last Modified By fields was immediate.

This has the following benefits:

  1. The Workflow Process starts immediately. If a Background Workflow Process was used there is a short delay between when the designated fields on the Contact were updated and when the Workflow Process starts. It is possible within this short time for some other User, or process, to update other fields on the Contact resulting in the Modified By field being changed to that other User. Then, when the Workflow Process populates the Last Updated By field it will be set to that other User, rather than to the current User who updated any of the designated fields.
  2. The Last Modified On and Last Modified By fields if displayed on the form are immediately updated and visible without needing to refresh the form. If a Background Process was used the form would have to be refreshed before the changes to these fields would be displayed.

Other Scenarios

Sometimes you may encounter a scenario where you want to use a Workflow Process to set a User Lookup field on a record to the current User when there has been no corresponding creation or update of the record on which the User Lookup field is located and therefore no corresponding update of the Modified By field.

This may be because:

  1. The Workflow Process is started On-Demand, or manually, by a User without any corresponding changes being made to the record against which it was started.
  2. The Workflow Process is automatically triggered by the creation or update of some related record such as an Activity, Case or Opportunity etc. instead of by the creation or update of the record on which the User Lookup field exists.
  3. The Update step in the Workflow Process occurs after a Wait Until or Parallel Wait step; i.e. a Timeout period. Note: This scenario only applies to Background Workflow Processes.

In this situation, one of the following two approaches might be used to ensure that the User Lookup field is correctly set to the current User.

First Approach

Configure the Workflow Process with two successive Update steps as follows:

  1. Configure the first Update step to change an unused field. This change to the unused field will also cause the Modified By field to be updated. Note: You must ensure that this step always makes a change to the field. You can do this by selecting an unused Date/Time or Text field and configure the Update step to set that field to the Process Execution Time; e.g. for a Contact you could set the unused Pager field to the Process Execution Time. This is a text field. Note: If using an unused Date/Time field the Format must be Date and Time rather than Date Only.image
  2. Configure the second Update step to set the Last Updated On and Last Updated By fields from the Process Execution Time and the Modified By field.

image

This approach works well if you don’t mind making two successive updates to the record.

Note: If you are using a Real-Time Workflow Process, ensure the Workflow Process is configured to run as the User who made changes to the record rather than the owner of the workflow, otherwise the first Update step will result in the Modified By field being set to the owner of the Workflow Process rather than to the current User. This option does not apply if the Workflow Process is started On Demand, manually, by a User, but is does apply if the Workflow Process was started automatically.

image

Hint: You could bundle these two Update steps into one single Action or Real-Time Child Workflow Process and then invoke that Action or Child Workflow Process from any other Workflow Process, Dialog Process or Action whenever required using a single Perform Action or Start Child Workflow step.

The following images show:

  1. A Perform Action step in a Background Workflow Process that starts an Action named Update Last Updated Fields. Note: Actions always run in Real-Time.image
  2. A Start Child Workflow step in a Background Workflow Process that starts a Real-Time Child Workflow Process named Update Last Updated Fields.

image

Second Approach

Configure the Workflow Process to first start a Custom Workflow Activity that then returns the UserId of the User that the Workflow Process is running as and then use an Update step to set the Last Updated On and Last Updated By fields from the Process Execution Time and the previously returned UserId.

This approach:

  1. Works if the Workflow Process is running as the current User.
  2. Requires the development and publication of a suitable Custom Workflow Activity that returns the UserId of the User that the Workflow Process is running as.
  3. Requires only one rather than two updates to be made by the Workflow Process to the record being updated.