Microsoft CRM Phase 1 Deployment

In my experience when a company decides to embark on a CRM initiative they almost always under estimate the impact that such a project is going to have. And I mean "impact" in a positive sense. The client is not to blame for this because they are invariably involved in their day to day activities and rarely have the time to dedicate to really appreciate what they are getting themselves into by having made such a decision. That is, in most cases a client will have decided that they need to be doing a better job with, say, tracking their sales process, or managing their client "touch points" etc. etc. and based on this they will likely come up with a set of scenarios that they will want their CRM solution to cover.

Therefore in my opinion, a CRM initiative is usually driven by something akin to an organizational "gut feeling". The client is normally somewhat educated about the high level features that a typical CRM product brings to the table - sales automation, marketing automation, service management, along with typical features such as workflow, alerting, and follow up - and their initial requirement will likely be a reflection of some these "high level" features that they know can improve efficiencies (customer experience, hand offs, visibility, oversight etc.) within the organization.

If a client is replacing an existing CRM solution or implementing CRM to replace a custom built or vertically specific application then it's likely that they will have a better idea of the features that they need the new product to cover and this will be reflected in their requirements as well as in the product selection process.

However, in most cases - during the project initiation phase and prior to that - the client is unlikely to have a much deeper appreciation of the myriad other capabilities that a product such as Microsoft Dynamics CRM brings to the table. And this is where it gets interesting...

The question therefore is - in light of this introduction - what is the best way of going about Phase 1 of a CRM deployment?

I would venture to say that the answer lies within the fact that a major factor of the Phase 1 deployment is education. And not only education for the organization undertaking the CRM initiative but education of those you have entrusted in realizing your CRM dreams. First and foremost the client needs to be educated about the features and capabilities of the product as it pertains to their business. A good consultant must help the client envision what the future can hold while at the same time grounding the deployment in real achievable chunks. And at the same time, the consultant must get educated about the client's business model, their unique requirements, the client culture and the intricacies of the client operation. This mutual education process is iterative and it is a discovery process that happens naturally and dynamically and should be controlled and driven by the consultant running the workshop (it's easy to get carried away, so it's important to know when a discussion needs to be tabled for later review in order not to take away from the core objectives).

A workshop session should also include - at some point - various other players within the organization. And it is again likely that most of these additional players will have had limited involvement in the run up to the project initiation and will have little to no knowledge of what this so-called CRM application is. There's a good chance that they will never have even seen the CRM user interface. But these players will also likely have key input that may have not been considered during the selection process. And while managing expectations and preventing the process from becoming a "free for all", the insights gained from such participation could prove to be very valuable indeed.

Unlike perhaps most other systems that a company may choose to implement in its organization, CRM is typically a very horizontal type of application. That is, because CRM is your front office and your interaction with your customer, prospect, partner vendor etc. - be it during the sales process or later on in the life cycle during customer service - it tends to be a reflection of way you go about doing business (or should be). And this may also explain the common refrain that consultants such as myself love to repeat that "no two CRM implementations are alike" because just as no two business are exactly alike, so too the CRM product and the way in which it needs to be configured for your specific differentiation, interaction with clients, or way of doing business, needs to be similarly different. Not to belabor the point, but I think this also demonstrates quite well why a CRM solution needs to be so configurable - especially one created for the masses such as Microsoft CRM - it needs to be able to be tailored to your organization and be flexible enough to model your business as it evolves.

And being a horizontal application, it typically needs to "serve up" whatever information is required by your end users in order to enable them to do what they need to do to make your business a success. And this might be tapping into your back end accounting system, your custom built ordering system or with some other data source or system within your organization. And once again, the way in which the data needs to be integrated, migrated or mashed up with your CRM application is realistically only going to come out of a workshop session where you have had time to dedicate and be educated as to the capabilities and possibilities that can be realized.

