As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at status and status reason transitions.

As you revise it is wise to keep referring back to the skills measured statements to ensure you are fully covering all of the points mentions. In this post I will cover the item underlined red, “status and status reasons”.

Status (aka Statecode)

Every entity has a status field. It governs the main “state” of the record.

Custom entities and many system entities have just two states, active and inactive. Inactive records are read-only and can be activated again if required.

There are some system entities such as lead, opportunity and case that put a slightly different interpretation on the status field. An opportunity, for example, is shown and being open or closed. These system entities may also have more than two states.

It is important to understand that the status field cannot be customized.

Status Reason (aka Statuscode)

For each status multiple status reason options can apply. These are used to give further detail about that status.

For a custom entity we have two default status reasons of active and inactive. These can be renamed.

For both system and custom entities we can change the labels used in status reason or add addition options.

I have shown the status and status reason options for several key system entities below. You can also see a full list for all entities here.

Case

Lead

Opportunity

You can’t customize the status field but you can make changes to the status reason field. Below you can see the status reason for a disqualified lead. It would be quite a common customization to add additional reasons for marking a lead as disqualified.

Status Reason Transitions

You can also define what are the valid transitions for a status reason on an entity.

For example, in my application I can log project issues. An issue is initially logged, then it is reviewed. After a review it is either accepted or rejected. And an accepted issue may be resolved.

In my example you shouldn’t take an issue that has been marked as accepted back to a logged status.

This type of logic can easily be implemented by using status reason transitions. You will find an option called “Edit Status Reason Transitions” in the ribbon bar of the status reason field.

Below you can see that I have enabled status reason transitions and then defined which status reasons can be selected for each of the options.

I hope this post has given the key details needed for preparation for the MB2-716 exam.
