I recently had to do some investigation on refreshing the data fields of a record within a workflow. Consider this scenario:
- You have a workflow that triggers at the creation of a case record
- The first step of the workflow is to use a custom workflow activity that performs business logic and updates the priority field on the case
- The second step is a check condition that looks at the value of the priority field to go in one branch or another
If you know CRM workflows well, then you know they are not designed for this kind of utilization. When the workflow starts running, it loads the record and persists it in its current state, then uses the record in the persisted state for the next steps of the workflow. In the scenario that I’m using as example, it means if the value of the priority field is set to ‘normal’ (default value) when the case is created, that’s the value that is loaded in the workflow. The custom workflow activity updates the priority field value to Low or High. This update is not taken into consideration when the workflow hits the next step where it checks for the value of that field to go into the appropriate branch.
There are a few ways for ‘force’ the workflow to refresh the data, but none of them is really pretty.
Use an ’empty’ update step. You just insert an ‘Update Record’ step in the workflow without updating anything on the record. This will force the data to refresh
- Use a dummy ‘Wait’ condition. For example, you can wait for 1 minute (Timeout). When the workflow resumes from a wait condition, it also refreshes the data
- Create a custom step that reads the field value directly from the database
Solution 1 is the simplest solution in my opinion. It’s important to document it accordingly if it’s something you are doing on a regular basis and in multiple places. Knowing that 1 works, I would simply disregard solution 2 as it adds more steps in the workflow and creates more database hits. Solution 3 is interesting if you have to do many ’empty updates’ within your workflow(s). It could be cleaner to have a custom step that returns all required decision field values. The problem is this requires code i.e. more work and coding skills and potentially harder maintenance…