Behavior of specialized update operations
Note
Unsure about entity vs. table? See Developers: Understand terminology in Microsoft Dataverse.
There are several deprecated specialized messages that perform update operations. In earlier versions it was required to use these messages, but now the same operations should be performed using IOrganizationService.Update or UpdateRequest class with IOrganizationService.Execute
| Deprecated message request | Attribute(s) to update |
|---|---|
| AssignRequest | <entity>.OwnerId |
| SetStateRequest | <entity>.StateCode<entity>. StatusCode |
| SetParentSystemUserRequest | SystemUser.ParentSystemUserId |
| SetParentTeamRequest | Team.BusinessUnitId |
| SetParentBusinessUnitRequest | BusinessUnit.ParentBusinessUnitId |
| SetBusinessEquipmentRequest | Equipment.BusinessUnitId |
| SetBusinessSystemUserRequest | SystemUser.BusinessUnitId |
<entity> refers to any entity that provides this attribute.
More information: Legacy update messages
This change introduced some special behaviors that should be noted for plug-ins and workflows.
For plug-ins
When update requests are processed that include both owner fields plus other standard fields for business owned tables, plug-ins registered for the Update message in PreOperation and/or PostOperation stages 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 table). Examples of business owned tables 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 PreOperation and/or PostOperation stages 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 the PreOperation and then store relevant information in SharedVariables in the plug-in context for later plug-ins (in the pipeline) to consume.
For 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
Update and Delete tables using the Organization Service
Event Framework