Bernado Nguyen-Hoan's Blog – Coding Stories from an IT Mercenary

A weird post title I know..

One of the most confusing things in CRM is the State and Status (or Status Reason) of a record. These two things are very different in CRM, and it seems that the CRM UI itself often gets mixed up between the two.

When you create a new entity for example, the default label for the statecode field is Status, and for the statuscode field it is Status Reason.

When configuring a workflow, you can specify that it fires on after ‘record status changes‘:

Exactly what does this mean? Will the workflow fire when the record’s State (Active/Inactive) changes? Or will it fire when the record’s Status (‘sub-state’ within Active/Inactive) changes? Will it fire on both?

Well, as it turns out, this option will fire the workflow only when the record’s State changes. Enabling this option has the same effect as enabling the ‘record fields change‘ option and ticking the statecode field in the filter.

In fact, that’s exactly what CRM does behind the scene. Try this:

• Tick the ‘record status changes‘ option
• Tick the ‘record fields change‘ option. This enables the Select button to apply field filtering.
• Now click the Select button. You will see that the statecode field is selected by default.
• Untick the statecode field from the filter
• You will see that the ‘record status changes‘ option is now unticked

So in conclusion…

Even though the option say ‘record status changes‘, it really means on record state (Active/Inactive) changes. Misunderstanding this option can cause workflows to fire (or not fire) unexpectedly in your system.

This is a rehash of several posts by other people.

A user in CRM has a default organisation. This is the first organisation where the user was created. Use the SQL script below to identify the default organisation for a user:

select a.domainname, a.systemuserid, d.DatabaseName, d.uniquename 
from <Org Name>_MSCRM.dbo.systemuserbase a WITH (NOLOCK)
inner join MSCRM_CONFIG.dbo.SystemUserOrganizations b WITH (NOLOCK)
on a.SystemUserId = b.CRMUserId
inner join MSCRM_CONFIG.dbo.SystemUser c WITH (NOLOCK)
on b.UserId = c.id
inner join MSCRM_CONFIG.dbo.Organization d WITH (NOLOCK)
on c.DefaultOrganizationId = d.id
where a.domainname ='DomainUsername'

The script above was posted by Susan in the comment section of this post: https://blogs.msdn.microsoft.com/arpita/2013/01/23/how-to-find-default-organization-for-any-user-in-multiple-organization-crm-deployment/, which describes how the underlying data hang together to determine the default organisation for a user.

When does this might come in handy?

When a user runs a report in CRM, CRM appears to check for the user against their default organisation. The report will not be rendered correctly if this organisation is disabled. I found this information at this post: https://crmbrewer.wordpress.com/2016/05/05/crm-reports-error-error-sys-is-undefined/.

In our particular case, we found the below stack trace in the Event Viewer. My guess is that this is a MS bug that may one day be addressed. This was observed on CRM 2016 on-prem.

Exception type: CrmException

Exception message: The CRM organization you are attempting to access is currently disabled.  Please contact your system administrator

at Microsoft.Crm.BusinessEntities.SecurityLibrary.ValidateOrganizationState(IOrganizationContext context, LocatorServiceContext locatorServiceContext)

at Microsoft.Crm.BusinessEntities.SecurityLibrary.CheckDisabledStatus(IUser user, IOrganizationContext context)

at Microsoft.Crm.BusinessEntities.SecurityLibrary.ValidateUserEnabled(Guid userId, Guid organizationId)

at Microsoft.Crm.Authentication.Claims.AuthenticationProvider.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationStep.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationPipeline.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationEngine.Execute(Object sender, EventArgs e)

at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)