Updating a Microsoft Dynamics CRM Record in a Read-only State


Our guest blogger today is CRM MVP Donna Edwards who blogs regularly here.

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
    • 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!

Cheers,

Donna Edwards

Comments (4)

  1. David Berry says:

    One of the big problems I have with this process, is really the elephant sitting in the room:  changing record states.  Workflows and Plugins that execute when the state changes will be called when your workflow is executed.  While it’s simple to turn off workflows, it’s not so simple to turn off plugins.

    This becomes a problem when these code paths are not designed to be executed more than once.  While I can appreciate that such design would be considered poor, most may not expect to have a Quote revisit an Active state, as the "Revision" process clearly is meant to avoid it.

  2. Kamaldeep says:

    I hope this works.. will test it.. I was required to update the Case with the Case Resolution details as the case is marked as resolved. This was needed as I was supposed to send the resoltion Date and the resolutin details in the email to the customer.

    This is because, I could not add resolution entity values in the email template directly.

  3. Donna Edwards says:

    Hi Barry,

    Thank you for your feedback, good point!  

    It is important that System Administrators perform this type of work to ensure the integrity of the system.  Even though, this is a fully supported feature, in the wrong hands, data can be compromised.  My example does not compromise the data integrity but instead, provides a valuable update for reporting which was a big win for this client.

  4. Donna Edwards says:

    Ok, let me know if you run into any issues with updating the case and I will try to assist.

Skip to main content