ActivityPointer Redirection

I ran into error this a little while ago while doing some data conversions.


A quick search on Google will yield results on trying to associate an invalid activity record to your entity.

However this was not the case, as I was not doing any linking of activity records.

In the end what it turned out to be was that the relationship was created against Entity A (which was wrong), while I was passing in an EntityReference to Entity B.

Still wrong, still an error, but took me down the wrong path when the error first popped up.

And now you know.

Failed to Import Solution Error

I encountered a rather odd error the other day when I was having to do schema changes between organizations that involved a lot of importing and exporting when at one point I could not import the solution into one of my target orgs anymore.

After some digging through the Dynamics logs, the problem became very clear.

I had a field that had been incorrectly typed, so in my source org, I deleted it and recreated it.  When I proceeded to import the solution updates into my target org I could not perform the import because the field already existed but in an incompatible field type.

Specifically, doing some searching through very verbose CRM log file yielded the following entry.

Attribute new_legacyid is a Integer, but a String type was specified.

To get around this issue, I removed and deleted the field new_legacyid from my target org and then performed the import again, which then went smoothly from there.


Updating the State of a Record in Dynamics

Had some head banging to do this past week when I wanted to update the state of a record in Dynamics.  For some reason, this has always been an indirect path to accomplishing a simple task.

This article applies only to Dynamics 2015/2016 and below.  In Dynamics365, this method is being deprecated in place of the Update method (YES)!

Before you code anything, there are two references you are going to need in order to access the correct object.



Now that you have those two references you can now leverage the SetStateRequest message to submit your state change (after your entity was created).

 SetStateRequest request = new SetStateRequest();
 request.EntityMoniker = new EntityReference("your_entity_name", EntityId);
 request.State = new OptionSetValue(1);
 request.Status = new OptionSetValue(2);

In the above, EntityId is the primary id (guid) of the record that was created.  The 1 and 2 are values represent the statecode and statusreasons fields in your system, while statecode will generally be the same (Active = 0, InActive = 1), statusreason can be wildly different.

An informative list of status codes are available here.

UCMA – I’m Writing a Message

I was working on a UCMA (Unified Communications Managed API) issue the other day and wanted to integrate the “Is Writing a message” functionality that is oh so important in any chat conversation today.  My application is pretty simple, a chat bot is listening to incoming requests and directing them to their intended recipient.

You can see this in some of the built in examples, but if you haven’t looked there yet, this functionality is quite easy to implement.

In your MessageReceived event from your Message Flow, simply add the following line into the event before you send back your reply and this will trigger an event to fire when this occurs.

MessageFlow.LocalComposingState = ComposingState.Composing;

And that’s it, now you can know when the receiving user start to type a response, even when they take a pause only to have it fire again.


Dynamics Workflow Scope

I ran into a scenario this week, where  workflow I created was only running for my user account on records that I had created and not ones that I might later modify and/or that other people had created.

The solution was to change the scope of the workflow to Organization so it ran for everyone.

Changing from User (the default) to Organization got this going.  I haven’t had a need to try with the current user’s business unit which would be pretty cool too.


Alternate Keys in Dynamics

In CRM 2015 Update 1, a new concept for allowing a field to be listed as a primary key outside of the traditional Guids was introduced called Alternate Keys.  I had not had a chance to use this feature in-depth so thought this would be a great opportunity to dig into it.

The concept itself is pretty simple – you are integrating Dynamics with another system that has it’s own setup of Primary Keys why not replicate those Ids in Dynamics.  If you are deploying a greenfield solution with no integrations to other systems, you’ll probably never use this feature.  However, if you have a complex synchronization solution between many line of business solutions where an entity in Dynamics could actually represent 5 disparate resources throughout the rest of your organization, this could be a big win for you.

Creating an Alternate key is pretty easy and can be done from the entity section in Dynamics.


From here you then identify your field as an alternate key in the new “keys” section of your entity.


Which will then show as an alternate key in the Keys section.


Without any other configuration, your new “key” field automatically has Duplicate data detection on it, ensuring that each record has a unique value as a key within it.  If a duplicate value is identified, the following warning is presented to the user.


As someone who writes migration/syncing code quite a bit, this is a great way to manage a variety of keys from different environments and ensure data is not getting dirtied.  There are some additional SDK functions that enable you to create entities from the alternate key as well.

My only confusion with this feature was that when you mark the field as “an Alternate Key” it doesn’t make it Business Required by default.  As a unique key, allowing empty values (even one should not be allowed).

Dynamics365 is not a Database

Yes, it has a database that stores all of it’s information within it, but it is not a database.

Similar to Skype For Business and SharePoint that have databases to store all of it’s configuration models and user data within it, they are not referred to as databases.

Over the years I’ve been asked many times to take a customer’s existing database model and map it to Dynamics – i., pick up and replace.

This generally leads to a back and forth on how this should be done as we discuss legacy information, schemas that no longer apply or are used and features that can simplify the overall implementation of the schema.

I think part of the reason for this is the readability of the Dynamics schema whereas something like SharePoint and Skype For Business is much more obscured (or a bit harder to read) whereas Dynamics can be readily mapped to the SDK.

When “migrating” a schema it’s important to remember;

  1. Your current schema for state engines will be replaced with State/Status codes for Dynamics.
  2. Your user ownership will be replaced by createdBy/modifiedBy entries tied to an active directory (on premise or in the cloud) and not use application Ids.
  3. Many-2-Many tables will exist in Dynamics but will not necessarily be accessible to you.
  4. Auditing is a checkbox that you enable.

I think what would really benefit Dynamics in this regard, and where I feel the Solution Designer falls down, is not providing a proper Entity Relationship Model for both the logical and physical implementation.  When talking with end users, it’s the logical they are more concerned with – “are all of our concepts within there” – and the developers who are more concerned with the physical – “can I get all my datatypes and fields in there”.

In the end, I urge customers not to think of their Dynamics implementation as database with an application on top of it, but instead of a platform that are creating, extending and debugging.

No code I know, but had to get this out there – it’s not a Database!