How do you change/get rid of the default "name" field in Dynamics 2011!

There are many situations where the default "Name" field is not applicable to an entity. A couple of examples to explain what I mean:

Order
An order doesn't have a name as such, but an ID. What we can do in this instance is change the name of the default field rather than keep the default "pfx_name". A more appropriate name might be "pfx_OrderId" or maybe "pfx_OrderRef". You do this when creating the entity on this screen:

Using the Primary Field tab we can decide exactly what the name of the field is and other things such as business requirement and length etc.


Order Detail
This is an even more interesting one. For Order Detail we don't really have primary field whatsoever. We have a few options as to what we may consider the primary field:

1. It's probably a combination of Order ID/Ref and the Order Line Number?
2. Maybe it's the Product Name we're ordering?

Either way, it's not a text field. So what are our options? Initially from a look at the above screen for editing the Primary Field properties we get some false hope... it looks like you can change the Type of field this is! Unfortunately we only have 1 option in the dropdown: Single Line of Text.

So, the only real option is remove it from the form. If you've ever tried this before you'll know that it's not as straight forward as a custom field because it's locked on the form. How do we do it:

1. Change the business requirement to "Not Required"
2. Open up the Main form
3. Open up the properties of the field
4. Turn off the "Visible by Default" flag

This has a few further implications. Firstly, any lookups to the Order Line will have blank lookup fields on the form. For example maybe we had a "Guarantee" entity that needed to reference an Order Detail record. On the Guarantee form this lookup will look like it's empty. There are a couple of ways around this, but my personal preference is to add some Javascript to the Order Detail form so that it populates the hidden name field on save with data from another field - E.g. the Product name.

Other implication is some view cleaning up to be done. If you open up the views you will see they will all display this name by default. All of these will have to be customized to allow for this.

Dynamics 2011 - Cannot Delete Relationship!

Recently we ran into a really interesting problem within our company when trying to delete a relationship between 2 entities. We kept getting 1 of 2 errors:

1. Cannot delete EntityRelationship because one or more components require it.
 
2. An error about an attributemap that no longer existed (I couldn't recreate this error to get the exact wording)

Obviously you'll have checked for the obvious like ensuring the field doesn't exist on a form or removing any connections if applicable. None of this solves the problem, so what could it be?

One of the most common reasons I've found is you've edited the site map and changed where the related link is displayed. So let's say you have an entity called Product and one called Component referencing it (i.e. Component has a look up to Product). There will also be a related list/link on the left navigation of Product where you can see all of it's Components. If you use a sitemap editor to reorder or change how this is displayed this can cause you a problem when trying to delete the relationship.

The second problem is quite an unusual, and I'm not sure why dynamics doesn't automatically do this for you. Let's go back to our example above but add a third entity:

1. Supplier
2. Product (Which has a look up to the Supplier entity)
3. Component (Which has a look up to the Product and Supplier entity)


Here's the scenario I came across, I try to delete the relationship between Product and Supplier and it says:

But what else could possibly require this? I click on details within the error and it points me to the relationship between Product and Component... ok, so what's going on here then?

9 times out of 10 you've added a mapping. In my case whenever I created a new Component from the Product screen I had a mapping to automatically use the supplier from Product to populate Component. So, open up that relationship and check for any mappings! Dynamics should really remove this mapping for you, but such is life.

Just a few things to be aware of when working with relationships.

MS CRM Dynamics - Q2 Release

Many of you might be aware of some major updates coming with the Q2 release of Dynamics (see here for a preview of the release). The major part that was originally of interest to me was multi browser support, but the preview has given me a few other surprises!

1. Business Intelligence / Power View.

Power View is a new reporting services Add-in for SharePoint that came with the release of SQL Server 2012. I believe this is the first stepping stone towards far more powerful reporting within dynamics. Looking forward to playing with this to see what exactly we can do with it.

Only Gotcha is that this is only available on-premise with the Q2 release. Fingers crossed for Q3!

2. Custom Workflow Activities on the Cloud!!

Finally! This one is a big one for me. No more thoughts of plugins and custom entities to handle "special" workflow code. I'm not sure why they weren't selling this one more (or maybe I had my head in the sand for a while!), but this is one I've been looking forward to for a while.

Convention over Configuration - Case sensitivity?

Today I had a debate with a fellow employee about the naming conventions of some fields on a CRM form. It's a slightly off the norm of "convention vs configuration" arguments, instead it was more of a "Convention A vs Convention B" type argument. Take this example, the particular field that was added was a web resource. For other reasons we have some javascript that passes over the form to try locate these web resources. I designed the javascript so that it will always look for web resources that start with the following naming convention:

WebResource_DS*

So, if we follow this convention we don't need to configure anything. Note that DS is a recognised acronym in our organisation. Unfortunately we ran into some problems in our testing environment, some of the controls weren't being detected. I take a look at the controls and they've been named:

WebResource_ds*

Now, my gut reaction is to fix the script to allow for case sensitivity... but after a quick think this feels wrong to me. If we're following convention shouldn't it be case sensitive? For example, if we introduce camel casing on database field names then "productname" is incorrect, it should read "productName".

So instead of changing it I argued that it should follow the convention of _DS including upper case. I argued that if you follow "convention over configuration" it should include case sensitivity. This should be especially the case for known acronyms (if the convention states all upper-case for acronyms). The debate that he put forward is if you've ever read something like "the design of everyday things" everything should be intuitive, so 'DS' or 'ds' shouldn't matter.

I see his point... but I stick by my guns!