Scribe Online

Scribe Online is Scribe's latest product offering. The current offering is limited to work with Microsoft CRM and basically allows for a CRM Online solution to be replicated locally. The value add of such a solution is perhaps a little less obvious than Scribe's flagship offering: Scribe Insight. Simply put - whenever you are entertaining the notion of building any sort of integration with Microsoft CRM (or for that matter standalone databases, or any of the other Scribe templates such as GP, Salesforce etc.), Scribe Insight is going to have to be one of the options considered for accomplishing this. The benefit of using a tool such as Scribe Insight over say, a custom built solution, is fairly substantial and I've reviewed some of the considerations in a former post.

The Scribe Online Replication Service though has - at least to me - a somewhat less obvious niche.

First and foremost, this offering is not meant to be a backup solution which - in fairness - Scribe has made fairly clear. Although CRM Online cannot be backed up as you could for say an On Premise implementation, I think that it has to be kind of axiomatic of the cloud model that your data is secure (I'm sure Google and SalesForce would agree...). Having said that, it could provide companies with a "sense of comfort" that their online data is also available locally. But I personally would not encourage that type of thinking as it goes against the kind of thinking that is necessary in order to move into the cloud.

I think it can also be argued that Scribe Online's Replication Service is perhaps a little anachronistic in that it kind of defeats the purpose of going online in the first place. The major driver for going to CRM Online in the first place is so you can subscribe to the SaaS model and not have to deal with servers, environments, maintenance etc. But yet - here we have Scribe Online that will require you to have a local server with SQL installed in order for it to work...

If so, I think it is fairly clear that the Scribe Online Replication Service is going to be required in a given number of scenarios. So what are these? Below I will attempt to outline where I think such as service can come in handy which is based both on my own considerations and information garnered from Scribe demos:

• Reporting - As highlighted previously, reporting in CRM 2011 Online is significantly more robust than it was in 4.0. And therefore for most companies - at least initially - you should be able to handle the reporting requirements that you have using the CRM Online model. But what if you have sophisticated reported needs? Or better yet - what if you want to create a data warehouse that you can use for setting up Key Performance Indicators (KPIs) to enable you to slice/dice your data in various ways that you cannot do using your operational database (i.e. CRM Online)? Such reporting is typically a more sophisticated requirement to see trends, perform data mining, etc. in order to analyze your business. In such a case, Scribe Online can be a perfect complement to your CRM Online offering allowing you to bring the data into your local environment where it can be combined with Business Intelligence (BI) tools to deliver the goods. I believe that Scribe may also be looking at partnering with BI vendors that may facilitate the delivery of pre-packaged metrics or something along those lines. Time will tell...

• Data Cleanup/Import etc. - Another use could be if you have a need to clean up (e.g. de-dup) your production data but do not want to do it in the live environment. This requirement combines the capability of Scribe Insight with Scribe Online Replication Services. Using this approach, you could bring your data to a local environment, perform all the clean up in that environment, and when you're done you could use Scribe Insight to update your production data.

These are the major benefits that I can think of right now. And based on this, I believe Scribe Online only has value when using CRM Online as opposed to Partner Hosted. With the latter, although your data is still "online" you typically will have more access to your environment, database etc. than in the pure online model. I think it also bears mentioning that the cost of Scribe's Online Replication Service is fairly nominal at $99/month which makes it that much easier to take the plunge should you wish to experiment.

It's still very early days with regards to Scribe's Online offering and the Replication Service is only the first offering using this platform. It will therefore be interesting to see where this product heads as more capabilities get added. For those who want to know more about the strategic direction of this product, you can review Lou Guercia's (Scribe's president and CEO) interview with IT Business Edge.

Extending the IFD timeout

After deploying IFD, we noted that the default ADFS timeout setting was too short and kept on timing out users.

The IFD Configuration guide has a section describing how to modify the timeout setting. The following is a simple walkthrough:

• Open up a windows powershell session

• In ther powershell session type in: 
• Add-PSSnapin Microsoft.Adfs.PowerShell
• Get-ADFSRelyingPartyTrust -Name:"Relying_Party"
• Set-ADFSRelyingPartyTrust -TargetName:"Relying_Party" -TokenLifetime 480

Note that the Relying_Party value should be the Relying Party you see in ADFS. So in this example it would be "CRM External".