The challenge of fix pricing a CRM deployment based exclusively on the requirements provided by the client is that the process defined above (or parts thereof) will almost certainly occur in some way, shape or form but the project will be limited to the scope of the originally signed SOW. And this of course can in turn lead to strained relations and/or missed expectations. Or to put it another way, the risk is that the customer may get exactly what they asked for... instead of having the benefit of being educated and design the system so they get exactly what their business model requires.

Phase 1 of any CRM undertaking is without doubt the most difficult phase of the CRM initiative. It is an intense period of mutual education and if done well, it also lays the foundation upon which the business can evolve and grow. And therefore it is essential that it be performed with the proper due diligence, understanding and aptitude.

Therefore I would humbly submit that the best way of doing a Phase 1 deployment of CRM is by holding a workshop session with the client using a limited scope engagement for this workshop session. During this workshop, Microsoft CRM itself can be used to facilitate the discussion by configuring the application sufficiently so it can help with the envisioning process (a picture here is worth at least 1000 words). The output of the workshop session may be a partially configured CRM environment (the extent configured will depend on the size and nature of the undertaking) along with an SOW that will provide the client with a detailed breakdown of what is required to round out the Phase 1 deployment, along with outlines for future phases and an overall blueprint of the CRM landscape for your organization.

You must enter a number between 200,000 and 2,147,483,646

When entering a picklist value you may be presented with this error message:

This is a pretty well known issue and anyone who has been working with CRM for even a short while is likely to have encountered it. The solution is fortunately equally simple and presented at the bottom of this post.

With the advent of CRM 4.0, it was possible to not only overwrite a picklist Label but also the associated picklist Value. This gave much needed configuration options to the person configuring CRM but it also introduced a risk in that a user could change a picklist value to overwrite a value that is referenced in the database thereby losing that reference. And indeed if you try to do so you will be presented with the following warning:

But for whatever reason Microsoft decided to give the customizers of Microsoft CRM the option for configuration in this case along with the responsibility for taking such a design decision. This is a good thing. 

The caveat is that the above works for custom picklist attributes that you might create. For some reason when it comes to out of the box attributes, Microsoft suddenly seems to have gotten cold feet. Because in this case you are not able to create a new picklist value with a Value of less than 200000. So here we have a case where Microsoft giveth and Microsoft taketh away...

I am not entirely sure what the rational was for such a limitation but I can only surmise that it was guided by the following thinking:

• Protect against over-writing existing system values which could be used by the application (now or in the future)
• Have a clear differentiation between values that came with the out of the box configuration and values configured during a customer deployment

You may ask - what's the difference? The picklist Value is anyway completely behind the scenes and therefore what do I care if it's value is 15 or 1500? As long as I see the correct Label that's all that should matter. And for the most part and likely in most cases this thought process would be correct.

But consider the case where you have an integration between your CRM deployment and another internal or 3rd party application. If you are integrating the picklist value between a similar drop down/picklist in the other application wouldn't it be easier and more straight forward and make long term maintenance that much simpler if the numbers were the same? Of course it's not difficult to create a cross reference to map these values during integration but that takes the solution just a little further from "simple" than it needs to be. And therein lies the crux of the issue of limiting the configuration option and not entrusting the responsibility of such a design decision to the system customizer.

I for one would like to see additional optional attributes on the picklist attributes (or Option Set as referred to in CRM 2011) which would give additional options for integration mapping purposes which hopefully Microsoft will introduce in the not too distant future.

Happily in CRM 2011, it seems that Microsoft realized the limitations that they had imposed on those who really want additional configuration options and no longer imposed this via the front end.... or perhaps they realized that those who wanted to have this kind of freedom were not deterred by the front end limitation and instead took the back door configuration option as described here (for CRM 4.0):

1. Export the entity in question. For example to export accounts navigate to Customizations | Export Customization | Account | Export Selected Customization
2. Search for the attribute in question (e.g. accountclassification code)
3. Manually add a new picklist option as shown below
4. Import the entity and publish 

Troubleshooting permission issues

