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.
Donna Edwards 