Enhanced Update Request in CRM 2015 Update 1

Before release of CRM 2015 Update 1, user needs to call different request to perform the below operation.

1. If user wants to update the records he needs to call the UpdateRequest

2. If User wants to Change the Status of record he needs to call the SetStateRequest.

3. If a user wants to change the ownership of the records then also he needs to perform the AssignRequest.

4. Similarly user needs to call below request to perform the below operation

So, if user needs to perform below operation on a record,

a: Update

b: Assign

c: Status

Then user needs to call three different request which hits the server thrice and if there are so many records then it will increase the load.

But in this release there is good news for the developer, now user can perform all the above operation in a single request.

User just needs to call the UpdateRequest to perform all the above listed operation.

Notes: For Microsoft Dynamics CRM Online organizations, this feature is available only if your organization has updated to Dynamics CRM Online 2015 Update 1. This feature is not available for Dynamics CRM (on-premises).

Though above listed messages have been deprecated for future releases, it will continue to be available with the 2011 endpoint. However, the recommendation is to use the UpdateRequest or Update method when possible to set these attributes.

You can continue to use these specialized messages of the 2011 endpoint in your code. However, the Web API that eventually replaces the 2011 endpoint supports only the Update message for these types of operations. If you want to get a head start on changing your code to align with the Web API, you can now do so. See Web API Preview for more information.

Following are the impacts on the Plug-ins and workflows

Plugin:

When update requests are processed that include both owner fields plus other standard, plug-ins registered for the Update message in pipeline stage 20 and/or stage 40 execute once for all non-owner fields, and then once for the owner fields.

The new API would not execute the SetState or Assign message plugin, BUT, it will call an UPDATE request for each of these messages

a. 1st time for the updating-This time, the target would receive only the non-owner/non-status fields)

b. 2nd time for the Owner-only the owner field is available in Target

c. 3rd time for the state-This time only status fields are passed in Target.

In order for plug-in code to receive the full data changes of the update, you must register the plug-in in stage 10 and then store relevant information in SharedVariables in the plug-in context for later plug-ins (in the pipeline) to consume.

Workflow:

a. When update requests are processed that include both owner fields plus other standard fields, workflows registered for the Update message execute once for all non-owner fields, and then once for the owner fields. Workflows registered for th Assign message by users continue to be triggered by updates to owner fields.

b. When update requests are processed that include both state/status fields plus other standard fields, workflows registered for the Update message execute once for all non-state/status fields, and then once for the state/status fields. Workflows registered for the Change Status step continue to be triggered by updates to state/status fields.