In a previous post I gave a brief overview of the security model in MSCRM. And there definitely is more to be said about best practices when it comes to setting up security roles etc. which I will hopefully cover at some point.

That said, there are times when we encounter a permission error whereby a user cannot perform a certain action. Some times it is obvious such as not having "Create" permission on a given entity and sometimes it is less obvious when dealing with some of the more esoteric permissions in CRM that have dependencies on some other lesser known permissions in order to perform the action.

In these cases you will likely be presented with the "logged-on user does not have the appropriate security permissions to view the records or perform the specific action" message.

So what is the best way to troubleshot this type issue when it occurs?

Well first of all, you should consider which entities are involved in this action. When performing an update or assign action, there could be 2 entities involved. Both the one being assigned and updated and the parent entity that it is being assigned/updated to. That's because there is both the "Append" and "Append To" permissions and if these are not set up correctly it could result in a permission error even when trying to perform an action on a child entity (i.e. the permission problem could be indirect rather than directly on the entity you are trying to perform the action). A discussion of the "Append" and "Append To" privileges is outside the scope of this post, but once again I hope to address both in terms of explaining the difference between these somewhat confusing privileges along with best practices in terms of setting them.

If the above analysis does not lead you to the resolution of your permission error, you should employ the use of the CRM Diag Tool. As an aside, knowing how to properly analyze the log info produced by this tool can save you many support calls with Microsoft support (which will in turn save you time and money).

A good summary for the steps required for analyzing the log info is provided at the bottom of this post. Here is another rendition:

• Run the CRM Diag Tool and enable tracing
• Reproduce the error
• Disable trable
• Open up the log file and run a search on "Error Message" or "Error Number". You should find a section that looks like the following:

Stack Trace Info: [CrmSecurityException: SecLib::CrmCheckPrivilege failed. Returned hr = -2147220960 on UserId: ef295fca-91bf-dc11-99aa-0016353b5824 and PrivilegeId: c2aff40c-6e68-4437-a631-488a354a1860]

• The key piece of information is the Guid of the PrivilegeId
• Take this Guid and plug it into the following query:

select Name from PrivilegeBase where PrivilegeId = 'c2aff40c-6e68-4437-a631-488a354a1860'

...and you should be the returned with the name of the offending privilege: prvReadIncident

That is, in this case, the user does not have sufficient Read privileges on the Incident (aka Case) entity.

• Make some changes to this permission (e.g. increase scope from "user" to "BU") and your problem should be resolved

Infinite Loop Detection

This may be another candidate for the "if I had a penny..." series. It's not a new item but I've come across it enough times that I thought I'd bring attention to it.

Microsoft implemented an "infinite loop detection" mechanism within the workflow process. For example, it's possible for you to design "Workflow 1" that calls "Workflow 2" and then "Workflow 2" calls "Workflow 1" again, such that the workflow - once initiated will theoretically never end. And if these workflows are designed to call each other within moments of being initiated, things could potentially spiral out of control. And it is presumably for this scenario that Microsoft implemented it's "Infinite Loop Detection" mechanism.

You will have encountered this error when you open up a failed workflow and find the "workflow job was canceled because the workflow that started it included an infinite loop" message.

According to literature I've read on this topic, this error only occurs when  "a workflow calls itself (on the same entity) more than 7 times in an hour, the 8th instance will fail with the error..."

While in principle this may be a good mechanism, there are times when it gets in the way of good design. In fact, it can be argued that Microsoft puts such mechanisms into place as the lowest common denominator. Meaning that as Microsoft CRM is essentially a product that is designed for the masses and therefore there is no guarantee that those who "configure" CRM will be responsible enough to make wise decisions. In fact, CRM greatest strength could also - in the wrong hands - be its greatest weakness. That is, the application is so easy to customize/configure that you certainly do not have to be highly trained or technically qualified consultant in order to configure the system. But in the inimitable words of Spiderman: "with great power comes great responsibility". And therein lies the risk because when it comes to system design it is the THINKING - both short and long term - that is paramount. And therefore beyond the capability of being able to perform configuration/customizations on the system it is crucial to know when to add a new attributes, vs. entity, vs. relationship etc. etc. This topic clearly requires further development - perhaps for another time - but I digress, time to reel it in...

