Perform specialized operations using Update

 

Applies To: Dynamics CRM 2015

Before this release, specialized messages were required to update certain entity attribute values. In this release, UpdateRequest can now be used to set these attributes. The following table identifies the specialized deprecated message requests and the related message attributes that can be updated using UpdateRequest.

Deprecated message request

Attribute to update

AssignRequest

<entity>.OwnerId*

SetStateRequest

<entity>.StateCode*

Important

For SLA and RoutingRule entities, changing the OwnerId and StateCode in a single Update message invocation is not supported and results in an exception.

SetParentSystemUserRequest

SystemUser.ParentSystemUserId

SetParentTeamRequest

Team.BusinessUnitId

SetParentBusinessUnitRequest

BusinessUnit.ParentBusinessUnitId

SetBusinessEquipmentRequest

Equipment.BusinessUnitId

SetBusinessSystemUserRequest

SystemUser.BusinessUnitId

*<entity> refers to any entity that provides this attribute.

Note

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).

These specialized messages will continue to work with the 2011 endpoint. However, the recommendation is to use the UpdateRequest or Update method when possible to set these attributes. The Update message simplifies the SDK API and makes it easier to code standard data integration tools used with Dynamics CRM. In addition, it is easier to code and register a plug-in to execute for a single Update message instead of multiple specialized messages. The AttributeMetadata.IsValidForUpdate property for the above listed attributes has been changed to true in this release to enable this capability.

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.

Impact of this change on plug-ins

When update requests are processed that include both owner fields plus other standard fields for business owned entities, 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. Examples of owner fields would be businessunit and manager (for a SystemUser entity). Examples of business owned entities include SystemUser, BusinessUnit, Equipment, and Team.

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

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.

Impact of this change on workflows

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 the Assign message by users continue to be triggered by updates to owner fields.

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.

See Also

Write plug-ins to extend business processes
Write workflows to automate business processes

© 2016 Microsoft. All rights reserved. Copyright