The token lifetime is in minutes, so 480 equals 8 hours.

CRM 2011 IFD Setup: Part 2

My previous post refers to some resources for setting up IFD in CRM 2011. Overall the process looks scarier than it actually is. And the benefit of having IFD is that you can access CRM without having to jump through any firewalls etc. in about the same way as you can access your webmail from any location (or maybe not in your case...?). Not to mention the fact that some third party solutions may require that you have IFD set up as a prerequisite for configuring the solution.

Anyway when you walk through the videos, you will have ended up creating at least 4 URLS (which you'll need to configure in your DNS):

• adfs.yourdomain.com (or sts1.yourdomain.com as shown in one of the videos) - External facing. URL used for authenticating to ADFS.
• auth.yourdomain.com - External facing. Your IFD federation endpoint.
• dev.yourdomain.com - External facing. Discovery web service.
• org1.yourdomain.com - External facing. Your IFD access URL for your CRM organization (org1 = whatever your CRM organization name is)

I say "at least 4" because you may end up with more. This would be the case if:

• You create an internal alias for your CRM deployment e.g. crm.yourdomain.com (you may do this even if you're not configuring IFD but as it's mentioned in the video I thought I'd mention it here too)
• Access to additional organizations in your CRM deployment. Relevant if you're a hosting partner or for whatever reason you decide to have multiple orgs in your company's deployment (this will be the subject of a future post). For example:
• org2.yourdomain.com
• org3.yourdomain.com
• ...
• orgn.yourdomain.com

CRM 2011 IFD Setup

Setting up an Internet Facing Deployment in CRM 2011 is very different from it's predecessor. CRM 2011 uses ADFS to enable the IFD access.

Microsoft has an article with links to white papers and a video for setting this up.It should be pointed out though that the above article originally linked to the following video for configuring IFD:

http://www.youtube.com/watch?v=T9jZIxDTsBw

At around the end of April, another video was linked to the article:

http://www.youtube.com/watch?v=ZD5qaa-G99E

The reason I mention this is because I think both videos are helpful. The original video is more useful if you are deploying ADFS on the same server as where you have CRM installed. Whereas the second is better if you are deploying ADFS on a separate server.

For example, when deploying ADFS on the same server as you have deployed CRM, you will only require a single Relying Party Trust (assuming a single domain), Whereas the second video will walk you through setting up two relying party trusts which can perhaps be confusing.

Just my 2 cents.

Upgrading to MSCRM 2011

We upgraded our internal installation from CRM 4.0 to CRM 2011 several months ago so this entry is from memory. But in a nutshell, the upgrade from CRM 4.0 to CRM 2011 was by far the smoothest one yet.

Essentially all we needed to do was take the CRM 4.0 old database, import it onto the new SQL 2008 server and then use the CRM 4.0 import manager which pretty much took care of the rest. At that point, we just had to sit back and wait and put our faith in Microsoft... (which is true any time you click that "install" button at the end of the installation wizard process).

What's nice about this type of upgrade where you move to a new server is that you can pretty much leave your existing 4.0 installation in place until you've crossed the proverbial rubicon. Therefore the risk factor is much lower and you always have the option of rolling back (although you should never have to exercise that option...).

Obviously there are a lot of other things that need to be planned for and verified post upgrade such as plugins, reports, workflows etc. which will vary from installation to installation - those should be part of your due diligence upgrade plan. But assuming those have all been accounted for, the upgrade experience has thus far been a very smooth one.

The only things encountered in our internal upgrade were some strange "unknown" headers  appearing in the system:

Not exactly sure why these came about but it's likely due to the fact that we had made some changes to our 4.0 Site Map that caused the upgrade to get confused. Anyway this was easily handled by exporting the Site Map, adding title attributes to the relevant Groups and reimporting:

        <Group Id="System_Setting" Title="System">

The other oddity was that certain sections were missing the header groupings altogether:

Once again this was solved by going to the Sit Map and adding the ShowGroups attribute to the relevant areas:

 <Area Id="MA" ResourceId="Area_Marketing" Icon="/_imgs/marketing_24x24.gif" DescriptionResourceId="Marketing_Description" ShowGroups="true">

And that was pretty much it.

Importing Customizations in CRM 2011

My previous post dealt with approaches for exporting  customizations from CRM.  Importing the customizations has also changed a little.

In CRM 4.0, the export file was self contained and it could be imported from anywhere. You also had the ability of importing zip as well as xml files. When you imported files such as the Site Map and ISV.config files, the changes took effect immediately.

In CRM 2011, the exported zip contains some additional files such as those shown below:

The only file you want to be editing is the "customizations" file. Once you have finished making your edits (e.g. Site Map modifications) you'll need to zip up the parent folder (SiteMap_0_1 as shown in the screenshot above) and import the zip file as shown below:

Finally, note that unlike 4.0, you'll need to publish for ALL imports before the changes will take effect.

Exporting Customizations in CRM 2011

In CRM 4.0 exporting customizations was straight forward. You just went into the Customizations | Export section of CRM, selected the entities you wished to export and export. You could then make modifications to your exported files (such as the Site Map or ISV.config) and go into CRM and re-import the modified file.

With CRM 2011, this process has become slightly more involved due to the introduction of the concept of "Solutions". You can still very easily export all customizations by navigating to Customizations | Customize the System | Export Solution.

However what if you just want o export individual files as you could do in 4.0? It is easier to make modifications to say the Site Map if it's the only exported file than trying to work with the global export file.

As the Site Map and ISV.config (now Application Ribbon) are arguably the files you most frequently want to export, you may want to create a solution for each of these and then another general "export" solution for backing up other customizations files. Something like what is shown below:

...with the SiteMap solution (for example) just containing the SiteMap extension in it:

From now on to export the Site Map, all you'll need to do is open up the Site Map solution and click Export Solution.

It goes without saying that the above is not to get around the "solution" functionality in CRM. You should use solutions for what they were intended - managing the delivery of new functionality. But for quick tweaks such as modifications to the Site Map - while you can be a purist and create a solution for each one - it might make more sense to follow an approach like the one listed above.

Distribute Workflow for CRM 2011

In CRM 4.0, a wonderful little free workflow plugin was introduced that allowed workflows to be distributed. This can be downloaded from codeplex. The idea behind this workflow plugin is simple and effective. For example, say after completing a campaign, I wanted to generate a follow up activity on each opportunity generated from the campaign, I could create a single workflow against the parent campaign monitoring the campaign status and as soon it was completed, I could generate workflows to be kicked off for each of the child opportunities. So one workflow could spawn sub-workflows for all it's children. Useful in many different scenarios.

The functionality described above was not out of the box in 4.0 and I don't believe it is out of the box in CRM 2011 either (please enlighten me if I'm wrong as I haven't researched this to the Nth degree). So why am I mentioning this?

Well in light of my previous blog entry which discussed limitations with CRM 2011 Online - one of the limitations was that workflow plugins are not supported... And guess what - the utility mentioned above is in fact a workflow plugin which means that if you've deployed this feature in your on premise installation, you may have difficulty replicating this functionality if you decide to move to CRM 2011. So either you will need to dispense with the functionality or come up with another creative way for handling the requirement. Of course, upgrading to CRM 2011 on premise does not present the same challenge, since workflow plugins can be added in that case.

If anyone is aware of a way of executing the workflow distribution logic in CRM 2011 Online in a simple and elegant manner as the aforementioned plugin enabled - your input would be appreciated.

MSCRM 2011 - Going into the Cloud Considerations

In CRM 4.0 there were some major limitations if you decided to go into the cloud with CRM Online (vs. On Premise) that required careful consideration. A good detailed comparison can be viewed here.

However, from a practical point of view, the following were the most significant high level limitations:

• Reporting - custom reports are limited to out of the box views, the report wizard or you could create with significantly greater difficulty some aspx type reporting using FetchXML

• Plugins - no ability to add custom extensions to the application

The good news is that CRM 2011 Online has overcome these limitations to a large extent. However not completely:

• Reporting - custom reports can now be created using a FetchXML extension to BIDS. You can find a good introduction of this capability here. While this does provide a good workaround solution it should be mentioned that you are still limited to the FetchXML framework. That is you can only retrieve data from CRM in ways that FetchXML will allow you to. FetchXML was limited to relatively simple queries in 4.0 and the good news is that it's been expanded to be able to include aggregate functions such as GROUP BY which are important when it comes to reporting. However FetchXML is still bound to be more restrictive than it's SQL counterpart - the latter can be manipulated in virtually limitless ways, if not by a SQL statement, then by employing the use of cursors, dynamic SQL etc. to achieve the desired result set. 

• Workflow plugins - while standard "trigger" plugins can now be added to the CRM 2011 Online deployment, you are still unable to deploy workflow plugins. A "trigger" plugin is executed synchronously or asynchronously as a direct result of an event (update, insert, delete) that is made to an entity (for example, good for validation, calculation etc. logic). A workflow plugin is executed by the workflow engine which is useful if an advanced function needs to be called as a result of a more protracted workflow that gets generated due to some condition in the environment. Although through some fancy footwork it should be possible to leverage the "trigger" plugin to work around this limitation (for example, creating a custom entity that gets updated by the workflow and "trigger" plugins are designed against inserts to the custom entity - just theorizing)

In summary, while the workflow plugin limitation is not optimal I do believe it can be worked around. However if your organization has complex reporting (read: above average) or if you are upgrading an existing installation where reports have employed dynamic/advanced reporting techniques or need to join to data that sits outside of the CRM database, then you may want to give this further consideration before moving into the cloud.

One final point, if you are upgrading your existing on premise installation and you have many custom reports that have been written, you'll need to consider the effort that it will take converting those to the FetchXML cloud model equivalent.

Adding a hyperlink to a form using an IFrame

There are a number of ways to add a hyperlink to a form. You can create a custom field and convert that into a hyperlink. However an arguably better way is to use an IFrame since you can save on having to modify the schema by doing so.

Using an IFrame is not complicated, but one thing I struggled with a little was to give the link a nice underlined blue color as is standard for hyperlinks. Without formatting, the hyperlink will just appear as text in the form without any visual indicators that it is a hyperlink (other than when you hover over it the mouse pointer will change to a hand) as shown below:

Other than creating the IFrame as recommended in the screenshot below:

The only other requirement is to add the following somewhere in the jscript of the form onload event:

crmForm.all.IFRAME_RatePlan_d.innerHTML ="<a href='www.someurl.com'  target=_blank>Rate Plan Summary</a>";

I am not sure if this is the only way to go about it (I somehow doubt it), but in order to get the nice underlined blue hue, all you have to do is add the syntax highlighted below:

crmForm.all.IFRAME_RatePlan_d.innerHTML ="<a href='www.someurl.com' style='color: #0000ff; border-bottom: 1px solid #0000ff' target=_blank>Rate Plan Summary</a>";

And then it will render like this:

Perhaps a small tweak but a big difference as far as user experience is concerned.

On Integration

On numerous occasions I've had the question posed to me whether it is necessary to use a tool such as Scribe for building integrations vs. using CRM web services (or using eConnect for integrating to GP as opposed to Scribe and so on and so forth).

I think the question itself indicates that there is perhaps a misunderstanding of what the term "integration" really is all about.

First of all, by way of disclosure, I highly recommend using an integration tool for tying systems together. Scribe is an excellent example of a tool for building integrations with MSCRM that I fully endorse. The rest of this blog entry will attempt to both answer the question as well as justify this recommendation.

In short, when it comes to integration, it is really not a question of Scribe vs. CRM web services but rather Scribe and CRM web services. In short, there is nothing stopping you from creating an "integration" using the CRM SDK and web services but to do so is reinventing the wheel to a large extent. It needs to be remembered that "integration" is not just the act of making one system talk to another - that is arguably the easiest part of the long term effort. A successful integration strategy has a number of other components, including:

• Loosely tying systems together. We do not want the source application to be tied to the target application in such a way that if the target application is down, the source application is down too. Such would be the case if we were to build a simple “synchronous plugin” integration approach (an "asynchronous plugin" would result in the integration disappearing into the good night when the second system is down).
• Queueing. It is important to be able to queue integrations up such that under load or under the scenario described above where one system is down – items get written to a queue and are integrated as soon as the target application can accept them. 
• Retries. When an integration fails it is important to be able to have an effective automatic as well as manual retry mechanism. Sometimes an integration fails for a condition that will self correct and will succeed on the next retry. For troubleshooting purposes, it must be easy to have a way to retry an operation to get to the root cause. In short an integration must either succeed or if it fails it should fail “noisily” so it can be proactively addressed.
• Alerts. It’s important to be able to set up a proactive alert mechanism if there are issues with integration. This helps to quickly identify and resolve issues as they arise.
• Customizability – It’s important to be able to easily modify an integration for changing business needs. It’s equally important to use a tool that is supported, has easy access to training and/or qualified resources. It also helps for the tool to be a “configuration” rather than “development” tool.
• Console Management. It’s important to have a console that provides a single view of integration activity (especially when there are multiple integrations going on) as well as an ability to stop and start integrations in a simple manner.

A product like Scribe brings all of these capabilities out of the box. Scribe also leverages what are referred to as "adapters" for integrating to products such as MSCRM. And when we refer to the Scribe adapter, we mean the capability of Scribe to automatically expose and talk to all MSCRM web services; similarly when we refer to the Scribe adapter for GP we mean the capability to automatically expose and talk to all GP eConnect routines. It's not a matter of either/or as posed above but rather whether you want to build a robust integration strategy using off the shelf tools that will stand the test of time.

System attribute cannot be delete because it used in one or more workflows

This follows my previous blog entry on Removing Artifacts.


MSCRM does a pretty good job so that you don't get into trouble when removing attributes from the system. Before you will be allowed to do so, it will verify that the attribute is not being used in any published form, view, or workflow in the system. For forms and views, the error message explains quite clearly which form/view needs to be updated before the attribute can be removed.


However when it comes to workflows, you just get the following generic error:

If you have hundreds of workflows it can be quite a daunting task to locate the offending one. So how can the workflows be identified? Query the database. You can use the following query to get you going:

select distinct name fromworkflow

where rules like '%custom_attributename%'
and deletionstatecode = 0
and statecode = 1
and primaryentity = 112

One thing to be cautious of is that there may also be active workflow instances that reference the field that you are removing and CRM does not (in my experience) prevent the attribute from being removed on account of an active worklow instance. Only published workflow definitions that reference a particular attribute will be prevent that attribute from being deleted. This means that you should take into consideration the impact that deleting an attribute will have on active workflows that might be running. If you do so and there is an active workflow instance, you can expect to see something like the following appear in your workflow:

A similar "invalid condition" will be shown in any unpublished/draft workflow definitions that reference the deleted field.

To help prevent such a scenario from occurring, you can also query the database to discover workflow instances of the published workflow definition that you identified in the above query:

select statuscode from AsyncOperation

where Name like 'name of workflow'

and statuscode in (0,10,20,21)

As perhaps a better alternative, you can also use the CRM Advanced Find to query these records and take the appropriate action:

Removing Artifacts

Over time as you go about using and configuring your CRM solution it is likely that you will replace an older design with a newer design to facilitate some business process. This may come about for a variety of reasons:

·        New features in a newer version CRM that allow you to go about solving the problem in a more efficient, direct way

·        Budget constraints that restricted the original design – perhaps there is now budget to purchase a 3rd party solution to replace an interim solution that was put in place

·        Lessons learned – both in terms of technology, experience gained from other implementations, or feedback from end users who decide that the solution needs tweaking

Whatever the reason, it's important to keep the solution clean. By this I mean removing the "artifacts" that may build up as part of this natural evolution of configuring CRM within an organization. Leaving in attributes that are no longer in use is not good practice for a number of reasons, some of which are:

·        Over time it can lead to confusion when trying to understand how a particular part of the application works. Keeping the system nice and clean is good in and of itself but also saves time in the long run by not having to spend time trying to separate between the wheat and the chaff

·        Although you may have cutover to the newer functionality it's possible that there are old reports or the like that still reference the old artifacts. If you remove these attributes the reports will fail the next time they run, however it is better to have a report fail noisily (of course expectations should be set) so it can be addressed, than continue to function and return wrong and/or misleading information

·        Performance – This one is fairly obvious. To keep the system running at optimum levels it is always advisable to keep them as lean and mean as possible.

       

Of course, removing artifacts doesn't have to be performed as part of the cutover to the new functionality. In many circumstances it may be prudent to wait a day or two, or even a week or two after a cutover event. For example, it may be possible that data was converted as part of the cutover event, but perhaps certain data got missed or skipped over (of course, this never happens when working with Sentri!) – having the artifact data available can allow you to correct the data quickly. Alternatively, it might be possible that for whatever reason you need to rollback to the previous functionality and of course having the old attributes along with the accompanying old data makes this that much easier to do. In short, it is recommended to create a follow up task pending a cutover event to remove artifacts from the system at a not too distant time in the future.