Today I was working with a Dynamics 365 instance where I did not have full SA access to the SQL Server instance. My deployment administrator account was able to connect to Deployment Manager ok, disable organizations ok and delete Organizations, however, when I tried to re-import an organization I had already deleted, I got the below error.
Visual Studio was officially released today, and with it’s release comes the dilemma for Dynamics 365 developers. Do you keep going with VS 2015 (or maybe VS2013, VS 2012 or 2010!), or do you bite the bullet and install Visual Studio 2017?
In the past, I would normally hold off on a new Visual Studio installation until there is a service pack available, but after reading that Visual Studio 2017 is focused on performance improvements and speed, I decided to install it on an Azure Developer VM to see if I could get the Dynamics 365 Developer toolkit working on it.
I attended the excellent CRM Saturday in Dublin on Saturday past, with some very informative talks on a wide variety of CRM related topics, both technical and non-technical.
One of the most interesting talks was by Mohamed Mostafa, which involved a discussion around things to consider when considering whether to recommend an on-premise CRM or a cloud based deployment.
As well as discussing technical considerations, supportability, data jurisdiction issues and data protection issues such as GDPR, the diverging feature set between online and on-premise came up. Since Microsoft’s move to the cloud, more and more features are going online only, leaving on-premise customers slightly envious of some of the cloud only features.
I recently had an Organisation updated from Dynamics CRM 2016 Online Update 1 to Dynamics 365. After the upgrade, users experienced the following symptoms :
- Unable to add new notes to custom entities and core entities via the notes control on the form.
- Existing Notes created prior to the upgrade do show up ok however and can be edited.
- This occurs on multiple entities, but not all. I didn’t see a pattern, but certainly on some contact records I could add new notes ok.
I raised this with Microsoft and it didn’t appear to be a known issue, so I decided to do some investigation myself.
Update – This appears to be fixed in Service Update 5 for 8.2.0
Today I upgraded a Dynamics CRM 2016 Online Update 1 instance to Dynamics 365. Everything seemed to be going well. However when using Global Search I was getting the error below.
Query Builder Error – The specified field does not exist in Dynamics 365. If you contact support, please provide the technical details.
Are you scoping a new applications project and think Dynamics 365 could be all or part of the solution?
Starting a Dynamics CRM or Dynamics 365 Project can be a daunting task even for the most experienced decision maker. All your research might indicate that Dynamics 365 is a good fit for your business, but if you don’t know enough about the benefits, pitfalls and how it fits with your business, how can you be sure it’s the route you really want to go down?
You might be considering some of the following points?
- Maybe you’ll need to use a few in-house business analysts to do some configuration.
- Some bits may look complex so maybe some you need some .NET developers involved too?
- Should you start with Waterfall methodology or Agile or SureStep or a Human Centred Design approach?
- What training do you need?
- Fixed Price or Time and Materials?
- What licences should you buy?
- On-Premise or Cloud?
- Maybe you should go out to tender, but what if you don’t frame the requirements correctly? Should we get some training first?
- Is offshoring Dynamics 365 consultancy a good idea – can it be achieved remotely?
Microsoft has surely been looking at Salesforce for the past few years, feeling somewhat envious of their ‘apps’ market. If you take Salesforce at their word, they have over 1.4 million registered developers, so the apps market for Salesforce is clearly not a flash in the plan.
With the recent launch of Dynamics 365, there appears to be a concerted effort at Redmond to build an ecosystem around Dynamics 365, but how has this been implemented and what do application developers need to know?
“Dependency hell is a colloquial term for the frustration of some software users who have installed software packages which have dependencies on specific versions of other software packages.”
Source : Wikipedia
It’s often tempting to spin up a new trial online instance to do some custom development. The intention is normally to use it temporarily, then export your masterpiece as an unmanaged solution so you can import it into a target vanilla non-trial, more permanent instance.
With Dynamics 365, if you check all the boxes when setting up, CRM will be provisioned with a lot of supplementary solutions as well on top of what you know as a vanilla CRM instance – think Project Service, Field Service and maybe a few extra dependent solutions thrown in there for luck too.