We noticed that certain forms in a CRM 2013 upgraded installation were missing the embedded "Run Report" option in the command bar. It appears in some forms but not in others... with no apparent rhyme or reason. For example, below is a screenshot of the upgraded opportunity form:
Anyone see the Run Report option? Neither do I... and the reason cannot be attributed to there not being any context sensitive reports for opportunities. There indeed are!
Yet... it does appear in the command menu for the grid view. Go figure.
I found this post which pointed me in the direction of the resolution. It references two options for resolution. One by directly modifying the export XML for the entity. And the second by using the Ribbon Workbench tool.
The first solution is the way to go. Quicker and easier and does the job. That is, you just need to add the following command definition to the RibbonDiffXml of the entity.
<CommandDefinition Id="Mscrm.ReportMenu.Form">
<EnableRules>
<EnableRule Id="Mscrm.FormStateNotNew" />
</EnableRules>
<DisplayRules>
<DisplayRule Id="Mscrm.ReadReport" />
</DisplayRules>
<Actions />
</CommandDefinition>
After importing and publishing, the reports have returned to their rightful place (ok I know the report icon is still missing but that is a battle for another day).
The intention of this blog is to focus on the business application of Microsoft CRM and its surrounding ecosystem. In doing so, whenever discussing a topic I will endeavor to avoid presenting dry facts but rather to relate it to the practical application and/or impact it might have on the business, the pros, cons, best practices etc. The correct way of thinking is paramount when confronting a business challenge and this is what I hope to bring to the table.
Tuesday, March 18, 2014
Friday, February 7, 2014
CRM 2013: Compelling Reasons to Upgrade
There are many posts that describe and illustrate the new features that CRM 2013 has introduced. Here are a few choice samples:
Having now spent quite a bit of time working and getting familiar with the new platform, my intention is to try and determine what might be considered features that provide compelling reasons to upgrade assuming that you are on the previous version of the product. That assumption includes the fact that you've spent some time and effort configuring CRM to suit your needs. So while there may be some features that make it easier to achieve certain configuration options that were implemented previously - that in my opinion would not provide a compelling reason to upgrade as there generally is not going to be a burning need to rework the option that has already been implemented and working as desired.
Let's also stipulate that I'm not advocating against upgrading. Rather upgrading is a strategic decision that needs to be weighed with other competing priorities and budgets. And therefore this is more of a question of whether this should be prioritized now or perhaps down the line. And let's make no mistake about it - Microsoft will be spending their time and effort improving the new platform rather than CRM 2011, so if you're planning on performing any major process improvements then you'd be well served to bite the upgrade bullet so you can leverage new capabilities. This post is not for you if you fall into that category. If however you are somewhere in between and looking for features that just may take you to the next level - then this might help put things in perspective.
In my opinion too many posts out there just hype features of the product without providing critical analysis of the real world advantage they're likely to bring. In my list below, I am endeavoring to analyze the features on their practicality and real world application.
POTENTIALLY COMPELLING
FACILITATIVE
INTERESTING
- http://community.dynamics.com/crm/b/crmpowerobjects/archive/2013/09/06/top-10-new-features-of-crm-2013.aspx
- http://community.dynamics.com/crm/b/crmsoftwareblog/archive/2013/08/11/microsoft-dynamics-crm-2013-summary-of-what-s-new.aspx
Having now spent quite a bit of time working and getting familiar with the new platform, my intention is to try and determine what might be considered features that provide compelling reasons to upgrade assuming that you are on the previous version of the product. That assumption includes the fact that you've spent some time and effort configuring CRM to suit your needs. So while there may be some features that make it easier to achieve certain configuration options that were implemented previously - that in my opinion would not provide a compelling reason to upgrade as there generally is not going to be a burning need to rework the option that has already been implemented and working as desired.
Let's also stipulate that I'm not advocating against upgrading. Rather upgrading is a strategic decision that needs to be weighed with other competing priorities and budgets. And therefore this is more of a question of whether this should be prioritized now or perhaps down the line. And let's make no mistake about it - Microsoft will be spending their time and effort improving the new platform rather than CRM 2011, so if you're planning on performing any major process improvements then you'd be well served to bite the upgrade bullet so you can leverage new capabilities. This post is not for you if you fall into that category. If however you are somewhere in between and looking for features that just may take you to the next level - then this might help put things in perspective.
In my opinion too many posts out there just hype features of the product without providing critical analysis of the real world advantage they're likely to bring. In my list below, I am endeavoring to analyze the features on their practicality and real world application.
POTENTIALLY COMPELLING
- Business Process Flow - This is a net new feature, easy to configure/implement and can have a fairly significant impact to the ease of use. Especially for mobile devices such as tablets.
- Exchange Server Side Sync - Although the CRM Outlook Client has made tremendous progress over the years, it still remains the Achilles heel of the product - in my opinion. Mainly because of the decentralized nature of the configuration and troubleshooting headaches when there is a syncing issue. There were 3rd party solutions that allowed this to happen at the server level. And now Microsoft has finally added this functionality to the core product. If you are experiencing issues with contact synchronization then this could well provide the single compelling reason to upgrade.
- Mobile Optimization - The design of the product has been optimized to all mobile devices. Even more impressive - they have produce apps for the iPad, iPhone, Surface, and Android. If you think that mobile enabling your workforce will increase adoption and overall usage, then this is indeed a compelling reason for upgrading.
FACILITATIVE
- Business Logic - There is nothing new about this feature that could not be achieved with form jscript. In fact, you will still need jscript for more involved scenarios. But it does give less techie users the ability to configure simple dynamic behavior on the form and therefore become more self sufficient.
- Quick View Forms - This is definitely a nice new feature that makes it easy to display information from other related entities on the current form. But if you had that requirement previously, there were ways and means to achieve it.
- Real Time Workflows - I'd say this is a very nice new feature that could replace a lot of jscript and plugin requirements. But again this does not enable a capability that could not be achieved in CRM 2011.
- Access Teams - This is a nice new feature that is most likely to be used in scenarios of collaborative selling. The functionality was achievable with the standard team model in previous versions but is a lot more flexible and "on the fly" in the latest version.
- Actions - This extends the programming capability of the product essentially providing the ability to abstract business logic even further. I can see this feature as potentially very useful to minimize the amount of custom code logic making it easier to modify without having to update plugins etc. But again this does not enable a capability that could not be achieved in CRM 2011.
INTERESTING
- User Interface/Navigation - The new version is pretty nice but in some ways can be more challenging to navigate. There are merits to the new user interface but also to the previous user interface. The flat user interface is nice but does not come without a cost (e.g. the benefits of alt+tabbing vs. having to re-navigate to where you were previously). I suspect there will still be a few improvements to come to help optimize this particular experience. And make no mistake about it - upgrading will require you to optimize your form layout to leverage and benefit from the new form layout. If you do not allocate budget for that effort, you are in fact likely to be negatively impacted by the new user experience.
- Command Bar - Microsoft thought it had it all figured out when they introduced the ribbon interface. Only to apparently discover that it was also too overwhelming for the average user and have now scaled it back to the simpler command bar. I do think that they are moving in the right direction with this design change but I hardly think this will make a meaningful difference to those who have gotten familiar with the ribbon interface.
- Dashboards - This feature has been slightly enhanced such that a different default dashboard can be configured for each area (sales, marketing, service, etc.) and per role.
NICE TO HAVE
- Auto-Save - Honestly? BFD.
- Social Pane - Ditto. Maybe I'm old school but this is a feature that I have rarely seen employed. There's already activities and notes and at some point the lines gray between what should be what. And this doesn't really help. Perhaps for larger companies.
- Quick Create Forms - If I'm not mistaken this is kind of a re-introduced feature from CRM 3.0 and earlier. Not revolutionary and unlikely to improve the user experience in any significant way.
- Images - All entities now support associating images to them. Most likely usage is for contacts (although still doesn't sync with the Outlook contact image). Nice if you need it.
Monday, February 3, 2014
Debugging Workflow Plugins in CRM Online
The Plugin Registration Tool has some important features to enable the effective troubleshooting of workflow plugins (and plugins in general). The following posts contain useful walkthroughs of these debugging features:
Debugging standard plugins:
Debugging workflow plugins:
But sometimes I find that adding good old-fashioned trace statements to the plugin code can also come in very handy.
The following illustrates this form of debugging for workflow plugins:
- Add the ITracingService reference
- Output trace information at various points
- Throw an exception to force the trace information to be output
The plugin will fail as you have forced an error by throwing an exception. And you can now go into the failed workflow and view the trace information that was outputted.
Monday, January 27, 2014
Workflow FetchXml Query
Out of the box, workflow does a pretty good job of allowing you to specify test conditions to perform the appropriate branching logic. For example, say you wanted to determine whether a contact's parent account has a credit hold - well... configuration-wise requirements don't get much simpler than this.
Now let's add a wrinkle. Let's say you have an account hierarchy such that you wish to determine whether the contact's grandparent account (i.e. the parent account of the contact parent account) has a credit hold in order to make the necessary branching decision. This minor change in requirement of just pushing the test condition up one level cannot be achieved with the out of the box workflow tools. This is because the workflow Check Condition (and for that matter Wait Condition too) can only interrogate attributes of the current record and of parent records. Any relationship beyond that definition cannot be queried using the standard CRM workflow UI tools.
Fortunately we have a way of breaking out of this box using workflow plugins. I have created a plugin and published it on CodePlex that allows you to pass in a FetchXml query that will be evaluated. The plugin will return to the workflow whether the said FetchXml query returns results and can therefore be used to take necessary branching logic.
Let's use the example above to illustrate how this works.
First define a FetchXml query that will perform the evaluation that you are looking to do (you can use the Advanced Find "Download Fetch XML" to help you with constructing this query). In our case this would be as follows:
<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true"> <entity name="contact"> <attribute name="fullname" /> <attribute name="telephone1" /> <attribute name="contactid" /> <order attribute="fullname" descending="false" /> <filter type="and"> <condition attribute="contactid" operator="eq" value="{0}" /> </filter> <link-entity name="account" from="accountid" to="accountid" alias="ae"> <link-entity name="account" from="accountid" to="parentaccountid" alias="af"> <filter type="and"> <condition attribute="creditonhold" operator="eq" value="1" /> </filter> </link-entity> </link-entity> </entity></fetch>
NB: If you wish to pass in the current record's context as one of the filter criteria make sure that the following is included in FetchXml's condition clause (the attribute should be primary key of the entity that this workflow is running against):
<condition attribute="contactid" operator="eq" value="{0}" />
Now create a workflow and add the FetchXmlQuery step:
Pass in the FetchXml as a parameter to the FetchXmlQuery plugin:
And then define the rest of your branching logic based the results of this query.
If you have configured this correctly, you should be able to see the following results:
Now let's add a wrinkle. Let's say you have an account hierarchy such that you wish to determine whether the contact's grandparent account (i.e. the parent account of the contact parent account) has a credit hold in order to make the necessary branching decision. This minor change in requirement of just pushing the test condition up one level cannot be achieved with the out of the box workflow tools. This is because the workflow Check Condition (and for that matter Wait Condition too) can only interrogate attributes of the current record and of parent records. Any relationship beyond that definition cannot be queried using the standard CRM workflow UI tools.
Fortunately we have a way of breaking out of this box using workflow plugins. I have created a plugin and published it on CodePlex that allows you to pass in a FetchXml query that will be evaluated. The plugin will return to the workflow whether the said FetchXml query returns results and can therefore be used to take necessary branching logic.
Let's use the example above to illustrate how this works.
First define a FetchXml query that will perform the evaluation that you are looking to do (you can use the Advanced Find "Download Fetch XML" to help you with constructing this query). In our case this would be as follows:
<fetch version="1.0" output-format="xml-platform" mapping="logical" distinct="true"> <entity name="contact"> <attribute name="fullname" /> <attribute name="telephone1" /> <attribute name="contactid" /> <order attribute="fullname" descending="false" /> <filter type="and"> <condition attribute="contactid" operator="eq" value="{0}" /> </filter> <link-entity name="account" from="accountid" to="accountid" alias="ae"> <link-entity name="account" from="accountid" to="parentaccountid" alias="af"> <filter type="and"> <condition attribute="creditonhold" operator="eq" value="1" /> </filter> </link-entity> </link-entity> </entity></fetch>
NB: If you wish to pass in the current record's context as one of the filter criteria make sure that the following is included in FetchXml's condition clause (the attribute should be primary key of the entity that this workflow is running against):
<condition attribute="contactid" operator="eq" value="{0}" />
Now create a workflow and add the FetchXmlQuery step:
Pass in the FetchXml as a parameter to the FetchXmlQuery plugin:
And then define the rest of your branching logic based the results of this query.
If you have configured this correctly, you should be able to see the following results:
- When the contact's grandparent account has a credit hold
- When the contact's grandparent account does not have a credit hold
Thursday, January 23, 2014
Error running a report via Outlook Client
Update from Microsoft (3/25/14):
The issue appears to be fixed:
Update from Microsoft (2/20/14):
Update from Microsoft (1/31/14):
In one of our CRM 2013 online instances we are receiving errors whenever trying to run a report from the Outlook client. The error looks something like in the examples below (errors occur one after the other).
This does not happen when running reports via a browser so clearly some kind of platform issue. It is somewhat sporadic too and seems to be related to browser cache. So it might go away and then come back at a later point in time. For example, one solution I tried was to delete/recreate the report as I figured that it was perhaps due to some upgrade issue from 2011. This solved the issue for a while but then it returned.
And this was confirmed by Microsoft who are currently troubleshooting the issue. The following is the current guidance provided by Microsoft:
The issue appears to be fixed:
I received confirmation that the team has processed a change with the NLB system used by CRM Online. As a result, this incident with receiving script errors when running reports from your CRM Online organization should now be resolved.
Update from Microsoft (2/20/14):
After working with my team further, we were able to reproduce this problem internally (not using CRM Online). The problem is specific to a setting on the load balancers used by CRM Online. As such, it appears that this will affect Office365 based organizations (which to be honest makes more sense now). The setting on the load balancers was something recently applied in the move to CRM 2013, however our internal teams are getting approval to undo that change which should resolve this problem. They gave me an approximate 2 week timeframe to get proper approval and undo that change. We’re currently about 1 week through that, so we should be close to having this problem fully resolved.
Update from Microsoft (1/31/14):
The core problem is still being investigated, however a “workaround” was discovered that ties in with the new ‘Process Isolation’ feature of the CRM Client for Outlook. There is a registry key that can be applied on client systems to disable the feature. Testing on our side so far looks promising as the script errors on reports have ceased after disabling the feature. This is by no means a solution to the problem and our teams are still actively investigating. If you wish to test this, I’ve included the registry key below to implement on a client. If you confirm it also works from your side, we can discuss pros/cons of this workaround and if it’s feasible for your organizations.
Key Path: HKEY_CURRENT_USER\Software\Microsoft\MSCRMClientKey (DWORD): UseWebFormProcessIsolationValue: 0
-----------------------------------------------------------------------------------------------------------
In one of our CRM 2013 online instances we are receiving errors whenever trying to run a report from the Outlook client. The error looks something like in the examples below (errors occur one after the other).
This does not happen when running reports via a browser so clearly some kind of platform issue. It is somewhat sporadic too and seems to be related to browser cache. So it might go away and then come back at a later point in time. For example, one solution I tried was to delete/recreate the report as I figured that it was perhaps due to some upgrade issue from 2011. This solved the issue for a while but then it returned.
And this was confirmed by Microsoft who are currently troubleshooting the issue. The following is the current guidance provided by Microsoft:
Per our phone conversation, this issue with running reports in the CRM Client for Outlook against a CRM Online 2013 organization on our CTP authentication platform is currently a known issue that has recently been brought to our attention. We are actively investigating this problem and I’ll keep you posted as I know more. Currently, we believe this may be a server side setting – but the investigation has not yet yielded the exact cause of the problem. Unfortunately there is no workaround for the web client other than using the CRM Web Client (i.e. Internet Explorer).
Wednesday, January 8, 2014
Workflow: Comparing Two Null Fields
You can use the Check or Wait Condition in workflow to compare one field to another field. However if both fields are null then the comparison evaluates to false. For example, say we compare "street 3" of the contact to "street 3 of the parent contact record - if both of these fields are not populated then the comparison evaluates to false rather than true. The following workflow snippet illustrates this phenomenon:
Typically that's what happens when comparing nulls from a database perspective because when you compare null to null you are essentially comparing an "unknown" value to another "unknown" value rather than "nothing" to "nothing" (nothing = nothing; whereas an unknown value cannot be said to equal another unknown value). CRM workflow behaves accordingly. I'm not sure that I would have designed it this way as most humans would look at two empty address fields and you would have a hard time convincing them that they in fact have different values which is what the workflow evaluation is essentially telling them. However this is how it has been designed, so null values need to be taken into account when designing such comparisons.
Out of the box workflow does not have the equivalent to the SQL isnull conversion function which allows you to specify what null "means" and therefore perform a simple comparison (e.g. isnull(field1,'x') = isnull(field2,'x') will evaluate to true if both field1 and field2 are null since in that event they are both converted to "x" and of course x=x).
So one option is to create a workflow plugin that will perform this logic.
In the absence of such a plugin, you could use the following workflow logic to essentially implement this isnull comparison feature. It does tend to make the workflow a little longer... especially if there are multiple conditions to be evaluated as then you need to perform this comparison block for each field be compared. But it does tend to do the trick.
The basic comparison logic is that when the condition evaluates to true then "do nothing". If it evaluates to false, then perform the action associated with a false evaluation and stop processing. At the end of the comparisons, perform the action associated with a true evaluation as if the workflow got to this point, it must have passed all comparisons.
Out of the box workflow does not have the equivalent to the SQL isnull conversion function which allows you to specify what null "means" and therefore perform a simple comparison (e.g. isnull(field1,'x') = isnull(field2,'x') will evaluate to true if both field1 and field2 are null since in that event they are both converted to "x" and of course x=x).
So one option is to create a workflow plugin that will perform this logic.
In the absence of such a plugin, you could use the following workflow logic to essentially implement this isnull comparison feature. It does tend to make the workflow a little longer... especially if there are multiple conditions to be evaluated as then you need to perform this comparison block for each field be compared. But it does tend to do the trick.
The basic comparison logic is that when the condition evaluates to true then "do nothing". If it evaluates to false, then perform the action associated with a false evaluation and stop processing. At the end of the comparisons, perform the action associated with a true evaluation as if the workflow got to this point, it must have passed all comparisons.
Tuesday, January 7, 2014
CRM Online Bulk Update Options
Having previously discussed the challenges with running bulk updates in CRM Online, I thought it would only be right to follow up with a post that provides some guidelines for doing so in the event that this is required. For simple updates you can obviously use the multi-edit feature and for slightly more complex requirements you can obviously use the "re-import from Excel" technique whereby you can export the data, making changes to the data and then import it back into CRM. And finally, if you have third party tools available such as Scribe Online or Scribe Insight you can obviously use those to cover pretty much any update requirement you have.
But what options do you have in the absence of such tools in cases where the update is beyond the complexity of the simple tools provided by CRM without having to resort to programming techniques to achieve the objective?
One alternative is to combine the power of workflow with the "re-import from Excel" technique.
CRM workflow is pretty powerful these days providing a lot of capability of manipulating CRM data using standard workflow actions and freely available codeplex solutions. So assuming your update requirement can be constructed via a workflow all you need to do is to "trigger" that workflow to run against all the records you want it to run against.
This can be achieved as follows:
But what options do you have in the absence of such tools in cases where the update is beyond the complexity of the simple tools provided by CRM without having to resort to programming techniques to achieve the objective?
One alternative is to combine the power of workflow with the "re-import from Excel" technique.
CRM workflow is pretty powerful these days providing a lot of capability of manipulating CRM data using standard workflow actions and freely available codeplex solutions. So assuming your update requirement can be constructed via a workflow all you need to do is to "trigger" that workflow to run against all the records you want it to run against.
This can be achieved as follows:
- Create a custom text attribute called something like "Temp Workflow Update"
- Create your workflow to trigger off the "field change" of this field
- Construct an Advanced Find query that retrieves the subset of records you want to update and include the "Temp Workflow Update" field in the columns
- Export the rows for re-import
- Go into the Excel file and add some text value to your "Temp Workflow Update" field, copy down, save and re-import
- This re-import should now trigger the workflow which will carry out the update that you configured it to perform.
Subscribe to:
Posts (Atom)