Share via

How To:  Use Record Status in Microsoft Dynamics CRM

  • Article

In Dynamics CRM there are two fields related to status:

  • Status (statecode) 
  • Status reason (statuscode).

For custom entities you can modify the status reason field but not the status field. The status field only has two options: Active and Inactive. You cannot change or add new statuses. You can add items to the status reason field values. In the interface CRM displays Activate and Deactivate buttons (depending on the current status) on the ribbon for custom entity forms and views. When activating and deactivating a record, if the status for this entity has more than one status reason associated with that status, a list of status reasons will be displayed for the user to choose from. 

Uses of status

The use of the CRM record status typically falls into one of two major categories:

  • Current/Deleted
  • Processing 

Current/Deleted

In this case the inactive status represents a record which is deleted, effectively hidden from the users and processes. These records are still present in the system however so the delete can be reversed acting as a sort of recycle bin. 

One of the things to consider is that when a record is being deactivated CRM will not perform any checks if the record is referenced by other records. And though the record is deactivated, subordinate and related records will remain active. If you want to make related records inactive you can take action on status changes and add this behavior.

The status reason for records in this situation can usually be ignored.

Processing

This approach is different from the Current/Deleted model, and instead looks at the status to determine whether this record is currently being processed or used in some way, and with the status reason giving further details about the status of the record. It is useful for records that undergo some kind of processing or evaluation, or for case management.

A record with an Active status indicates that it is currently in use or "current" in some way. A record with an Inactive status is one that has been completed, and has been "closed off". The status reason then expands on the status with more details about the current condition of the record - such as "under evaluation" or "approved". For a user to determine what the current condition of the record is, they look at both the status and the status reason.
 
An example is a CRM solution designed to process applications. When an application is received the associated account is created with a status of "Active" and a status reason of "Under Evaluation". In this situation the Active status means "this account is either current, or trying to become current". As the application is considered the status reason might change to "Further Information Requested" and "Draft Approval Given" as the application is processed. If it is approved, the status reason for the account would be set to "Approved". During this whole process the status remained unchanged from Active; only the status reason changed. 

Later on, if the account ceases doing business with your organisation or the approval ends, the status would be changed to "Inactive". The status reason would then explain why the status was changed; it might say "Account Closed" or "Approval Ceased" or "Suspended". The Inactive status indicates a record which is completed/historical or is otherwise in a state where modifications to the record are no longer allowed. The fact that the record is inactive does not necessarily mean it is no longer relevant; it just means that you do not expect to have to update this record again in the future, because whatever work you were doing with it has ceased. 

If you use the status and status reason fields in this way, you should consider removing the status field from the default views in CRM; in the above example, default views of "Current Accounts" and "Applications Under Processing" that look at a combination of status and status reason may be more useful.

System and custom entities

Some system entities have more than two status options. This applies to the following system entities

  • Activities (ActivityPointer)
  • KB Article
  • Lead
  • Opportunity
  • Quote
  • Order (SalesOrder)
  • Invoice
  • Contract
  • Contact Detail
  • Case (Incident)
  • System Job (AsyncOperation)
  • Bulk Delete Operation

For these entities the different state values indicate the stage in the process the record is in. CRM has specific behavior for these states. The other exceptions are Dialog Session (ProcessSession), Workflow and SDK Message Processing Step for these entities the two status values also have a specific meaning to CRM.
The other system entities have the two state options used by custom entities: Active and Inactive. Most of the possible behavior and customizations described below apply to entities which have the two status values (Active and Inactive) without special behavior. For the entities with system defined behavior not everything is possible and some of the options may already be implemented.

CRM does by default attach some behavior to the status field:

  • Most entities have three basic public views. An ‘Active view’; displaying all active records, that is also the default view presented to the user. An ‘Inactivate view’; displaying all inactive records. And for user owned entities a ‘My Active View’; displaying all active records owned by the user. These public views can be modified.
  • The Associated, Lookup and Quick Find views contain when create a condition to only show Active Records. This can be modified by opening the view in design mode and click Edit Filter Criteria in the tasks list.
  • Inactive records cannot be modified using the CRM interface. The form will be displayed as read-only. The CRM web service, plugins and workflows can still update the record.

Actions on status change

CRM does offer various options to interact with the status change. A status change is a message which can be used to trigger a workflow or a plugin. Workflows allow actions to occur after the status has changed. Plugins can be used in the same way but do also provide the ability to take action before the status change occurs. At this point you can validate the status change. In the property development example above you may have a check on the status change from planned to designed which validates an approval has occurred, if the approval is not met the status change can be aborted. Similarly you may also want to limit the possible status changes. A property which has been built cannot go back to the designed status.

You can also modify the behavior of the CRM user interface based on the current status of a record. Using JavaScript in the form onload you enable/disable and display/hide fields. Using the Ribbon customization you can also change the Ribbon. With a ValueRule within a EnableRule or DisplayRule you can easily disable or hide Ribbon actions for a specific status.