I was working with the App Designer this week in Dynamics365 and ran into an issue where I had created a second area in my sitemap but when I went to look in the app itself, I wasn’t able to see it.
If you’re not familiar with where Areas appear in the new Apps view, your second area will show in the bottom left corner (it’s a little hidden but it’s there).
In my scenario, I had an Area called Tools, but when I went to it I only had one item showing, even though in the designer, I had two and they had all passed validation checks.
If you’re still doing configuration in web.config files for your Azure services, it’s time to try something new and leverage something that has been there for quite some time – Application Settings.
In your Azure Portal, you will notice a section called Application Settings. Within this section is everything you need to configure your application. If you have some custom configuration data in your web.config file, a simple way to rely less on the web.config (and make your end administrator’s job a little more easier) is to expose these configuration values via Application Settings.
The process to create a new Application Setting is straight-forward, create the setting, add the value. (In this case I created a key called Tool).
If you’re still creating databases locally for all your development and testing needs, it’s time to give yourself the kick you need to start doing things a little differently and learn something new in the process.
Going to Azure isn’t as complicated as you think (if you start small). If you’re worried about costs, there are tons of credits floating around to make the learning cycle quick and painless.
First, setup a Resource Group, for a listing of all Azure related terminology, check here. When you’re done doing this, navigate down to SQL Databases and create a database server (a URL) and whatever associated database you want to go along with it.
In my portal view, this looks a little like this where I now have a server and a database.
Using Alternate keys is an easy way to stop doing pre and post checks for whether you can insert data into Dynamics.
Before you had to do a check behind the scenes for whether an “Id” existed and if not go and insert it.
Now using the “Upsert” pattern in Dynamics, you can accomplish this task in one method call using an alternate key.
At’s it’s most simplest implementation, I created a custom entity and a field (wholenumber) that I then declared as my alternate key.
Then I wrote the following code to insert the following record into my system. You can
Audits are a great way to see what has happened on records, what they did and more importantly who did it.
But if you have automated processes running that are pumping data into Dynamics because a field or two has changed, you might end up with an Audit History looking something like this.
In this case, an update was triggered, but it wasn’t until the fourth update that there was an actual difference in the data being changed. Even then, when we sent the whole packet of data, we sent it all.
With only four feels you can already see this gets a little painful to follow.