The point is that Microsoft - who knows that the product will equally be at the mercy of both the talented and not so talented (when it comes to technology) and that it's impossible to control who will have the keys to the kingdom at any given moment - has put in controls to protect the people from themselves. And this is but one example (another much better example is Microsoft's strict policy of not allowing direct updates to the CRM database - definitely a topic for another time).

Back to the issue at hand - it is perfectly good design to have multiple workflows calling each other. In fact, it could even be a recommended due to the modularity of such a design approach. But yet, if you do so you may hit up against this issue even though your human decision making skills are better than that of a computer in terms of detecting infinite loops - at least in this case.

And the "penny moment" here is - why didn't Microsoft recognize this might happen and give the end user the ability to override the behavior either through a global setting or through a specific workflow setting? Maybe this has been implemented in a different way in CRM 2011 - I haven't had a chance to check. Anyone?

In this case, the absence of such a setting is not that critical as I think the likelihood is that encountering this error is likely to be the result of testing rather than something that would occur in the real world. Because in the real world it is probably unlikely that you'd want to process more than 7 workflow steps in an hour. At least in theory, but even encountering this error in a test environment can be a pain.

Although there apparently is no setting to override this behavior, there is an ability to increase the threshold from 8 as described in this article. I am not sure if there is an upper limit - I remember at one point trying to increase it but still being dogged by the issue at an upper limit. If there's no upper limit, then indeed setting this threshold to a very high number would give a way to override this setting in which case I don't get my penny...

CRM Security Model Part 1

The CRM security model is in my opinion the most complex aspect of CRM that new administrator users of CRM will need to digest. It is not that it is unnecessarily complex but rather complex due to its robustness. That is, CRM can be configured from a security perspective not only in terms of the actions (CRUD along with some other CRM specific options - share, append, append to) that an end user can take on the various CRM entities but also in terms of the scope that a user may take on a given entity. For example, it may be that a user can update account records in CRM (action), but they may be limited to updating only a certain group of contact records (scope). Similarly, a user may be able to view accounts in CRM (action) but may be limited to viewing only a certain group of accounts and not say "corporate accounts" (scope). The same is true for the other actions (known as permissions in CRM speak) such as delete and insert (although insert is decidedly a rarer need in terms of the scope factor).

There is both a hieararchical as well as looser "team" based security model. And when deploying CRM, it is important to understand the structure of the organization in order to understand which model to apply. They are not mutually exclusive and can be combined to facilitate the required security model. Or team based sharing can be automated based on "attributes" of your CRM data in order to create a security model that is more "tag" based. So for example, you could use the team model to make accounts categorized as "investors" to only be view-able or update-able etc. by an "investor" team. You would want to automate such  a feature to ensure that such classification always happens and not to burden end users with extra "sharing" steps.

Yet, even with all the robustness of the security model there are still some gaps. The one that is most often encountered is the Field Level Security issue. For example, although you can control who can view say an account, once the account is view-able, you cannot control (in CRM 4.0 out of the box that is) what fields on the account can be viewed. Of course there are a number of 3rd party tools available to address this shortcoming along with other tricks of the trade that make it possible to surmount this shortcoming in 4.0. Happily, in CRM 2011 this shortcoming has been addressed out of the box so the above is more for the sake of posterity rather than being relevant if you are working with a CRM 2011 installation.

