It appears that the javascript getServerUrl() function will become deprecated with the release of Update Rollup 12 for CRM Dynamics 2011 (imminent). As far as I can tell, from that point forward there will be a new function called getClientUrl() that should be used instead.
No doubt the reason for the deprecation is due to the fact that the getServerUrl() function cannot always be relied upon to return the correct server context as described in an earlier post (and therefore the workaround solution described in that post should no longer be necessary).
We'll have to get back to this to confirm once the rollup has been officially released.
Wednesday, December 26, 2012
Form Query String Parameter Tool
The Dynamics team recently released a new utility called the Form Query String Parameter Tool. Essentially it's a useful little utility that can be used to generate the syntax of a create form URL passing in parameters to default field values when the new form is opened.
Having said that, I believe that in in most cases using the URL parameter passing approach for defaulting values on the create form should not be necessary. The rest of this post will explain this point of view.
First of all, the out of the box "field mapping" approach - whereby field values from the currently open parent entity are mapped to the child entity form being opened - should be used where ever possible. This covers scenarios where the default values are static regardless of the form "context" and the field being mapped is in fact "mappable".
If the default values are dependent on the form "context" (e.g. new accounts where type = "customer" should have different defaults than cases where type = "vendor") or if the field being mapped is not "mappable" then your next best bet is using javascript on the form load event to set the defaults. Using javascript you can set all the appropriate fields as long as you have a field populated on the form in order to make the necessary branching default logic (the form "context" field). The form context field may be set using either standard field mapping, a web service API call (as explain below) or via URL parameters. Once obtained the javascript default logic can take over.
Using the URL parameters approach would therefore only seem to be necessary when you don't have a form "context" field on the form that is being opened. However this is not necessarily the case either since you can also leverage the web service calls (RESTful or SOAP) in order to retrieve the "context" from the parent field in order to perform the necessary branch logic.
Therefore it would seem that using form parameters to set default values would be necessary to only a fairly limited set of scenarios. This would be a scenario where all 3 conditions listed below are true:
Finally, even in the remaining few scenarios that do require the URL mapping approach, it is really only necessary to pass through a single URL parameter - that will set the context and javascript can subsequently take over for the remaining default logic.
Therefore, when all is said and done, while it's always nice to see new tools being developed to facilitate the customization effort, I do not see myself using this particular one all too frequently.
Perhaps there are scenarios that I'm not considering? If I encounter them I'll be sure to dish.
One scenario encountered is with differentiating between multiple 1:N field maps for the same two entities as described in this post.
Having said that, I believe that in in most cases using the URL parameter passing approach for defaulting values on the create form should not be necessary. The rest of this post will explain this point of view.
First of all, the out of the box "field mapping" approach - whereby field values from the currently open parent entity are mapped to the child entity form being opened - should be used where ever possible. This covers scenarios where the default values are static regardless of the form "context" and the field being mapped is in fact "mappable".
If the default values are dependent on the form "context" (e.g. new accounts where type = "customer" should have different defaults than cases where type = "vendor") or if the field being mapped is not "mappable" then your next best bet is using javascript on the form load event to set the defaults. Using javascript you can set all the appropriate fields as long as you have a field populated on the form in order to make the necessary branching default logic (the form "context" field). The form context field may be set using either standard field mapping, a web service API call (as explain below) or via URL parameters. Once obtained the javascript default logic can take over.
Using the URL parameters approach would therefore only seem to be necessary when you don't have a form "context" field on the form that is being opened. However this is not necessarily the case either since you can also leverage the web service calls (RESTful or SOAP) in order to retrieve the "context" from the parent field in order to perform the necessary branch logic.
Therefore it would seem that using form parameters to set default values would be necessary to only a fairly limited set of scenarios. This would be a scenario where all 3 conditions listed below are true:
- The fields cannot be defaulted via standard parent/child field mapping
- The form does not contain a form "context" field on which to base javascript branching logic
- A standalone form that is not linked to another form from which the "context" can be retrieved using web services
Finally, even in the remaining few scenarios that do require the URL mapping approach, it is really only necessary to pass through a single URL parameter - that will set the context and javascript can subsequently take over for the remaining default logic.
Therefore, when all is said and done, while it's always nice to see new tools being developed to facilitate the customization effort, I do not see myself using this particular one all too frequently.
Perhaps there are scenarios that I'm not considering? If I encounter them I'll be sure to dish.
One scenario encountered is with differentiating between multiple 1:N field maps for the same two entities as described in this post.
Thursday, December 20, 2012
Simplifying Navigation: Add to Favorites
This post is another in the series on Simplifying Navigation - it is somewhat of an "oldie" but definitely a "goodie". And I have also verified that the same issue and workaround exists using Outlook 2013.
In short, the issue is that the CRM area within the Outlook Client is somewhat buried. For example, if you wish to navigate to the Accounts, it will involve at least 3 clicks (if this area was not previously opened):
In addition to that, if you are more than likely to access a particular entity from your CRM data it would be helpful if you could separate it from the rest of the group.
And fortunately you can by simply dragging and dropping the CRM folder to your Outlook "Favorites" folder which will you give single click access to your CRM data. Much better.
As an aside, it appears that in Outlook 2013 the UI has been simplified and the icons for all the folders have been removed... including the CRM icons. Not sure if this is a long term feature or something that will be tweaked in future Office patches (I personally haven't yet decided whether I prefer it this way or not).
The issue that you may encounter is that the aforementioned drag and drop capability might not be working. And if that is the case, you need to enable this feature by running through the steps in this KB article. Or you can just download this file, unzip and double click to deploy it in your environment (this will add a single registry setting called DisabledSolutionsModule under your MSCRMClient key).
Another option that allows for a little more organization of your CRM links is to use the Outlook "shortcuts" option. In order to make this effective the first thing you should do is go to the Navigation Options and move the shortcuts up in the list so it appears in plain sight as shown.
You can then add new shortcuts to the CRM folders of your preference:
And now you can click on the shortcut to navigate to your CRM data:
In short, the issue is that the CRM area within the Outlook Client is somewhat buried. For example, if you wish to navigate to the Accounts, it will involve at least 3 clicks (if this area was not previously opened):
In addition to that, if you are more than likely to access a particular entity from your CRM data it would be helpful if you could separate it from the rest of the group.
And fortunately you can by simply dragging and dropping the CRM folder to your Outlook "Favorites" folder which will you give single click access to your CRM data. Much better.
The issue that you may encounter is that the aforementioned drag and drop capability might not be working. And if that is the case, you need to enable this feature by running through the steps in this KB article. Or you can just download this file, unzip and double click to deploy it in your environment (this will add a single registry setting called DisabledSolutionsModule under your MSCRMClient key).
Another option that allows for a little more organization of your CRM links is to use the Outlook "shortcuts" option. In order to make this effective the first thing you should do is go to the Navigation Options and move the shortcuts up in the list so it appears in plain sight as shown.
You can then add new shortcuts to the CRM folders of your preference:
And now you can click on the shortcut to navigate to your CRM data:
Thursday, December 6, 2012
Data Import Options
When discussing data imports to CRM there are 2 distinct scenarios:
Data Migration
Data Migration generally refers to a large scale conversion effort and is typically performed as part of a CRM Go Live effort where data is migrated from the legacy system and is usually quite an involved effort. This exercise is technical in nature, typically performed by IT professionals and requires a great attention to detail. Correspondingly the migration logic is also usually quite involved. Meaning that there can be quite a bit of data transformation as part of the migration exercise. And if migrating from another system, you typically want to be able to connect to the data in the legacy database rather than extracting the data to an intermediate CSV file. So as a general rule of thumb when doing this type of data migration you typically want to be using a tool like Scribe to make it happen.
Importing Data
Importing Data generally refers to a more specific one-time or ongoing requirement to import data into a live CRM environment. For example, the need to import new leads into the CRM database. Typically this is a more straight-forward "one-to-one" exercise (i.e. no data transformation required) and if this is the case, the out of the box "Data Import Wizard" can be used for this function.
One thing to note is that while the "Data Import Wizard" has advanced by leaps and bounds, it still has one chief limitation - it only can import new records. If you're looking to use the wizard to update existing records, I'm afraid you're fresh out of luck. And if that is a requirement you'll once again need to look for a 3rd party tool such as Scribe.
For an excellent general overview of the features and functions of the Data Import Wizard please refer to this post. At the end of the post it lists a number of 3rd party tools that can be used to fill the gap in functionality of the Data Import Wizard should you encounter it. Although none of these products have what I would term a "no-brainer" price. Below is a rough comparison in pricing of the various tools on the market (as of this writing):
The following tools do not seem to fulfill the requirement:
Data Migration
Data Migration generally refers to a large scale conversion effort and is typically performed as part of a CRM Go Live effort where data is migrated from the legacy system and is usually quite an involved effort. This exercise is technical in nature, typically performed by IT professionals and requires a great attention to detail. Correspondingly the migration logic is also usually quite involved. Meaning that there can be quite a bit of data transformation as part of the migration exercise. And if migrating from another system, you typically want to be able to connect to the data in the legacy database rather than extracting the data to an intermediate CSV file. So as a general rule of thumb when doing this type of data migration you typically want to be using a tool like Scribe to make it happen.
Importing Data
Importing Data generally refers to a more specific one-time or ongoing requirement to import data into a live CRM environment. For example, the need to import new leads into the CRM database. Typically this is a more straight-forward "one-to-one" exercise (i.e. no data transformation required) and if this is the case, the out of the box "Data Import Wizard" can be used for this function.
One thing to note is that while the "Data Import Wizard" has advanced by leaps and bounds, it still has one chief limitation - it only can import new records. If you're looking to use the wizard to update existing records, I'm afraid you're fresh out of luck. And if that is a requirement you'll once again need to look for a 3rd party tool such as Scribe.
For an excellent general overview of the features and functions of the Data Import Wizard please refer to this post. At the end of the post it lists a number of 3rd party tools that can be used to fill the gap in functionality of the Data Import Wizard should you encounter it. Although none of these products have what I would term a "no-brainer" price. Below is a rough comparison in pricing of the various tools on the market (as of this writing):
- Scribe:
- $3000: 15 user license
- $5500: 100 user license
- $1900: 60 day migration license
- Inaport:
- $1799: standard (should be sufficient for import function)
- $3499: professional
- $1195: 30 day migration "professional" version which is apples to apples comparison for the Scribe migrate license)
- Import Manager (best option if end user interface is required)
- ~$2500
- Import Tool (attractive pricing)
- ~$1300: Full Version
- ~$325: 60 day migration license
The following tools don't seem to be realistic candidates based on their price point:
- Starfish
- $4800/year: Basic Integration
- $1495: 60 day migration license
- eOne SmartConnect
- $4500 (not sure if this is a one time or per year fee)
- QuickBix
- $7000: 100 user license ($70/user)
- Jitterbit
- $800/month: Standard Edition
- $2000/month: Professional Edition
- $4000/month: Enterprise Edition
The following tools do not seem to fulfill the requirement:
- CRM Migrate
- Tool specifically built for migrating SalesForce to CRM
- CRM Sync:
- Very little information and no pricing for this tool
Subscribe to:
Posts (Atom)