Monday, December 12, 2016

Beware of Legacy forms and how to fix broken case forms after upgrade

Been working with the upgrade of a customer from CRM 2013 to CRM 2016 on-prem and we ran into this weird error. The case form didn't want to work after upgrade if we didn't turn of the turbo forms. For those of you who are not aware of this, in 2015 Spring wave, there was a revision of how forms were loaded, called the turbo forms. After this version there is a setting in the first tab of System Setting where you can turn on "Legacy form rendering" if you want to go back to the old rendering method.

However, we noticed some other strange errors, for instance bool fields with Yes/No values with No as default, were shown as "False" when the form was in create state. Once the form had been saved this error went away.

Another error we saw was that if you tried to save emails, (not send them), you got an error message. The email got saved anyway, but you got a nasty message.

However, if we switched back to turbo forms, both this email error and the bool-error disapeared. Hence, it seems the legacy form controls are not nearly as well quality tested as the turbo form versions so I would strongly suggest that you do not use them unless you have no other option, and then try to move away from them as soon as possible.

So, trying to stick to my paradigm for troubleshooting; "Find where the error is first, then what the error is" - I wanted to go back to the case entity and find out why the turbo forms didn't work.

Rickard and I, who were troubleshooting this together, enabled the dev-mode in IE (pressing F12, if you don't know it) and opened a case. The odd thing was that the point where it broke was in one of Microsoft's functions. I have been unable to recreate the error now so I cannot show it. And after some nitty gritty debugging in IE, we found that the script seemed to be missing "productid" and "primarycontactid" or in laymans terms, Product and Contact.

So, I added them to the case form, and magic! It worked.

But the story doesn't end there. As I thought that this might be a good blog article and I wanted to recreate the error to have as a screendump, I removed the fields again... and mark my surprise when the form still worked... twilightzone.

Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Sunday, November 20, 2016

Getting started with AppDesigner

During the CRM UG Summit I was approached in the Medic booth by two nice guys from Microsoft  who asked me if they could show me and get my opinion on a new feature of Dynamics 365. It was the AppDesigner. There had been so much hype around a lot of the other stuff (editable grids, editable grids, editable grids) that I hadn't noticed this and when they showed it and I had time to think about it I recognized that it is really a cool and useful feature that I think can do a lot of good in the system.

One of the things I try to evangelize about is to slim the system down, not "dumb it down" but make it slim, and efficient to what you are trying to do. Hence not include a lot of unnecessary stuff. The AppDesigner is excellent for this, it creates subsets of Dynamics 365 (not operations/financials) into what are called apps. With their own sitemaps, view sets, form sets, business process flow sets, chart sets.

I made another film about this, on how to enable and get going with it. Why not watch it?


Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Tuesday, November 01, 2016

Video - How to enable editable grids

So, time to try something new. I recorded a small screencast with SnagIt to show how easy it is to enable the awsome new feature Editable grids in Dynamics 365. So, please have a look and let me know what you think!


And yes, I know I keep saying CRM, and Dynamics CRM. I have been working with this product for more than 11 years now. It's going to take some time for this old dog to sit.

Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Dynamics 365 is up!

It is here!

I just spun up a trial of Dynamics 365! So do it yourself and go check out all the awsome cool functionality everyone has been talking about!

For now, this is news enough!


Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Monday, October 24, 2016

Extending Max amount of components on dashboards only for onprem

Some of you might have found some sites like this https://msdynamicscrmblog.wordpress.com/2014/05/23/how-to-change-the-dashboardsettings-of-maximum-controls-limit-in-dynamics-crm20112013/
one:
I, Soupeurfaive, via Wikimedia Commons

or even the original MSDN or Technet sites regarding how to be able to change the maximum amount of components on a dashboard from the maximum of 6 to for instance 8 using PowerShell.

On the MSDN and Technet pages there are some default CRM version text in the header and footer but make no misstake, you can only do this change in a CRM onprem environment where you are the deployment admin.

As the change is deployment wide and you need to have deployment administrator access rights, you are also extremely unlikely (unless you have a dedicated Online environment) to get that set.

Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Sunday, October 02, 2016

Dynamics 365 and the hopes for the Common Data Model

As many of you probably have heard Dynamics CRM will as of Nov 1 2016 be part of Dynamics 365 in a commendable push from Microsoft to bring the Dynamics products closer together. This is partly a branding thing as the products themselves, as Dynamics CRM, will still be the same product from a technical perspective, at least in the Enterprise Edition, (little is known of the Business Edition) and partly a technical concept as they are introducing something called the Common Data Model which is canonical data model (unified data model) to which all "Apps" are integrated to automatically. This is what I wanted to discuss some.

This all sounds great, and I will admit that I havn't had time to fiddle with it yet, but I have had the pleasure of working with quite a few integration projects between CRM and ERP. And that is not easy, even if you do have a ready made point-to-point integration. So I would just like to make a few points that I hope you do consider before switching it on and hoping it will solve all your issues.

1. Addresses in ERP and CRM are typically not the same. In ERP the addresses that are needed can typically be invoicing address and delivery address, while in CRM the most important addresses are visiting address and postal address. If you naivly presume these to be the same the effects can be dramatic and sometime even catastrophic. I friend of mine, Peter Björkmarker, told me a story of a company integrated just like this, and as CRM was set as the customer data master, it overwrote all invoice addresses in the ERP system with visiting addresses. Next month, all invoices which were sent out were automatically, without anyone noticing sent out to the wrong address, hence nobody paid them. The company got into an accute cashflow problem and almost filed for bankcrupcy. So this is no joke.

2. Ready built integration are usually on a technical level, but you expect it to work on a business level. Integration technology is usually about moving data, but just having the data in the other system doesn't always DO anything. An example is if you have a boolean field on the customer in the ERP where the financial people can block the customer from further business if they havn't payed their invoices. So you integrate this field to CRM and can now see it on the account form. But without any additional logic in CRM it will still be possible to create opportunities, quotes and orders. Maybe not what you would like.

3. Data structures are different. My colleague Rickard Norström, whose blog you can find in the list to the right, was part of a CRM project which integrated to Dyn AX. One of their issues was the AX address data structure. An address record in AX can be used by both an account and a contact, And I think even several accounts. When this address is changed, of course this is seen in all affected places. As this is very different from the customeraddress built in logic in CRM they had to create their own new address entity to solve this. Other typical areas where there are large differences are in the logic of setting prices on opps/quotes/order. As you can expect, a system like AX with MPC and many other deep links into costs can of course use that as a base for pricing, something that is very hard for CRM. It also has more complex or just different ways of handling pricelists. I was working with an iScala integration and iScala for instance can have a current price in a pricelist and a comming price with a specified date on which the new price will be enforced. However, no event in the system will trigger at that time. Customer specific pricelists are also something that occur, not advisable but existing especially for larger customer accounts.

4. Centralized integration architecture. The Common Data Model sounds great but it only handles two of the components in the Business system infrastructure. If you for instance are a Telco the amount of business systems will be a lot more, billing systems, provisioning system, logistic systems, product configurators, etc. Banks are also complex worlds. Many of these have tried to consolidate their integrations to integration hub technologies like WebSphere or BizTalk and if done properly they will of course have their company defined canonical data model. It would be interesting to see the story of how the Common Data Model works together with this. It probably can by shuffeling data using Logic Apps to and from the CDM, but in essence you will have two hubs to orcestrate. Another option is of course to use the CDM as the central hub for all information, as long as that is extendable and doable. So, from this perspective, the main issue is probably, if we have 8 systems connected to our existing integration hub, is it plausible to use the CDM or do we manually integrate anyway directly to each application?

To conclude, I think the CDM will be a good tool but I will keep my expectation to a reasonable level and I recommend you do this too. Do not think it will make your highly customized CRM and AX automatically integrate all data and make it work from a business perspective, that would simply be too increadible. If they manage that, I will buy the entire team building CDM a beer (or similar).

Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Monday, September 12, 2016

xRMVirtual Presentation

By Charlotte S H Jensen - Flickr: Maskiner på Brede Værk, CC BY-SA 2.0,
https://commons.wikimedia.org/w/index.php?curid=20868496
Ever thought about the fact that there nowdays are so many ways that you can create logic in CRM?
Or did you start with callouts in CRM 3 and then learnt plugins in CRM 4 and have stuck with those, I mean, why change?

If you are interested in discussing this and listening on my views, join me on September the 27:th at 9:00 PST/18:00 CET when I will be presenting on xRMVirtual on this topic.

Hope to see you there!

Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Monday, June 13, 2016

Microsoft + LinkedIn == True

Todays biggest news in the Microsoft sphere is of course that Microsoft is to aquire LinkedIn for the
astronomical sum of $26.2 billion. This is hopefully great news for us in the Dynamics CRM world as LinkedIn have during the last couple of years been very protective of their data by not opening up, even with payed subscriptions, their API:s for integrations.

Imagine how cool CRM married with LinkedIn data looped through Azure ML would be when trying to find out how to get a good entry point on a opportunity. And that's just the beginning. Let's see what Microsoft does with this. They have a few dollors of synergy to win back.

http://news.microsoft.com/2016/06/13/microsoft-to-acquire-linkedin/#sm.000005b8xzynywdhe10mp9ndvkv8e


Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Sunday, May 29, 2016

Which browsers are actually supported?

I sometimes get people complaining to me that CRM doesn't work in Firefox. What i usually ask them when I hear this if they are running Mac, which of course is the reason why it isn't working. 

The simple fact is that Firefox isn't supported for Mac. The only supported browser for Mac OS X is Safari. And Safari isn't supported for PC.
Below is a simple matrix showing the support matrix for the browsers (for CRM 2016).


Windows 7
Windows 8/8.1
Windows 10
Mac OS X
IPad
Google Nexus 10 Tablet
IE 10






IE 11






Edge






Firefox






Chrome






Safari






Green = Supported, Red = Not supported, Grey = Not applicable

However, do note that there is a difference between "not working" and "not supported". The latter just means that you can't open a support case with Microsoft and complain that CRM looks weird in some of the non supported combinations described above.

So why is this? Are Microsoft just lazy? No, Just like everyone else, they have a limited amount of time, money and resources. So, they can't test all possible combinations unless the price of Dynamics CRM were to go through the roof, and I think we all agree that we prefer it not to.

Do refer to the official documentation from Microsoft on what is supported for more detailed information.


Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se

Tuesday, February 09, 2016

Tips when migrating using Excel

The Excel import functionality in Dynamics CRM is quite good. Version 7.1 (2015 Spring Wave) introduced some new features, like finally being able to work with xlsx-files which helps out a lot.

Generally we recommend using ETL-tools like our favorite KingswaySoft in SSIS, and sometimes the only way to migrate really complex data is to write your own code, but it usually isn't necessary (if you disagree, please leave a comment below!).

However, both ETL and especially code, takes some training to get going with and some of our customers and others I have spoke to have expressed a will to handle migration themselves which makes the Excel import the best candidate to work with as most people have experience with Excel.

First of all, my recommendation is to complete the customizations in the target system. That way, when you download the Import templates, you will get all the fields that are shown on the "standard" (fallback) form.


Excel Account Import Template (Swedish) from CRM 2016
As of CRM 2015 Spring wave (7.1) the Excel import template will be formatted as a excel table, which makes it easier to work with, I think.

During the work with migration of data, you can correct data in one of three places.
1. In the source system.
2. In the Excel files while transfering it.
3. In the target system/after migration

Typically the time when the live migration needs to be done, is as short as possible. As everyone needs to stop working in the old system, migration needs to be done, and then everyone can work in the new system. Hence it is typically done during evenings, nights or weekends, depending on which type of business you are in.

Due to this, you need to make sure that when you are doing the real live migration, you need to make sure that it will be as controlled and as smooth as possible. This requires you to first set up the migration and then test it properly. Dry runs are therefore a must unless you are CRM Rambo.

If you plan steps in the migration in the above described stage (2) - during the transfer, you will need to re-do these every time you do a dry run and when you do the live migration. If possible to change the data in the source system instead, for instance remove duplicates, you reduce risk and speed up the migration process.

Generally it is a really good idea to try to clean up you data before migrating it. Many are the CRM system owners who have understood quite a lot about how their users actually use the system, when the are to migrate the data and really start digging their head into it.

Some of the common problems when migrating with Excel are:
  • Complicated to handle GUIDs - ETL tools often have ways to migrate the GUID from a source system, very useful if moving from CRM Onprem to CRM Online.
  • Cannot handle updates/upserts easily. Can however upload several files at once instead. For instance, contacts have Parent accounts, and Accounts have Primary Contacts. Just make a zip with both xlsx-files and upload. CRM will figure out that they are interdependant.
  • Duplicates. Duplicates. Duplicates. So you switched off the duplicate detection for accounts and thought you'd be fine? Well, not so much, lookup fields to account, for instance, by default, will use the primary field, which is "name" and if you have several accounts with the same name, the import function will not know which to select and you will get an error. Typical fields where this is a problem are:
    • Contact - Parent Customer / Company (pointing to account)
    • Opportunity - Potential Customer / Account (pointing to account)
    • Opportunity - Contact
    • Account - Primary Contact
    • Account - Originating Lead
    • Contact - Originating Lead
    • Opportunity - Originating Lead
  • Only active? Are you only going to import active records? Will that work? Do active records have relationships to inactive records? For instance, you might have an active account that has an inactive primary contact. Or active accounts with inactive parent accounts. If only moving the active accounts and active contacts, the import will fail as the target system will not find the primary contact.
  • Activities. The activity parties, in other words the "to", "cc", "bcc", "required", "optional" etc. fields on activities are handled by a rather complex mapping entity called activity party. There is some support for migrating this with Excel but it is not very easy, so if you do have a lot of activities to migrate, I would strongly recommend using an ETL tool with support for activities.
  • If you add a column to the CRM 2016 Excel Template, despite having the Display name in CRM, it will not be automatically mapped like the other columns as there is underlying data to handle it. It is no big issue as the import mechanism usually interprets this correctly anyway. Do note that the Display name mapping is case sensitive and CRM does allow for duplicates in fields having the same Display name, but that doesn't make importing easier.
Some tricks that I use
  • Generate an import template for the entity at hand, let's say account from the target system, then remove all the columns you don't want to import. Remove the entire column. Save this. Verify the template by filling in one or two rows by hand and importing. Make sure that the lookups match data in the system.
  • Export data from the source system in the same order to match the import template, if possible, into Excel. Then, verify that all columns are identical (ie. picklist are the same etc.) and then copy-as-values from the source excel sheet to the target excel sheet without the header columns.
  • Verify that the data in the target excel sheet is correct, that for instance there are cities in the city column, not street names.
  • Then import the data into CRM. The first couple of times you will get errors. If you don't you are very very lucky. Migrating data is complicated, as data is seldom clean and well ordered. So, when it is done, go to the imports section in CRM and go through the errors and try to understand what it is trying to say. Typically a specific lookup cannot be found or it has multiple values. My suggestion is to fix it in the source data (1 in the list above) and not try to do it in the Excel sheet (2). Also plan for making several test runs of migration. Write down the steps you need to do when doing it live, so you have your plan set.
  • When importing data with lookups to data where there are lot's of duplicates in the primary field, do note that you can change the mapping of the lookup field so that it mapps not on the primary field but on some other field instead. For instance, if there are several accounts with the same name but all accounts have different account numbers, you can use account number to indicate parent customer on a contact instead and then change the mapping when importing.
  • Make sure that if you do change data in Excel and use formulas, copy and paste-as-values back to the cells/columns as the import does not support formulas. (not sure if the new CRM 2015 Spring Wave/2016 does, havn't tested, but I wouldn't provoke it.)
  • All picklist values need to exist. Using the import templates is a good tool here as they include the possible values. But you can paste incorrect data into the cells anyway and then import it where you will get errors on the rows with the incorrect data.
  • Decide what is a good enough result before. Is 99% good enough? That would mean that if you have 100 000 accounts, 1000 accounts are not imported... so maybe that is not good enough. Remember Pareto's law, that the last 20% take 80% of the work. So fixing the last 1% can be a real pain, why it is sometimes easier just do fix it manually after import.
  • Zip files with inter-dependencies. Like account-contact.
  • You can increase the max file upload size. but the max size for a file after uncompression is still 20 MB, if I am not mistaken. This means that you need to think about how you upload your data if you have large amounts of data. ETL tools might be a better option here as well.
  • After getting errors and getting an import of let's say 50%, instead of trying fix the last 50% and importing those, I recommend deleting all and going back from the start. As you need to plan for doing many trial runs before doing a live migration, this is the only way to make sure that you get the source data better and better.
If you have done your own imports and migrations with Excel, I am sure you have some tips of your own, please share them below! I do moderate all comments to avoid spam.

Gustaf Westerlund
MVP, Founder and CTO at CRM-konsulterna AB
www.crmkonsulterna.se