Remember though that MSCRM is an application that has been designed to be generic enough to be applied in all kinds of organizations across the world. And therefore it is pretty likely that a given organization will only require a certain facet of the security model. Consequently the complexity of the CRM security model may vary depending on how you intend to use it. For example, it might be that a deployment only has a need for a single root Business Unit and if so, it will not be necessary to be concerned about the "BU" or "parent-child" aspects of the security model. Or it may be that an organization does not have the concept of "ownership" for records and therefore you can perhaps dispense with the "user" level security. To be sure, I am not advocating ignorance in this regard - it is certainly possible and even likely that a company's implementation of CRM and therefore security model will evolve over time - and therefore it is always recommended  to have a good idea of the capabilities of the security model. However pragmatically speaking - like anything else - your design of the CRM security model should be tailored to an organization's needs and where-ever possible it should be simplified to the extent possible to enable easy administration. At the end of the day, a walk through document relevant to an organization's specific implementation of the CRM security model should be produced to facilitate such an imperative.

This blog entry is titled "part 1" as with this being somewhat of an introduction, I expect that there will be a sequel or two as we delve deeper into understanding the security model and its real-world application.

Auto assign via URL

We were faced with the challenge of being able to auto assign a record as soon as a user clicks on an email containing a link to the record:

I am sure that there is more than one way to accomplish this but the challenge was to differentiate between a user opening the record using the URL from the email versus opening the ticket from standard UI navigation (in which case we would want to suppress the auto-assign functionality).

The best way to achieve this seemed to be by adding a custom URL parameter that we could then manipulate via jscript to perform the necessary processing. However by default if you try and add custom parameters, the form will error out when you try and load.

Luckily, I discovered a blog entry which explained how to go about enabling the feature in the application. Believe it or not, you have to add a registry setting in order to allow this. I am not sure why there would be reason to suppress this in the first place but then again - if I had penny for every time I've wondered why certain features were designed in certain ways (MSCRM and beyond)...

Once this setting was in place, I could then add a URL via workflow containing the custom parameter:

And bob's your uncle! Well almost - of course you need to design the jscript on the form to retrieve the URL parameter (use the code snippet from the referenced blog) and perform the necessary logic to apply the update.

Support for Scribe Insight v6.5.x to be discontinued

Scribe has just announced the end of life for it's Scribe Insight 6.5 product line. Is this something to be worried about if you are still on the 6.5 version? In short, not really. Very often when products get to their "end of life" stage, they tend to be pretty stable platforms. I think Scribe Insight 6.5 falls into this category and therefore I do not consider it "do or die" in terms of upgrading. You probably  haven't had to log a ticket to their support group for quite some time now and chances are you are unlikely to need to do so going forward.

Does this mean I'm recommending against an upgrade to the Scribe 7.x product line? Absolutely not. First of all I'm just trying to prioritize the upgrade requirement amongst the many competing priorities that a company might have. I would therefore not place performing a Scribe upgrade as being a crucial upgrade unless there were some compelling reasons to do so. A compelling reason would obviously be if you have been dealing with a number of support issues. Another compelling reason would be if your company's tolerance levels (whether it be mandated or otherwise) for using an officially "unsupported" product are low. Finally, a compelling reason might be because you want to take advantage of the new features that the new product line has to offer.

Indeed, the last reason mentioned is really a reason for upgrading in and of itself rather than having to deal with end of life support issues. Although perhaps the latter is enough to push you over the edge so to speak...

Officially I do most definitely recommend an upgrade to the latest version of Scribe Insight. This version has been out for quite some time now and therefore you are no longer on the bleeding/cutting edge by doing so. You might even be considered to be a laggard at this stage in the game. That notwithstanding, my reason for this recommendation is most definitely because of the 3rd compelling reason I gave for going for an upgrade namely, to take advantage of the new features that the product line has to offer.

Let me explain. Every new product lines offer capabilities that the previous one did not. The lack of these features may very well impact the way you go about making a design decision. For example, before CRM 4.0 you did not have the benefit of many-to-many relationships and the design approach taken in CRM 3.0 for how you go about representing certain relationships may well have been different than how you would have done so using CRM 4.0. Of course the same applies to CRM 2011. A more relevant example - at some point in time Scribe introduced the Query Publisher into their product offering. Having this feature allowed for more options in terms of integration approaches - something that you would not have been able to even consider in previous versions. The result might be that you end up redesigning some of the pre-existing integrations at some point in the future to take advantage of the new capabilities.

