Behavior of specialized update operations
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.
Important
When you update the StateCode column, it is important to always set the desired StatusCode.
StateCode and StatusCode have dependent values. There can be multiple valid StatusCode values for a given StateCode value, but each StateCode column has a single DefaultStatus value configured. When you update StateCode without specifying a StatusCode, the default status value will be set by the system.
Also, when auditing is enabled on the table and the StatusCode column, the changed value for the StatusCode column will not be captured in the audit data unless it is specified in the update operation.
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 SDK for .NET
Event Framework