Worth Your Time to Fine Tune Workflows?

In working through some optimization on a CRM server, I thought it would be a good idea to check the running System Jobs.  This particular CRM installation was upgraded from 1.2 to 3.0 to 4.0.  Given that, I knew there were a few workflows that needed a face lift so before diving into them, I decided to gather information.


My first step in the process was to create an Advanced find view that returned all System Jobs where the Status Reason = Waiting, Waiting for Resources, Pausing, In Progress.  I added the columns Error Code and Message to the result set for additional information.


The results of the query showed that there were several thousand jobs running in various states. Here is some of the information I was able to glean from the System Jobs.


Several of the jobs failed for one of the following reasons:

·          The system was not able to execute a Send E-mail step.

o    The entity record containing the e-mail address information did not have an e-mail address

·          The record used to populate the Regarding field of the e-mail was not a valid record for this use

·          The record the workflow was trying to update was in a ‘Read Only’ state

·          Timeout periods spanned multiple days

o    Workflow was in a waiting pattern but the record that the job was running against was closed


Armed with the information above, I was able to go through the workflows and re-design with them to behave more intelligently and better handle some of the data anomalies and scenarios that they would encounter.


Those improvements included:

·          Added a Check Condition step that checks to ensure the e-mail address field contains data before all Send E-mail steps.

o    I send a notification to an internal user if the e-mail address field of the record does not contain data.  The notification instructs the user to update the record with the e-mail address and run the workflow again.

·          Added a Cancel Workflow step that follows the Send E-mail notification to the internal user.

o    This ensures that the System Job is canceled when it is not able to complete

·          Ensured all Regarding fields of E-mails generated from the System were updated with valid record types

o    Contacts, Accounts, Leads, Opportunities, Quotes, etc. are all valid record types.

o    This step will fail if you try set the Regarding field to another Activity type like E-mail, Service Activity, etc.

o    If you are not sure if the record you are using to set the Regarding field in an e-mail is valid, you can create a CRM e-mail and click on the Regarding field to ensure the record type you are using appears in the list.

·          Added a Check Condition step that checks the record status to ensure it can be updated before the Update step.

·          Added a Cancel Workflow if the record is in a Read-Only state

·          If the timeout period spanned a few days, I added a timeout step for each day

o    Added a Check Condition step before each timeout day to check the record status

o    Added a Cancel Workflow step to cancel the workflow if the record was closed during the day


My initial goal was to see if I could identify improvements that would reduce the result set of the query by 50%.  Applying the design improvements above, I was able to reduce the result set from several thousand to several hundred and my invested time was about 8 hours of effort. 


The above is intended as an example only and the specific steps referenced may not be the optimal approach for every CRM configuration. 

Updating a CRM record when the record is in a read-only state such as Closed or Completed


Ever wonder how to update Closed or Completed CRM records like Activities, Quotes, or Opportunities that are in Completed, Won or Lost status using a supported method that does not require writing code or custom workflows?  If so, here is a solution leveraging workflows in Dynamics CRM 4.0 which was not possible in the CRM 3.0 version.

I recently had a requirement to automatically update a field on an Opportunity and Quote record with a data value from the related Order when an Order was created.  The date value is the Booking Date of the Order which is generally different from the date the Order is processed.  Since I was aware that the related Quote and Opportunity would be in read-only status (Won) after the Order was created, per the business practice of the company, I knew the workflow logic had to include something like the below:

·         Update the Quote Status to Draft / In Progress

·         Update the Quote field per requirements

·         Update the Quote Status to Active

o    The Quote must be in Active Status in order to change it to Won status

·         Update the Quote Status to Won

·         Update the Opportunity status to Open / In Progress

·         Update the Opportunity field per requirements

·         Update the Opportunity to Won

·         Stop the workflow as Succeed


I began by creating a fairly simple workflow on the Order entity which included the steps above.  Below is a snapshot of the workflow for reference:


As you can see, I set the Workflow Scope to Organization, selected to start the workflow when the Order field changed, and made the workflow available to run On Demand for testing and updating existing records.  Using the Order field change as the trigger rather than when the Record is created, allowed me greater flexibility to ensure I was catching all changes and not just those generated when a new record was created.

After saving and publishing the workflow, I tested it on a few Order records.  I gave the system jobs adequate time to complete and ran an Advanced Find query on the system jobs with the name of the workflow to ensure everything completed as expected.  I included filtered criteria to show all systems jobs where the Status Reason; did not equal Canceled or Succeeded.  The query returned a small set of records where the System Job was in Waiting Status. 

I opened the System Job to see if I could identify the issue and discovered that the issue occurred because the user neglected to associate an Opportunity with the Order record.  The job did not complete as expected since it could not find the related Opportunity record. 

To address this scenario, I inserted a step in the workflow that first checks the Order record for the related Quote, sends an e-mail notification to CRM Admin if there is no related Quote, and cancels the workflow.  I created a similar check for the Opportunity. 

Please see the modified workflow screen shots for reference below:


To complete the change request requirements, I also needed to update existing Opportunity and Quote records with the required data value.  Normally, one could simply use the default Order view of Active Orders, but this particular Company had Orders in both Active and Submitted status.  To ensure I captured a full list of the Order records, I created an Advanced Find view on the Order entity and used the filter criteria: Order Status does not equal Canceled.  I ran the workflow on the Order records and the workflow updated both the Quote and Opportunity records with the field data value as expected. 

One item worth mentioning is that if you have a large record set to update, you may want to wait until after hours to apply the workflow or apply the workflow to a subset of records in stages to minimize performance impact.  I had a little over 4 hundred records to update so it did not impact performance.

Thanks to Microsoft for the enhancements made to workflows, I use them frequently!