Scribe Insight 7.x introduced a number of new capabilities over it's predecessor. In my opinion, the "game changer" of this release (as it relates to design approach as illustrated above) is the "multi-target" capability. Without going into a whole lot of detail, this feature offers a very oft-requested capability that can simplify and even eliminate some integration threads. Having this capability available may very well change how you go about making your integration design decisions for new DTS's and it is primarily for this reason that I make my upgrade recommendation.

SQL Server Error

After having authenticated to CRM using the newly released Plugin Registration Tool I was then confronted with another issue namely that I could not in fact unregister the plugins. I imagine I would have encountered a similar error were I trying to register a new plugin.

Looking on the CRM server I discovered the issue was the fact that the log file for the MSCRM_CONFIG database was full.

Truncating the log in SQL 2008 is a slightly different affair than it was in SQL 2005. Long story short - you can use the following script to truncate your MSCRM_CONFIG  database:


USE MSCRM_CONFIG;
GO
ALTER DATABASE MSCRM_CONFIG
SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (2, 1);
GO
ALTER DATABASE MSCRM_CONFIG
SET RECOVERY FULL;
GO

In order to not have this issue re-occur, I'd recommend changing the autogrowth for the MSCRM_CONFIG  database as shown in the screenshot. The MSCRM_CONFIG database should be a relatively static database therefore essentially setting it to "unrestricted growth" should be fine.

Plugin Registration not working with IFD

Recently I spent quite a bit of time troubleshooting an issue where the Plugin Registration tool was not working. The issue was attributed to the fact that I was trying to access an IFD On Premise of CRM 2011. Basically I was unable to authenticate into CRM and was receiving the following message:

I tried various other "discovery URLs" without any success.

In the end it turns out that the version of the Plugin Registration tool that I was using was in fact the problem. Luckily a new version of the CRM SDK (and along it Plugin Registration tool) has just been released.

Using the most up to date version of the Plugin Registration allowed me to authenticate. The new version can be downloaded from the following location:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=420f0f05-c226-4194-b7e1-f23ceaa83b69

The infamous No Attribute error

You have no doubt come across this error. While working on some enhancement you might be working in a CRM Form and receive the following upon saving:

Or you might notice that a workflow has failed and when you open it up, you’ll similarly see:

How would you troubleshoot something like this? This may vary depending on the circumstance but here are a suggested set of steps. Let’s assume the No Attribute error was received in a workflow process as shown in the second screenshot above.

• Go into the form and attempt to update the same field that the workflow is trying to update. Chances are that you’ll get the No Attribute error as shown in the first screenshot above.
• Assuming you received this error while saving on the form, use the CRM Diag tool to trace the error:
• Open up the CRM Diag Tool
• Click Enable on the tracing just before reproducing the error
• Reproduce the error
• Turn off tracing
• Find the trace files under the Microsoft Dynamics CRM\Trace folder and open up

• In the trace file search terms like “Error Report:”, “Error Message:” – this should bring you to the part dealing with the error that occurred
• Doing the above you may come up with something like this:

>MSCRM Error Report:--------------------------------------------------------------------------------------------------------Error: 'Incident' entity doesn't contain attribute with Name = 'ci_deptsystemuserid'.

• The above identifies the offending attribute therefore search through your plugins and associated images to see if this field is referenced and remove
• For example, in our case, the attribute is referenced via a custom audit plugin that we developed (in CRM 4.0 prior to the advent of the out of the box version of CRM 2011) that was auditing the field in question:

• Then again, if the attribute wasn’t deleted, we wouldn’t have hit this issue in the first place. However I have already espoused the virtues of keeping the system nice and clean in a former post and therefore I think it’s well worth the effort.