In Microsoft Dynamics 365 for Finance and Operations, you are able to view the base Microsoft source code. The base objects and source code are stored in several Models, which are groupings of objects and code. However, you are not able to modify or add to the code or objects in these models. Therefore, as a developer, you need to create a Model in D365 to store any objects or code you wish to create. Use Extension objects to customize existing objects. Use Chain of Command and Event Handler classes to customize existing code. Or create entirely new objects and code. In this article, I will explain how to create a new Model in D365.
Overview
Before going through the steps of how to create a model in D365, I wanted to explain what Models are.
A Model is a group of elements, such as forms, classes, tables, and any other object you can create in a Finance and Operations project in Visual Studio. In addition, models can also contain dlls, references to other models, and metadata. This model will eventually be part of what is called a Package, which can be used to deploy the code in that model to another environment.
I will briefly explain the typical life cycle of how the code in a Model gets promoted to other environments. Once a developer has finished adding all the objects needed for some new functionality to work, the developer will check in the objects, code, and Model into source control. A build server will be run to ensure that all of the code in that Model compiles successfully. It will also combine the code with any other custom Model code, and generate a Package. The Package file will then be downloaded. Then uploaded back to the Asset Library in LCS. From there, the package can be applied to another D365 environment. This is the way code is promoted from a development environment to a Test environment. As well as promoting code into a D365 Production environment.
One Or Multiple Models?
Models are designed to be a grouping of objects that relate to each other. For example, when you create new functionality in D365, you may create a new menu item, form, table, and class. All of these objects that are used to support that new functionality should be put in the same model.
Many features can be put into a single Model. However, a developer might also create several Models to help separate functionality that might not be useful to the same end users.
For example, you might decide to have one Model that stores functionality related to Postage and Handling. And an entirely different Model that stores functionality relating to Ingredient mixing. This gives more flexibility to potentially deploy a smaller footprint of code, if the other functionality is not needed.
An Important Warning!
That said, you need to be very careful with multiple models. For many companies it is much easier to only have ONE model that contains all of your code. This will help you prevent issues like circular references, where multiple models are dependent on each other. Multiple models are more often used when you have one Model for your code, but you are also using another 3rd Party Model to add functionality to the system. But this should be safe, as the 3rd Party Model won’t have any dependencies on your model.
References and Dependencies
There are some rules to keep in mind. Every object in the Model needs to either reference other objects inside that model, or the Model itself needs to reference other models that contain the used objects.
Let’s look at a couple examples to understand these rules.
First, let’s pretend you create a form, and you add a Datasource to your form. The Datasource references a table that you created that is also in this same Model. This is fine. The system has all the information it needs in this model to compile the code.
Secondly, let’s pretend you create a form, and you add another Datasource to your form. In this case, the Datasource references a base Microsoft table, such as SalesTable. SalesTable is not defined within your model. It is defined in the Microsoft Model named ‘Application Suite’. In order for the system to be able to compile the form, the Model that we are creating the form in, needs to reference the ‘Application Suite’ Model.
As I go through the steps on how to create a Model in D365, I will explain how to add references to other models.
Create A Model
Microsoft has some good documentation on how to create a model in D365. However, I will also explain the steps as well.
Model Parameters
First, run Visual Studio as administrator.
Next, go to the Dynamics 365 menu. (If you don’t see the Dynamics 365 menu, go to Extensions>Dynamics 365)
Select Model Management>Create model.
Note, if you are not running Visual Studio as an Administrator, you will see an error message like the following. Close Visual Studio. Then, right click on the Visual Studio icon, and select ‘Run as Administrator’.
You will know that you are running as an Administrator if you will see the text “(Administrator)” show in the top caption. Or, if you are running Visual Studio 2019, you will see a block in the top right of Visual Studio that says “Admin”.
A ‘Create model’ wizard will appear.
First, enter the name of your model into the Model name field.
Secondly, enter the name of your company in the Model publisher field.
Thirdly, enter a value from the drop down in the Layer field. It would take a longer explanation to explain when you should use value. I recommend you set this to either “isv” or “cus” for now. This field is no longer that important, in my opinion.
Fourthly, enter a description of the functionality in your model for the Model description field.
Next, enter a value for the Model display name.
Finally, click the ‘Next‘ button.
Select Package
On the next page of the wizard, select ‘Create new package‘. The other option, ‘Select existing package’ should really no longer be used. And is there for support of some old ways of using models.
Click the Next button.
Select Referenced Packages
On the next page of the wizard, you need to specify which other models / packages, you want this model to reference. As mentioned previously, if you create objects or code in this model that references other existing objects in other models, you need to reference the model that the object is defined in.
You can tell what model an object exists in, my looking at the value between the square brackets when viewing the object in the Application Explorer. For example, I can see that the SalesTable table exists in the Application Suite model.
You can update the referenced packages later. So if you don’t know at this time, that is ok. It is recommended that you start by selecting the ‘Application Platform‘, and ‘Application Foundation‘. But you very likely will need to come back and reference more later.
If you are not sure, and just looking to just add some of the most common models I recommend referencing this list.
- ApplicationCommon
- ApplicationFoundation
- ApplicationPlatform
- ApplicationSuite
- Calendar
- ContactPerson
- Currency
- Dimensions
- Director
- FiscalBooks
- GeneralLedger
- Ledger
- PersonnelCore
- PersonnelManagement
- Retail
- RevenueRecognition
- SourceDocumentation
- SourceDocumentationTypes
- Subledger
- Tax
- TaxEngine
- UnitOfMeasure
The fewer the better for debugging and full compiles. But it can be annoying to have to constantly go back and update the model. Therefore, you might just start with these.
Summary
The last page of the wizard is the Summary screen. This screen will list the values you selected throughout the wizard.
However, there are two additional options you can select on this screen.
- First, you can optionally check ‘Create new project’ if you would like the system to create a new project immediately after creating the model. If you are planning on creating objects or code in this model right away, this can save you a step.
- Secondly, you can optionally check ‘Make this my default model for new projects’. Very often, a developer will create a new model, and then spend the next while adding objects and code to that model. They likely will create those objects over several projects. Splitting them up by their functionality. It can again save a step to make it so all new projects are automatically set to use the new model you created. However, you can change this by right clicking on the Project and selecting Properties. Then changing the ‘Model‘ property to the model you wish to create your code in.
Behind The Scenes
Behind the scenes, Visual Studio has created a new folder, and some files in the AOSService folder, which contains the files to run Microsoft Dynamics 365 for Finance and Operations. In a cloud hosted developer machine, you can look on the K drive, and find your new model folder under K:\AosService\PackagesLocalDirectory\<Your model Name>
Look one folder deeper, by opening the folder that matches the model name. In my case ‘MyModelName’. This folder contains a folder for every type of object that can be created in Dynamics 365. And when new objects or code is created, new .xml files are stored in this folder that contain this code.
These files must be checked into source control. And they are used by a build server to properly compile the code that is stored inside this folder. These files are turned into a package, along with files from any other models. And that all-in-one package can be deployed to other environments using Life Cycle Services (lcs.dynamics.com).
Create A Project And Solution
After learning how to create a model in D365, you likely will want to start by creating a project and solution. To do this, you can check the ‘Create new project’, checkbox in the create model wizard. Or, you can go to File>New>Project…
A dialog form will open. Enter in a project name, and solution name. Then click Create.
Your new solution and Project will be displayed in the Solution Explorer window in Visual Studio.
Notice, that if you checked the ‘Make this my default model for new projects’, your new model will automatically be set as the model on the project. The value between the square brackets is the model being used for this project.
If that is not the case, right click on the Project, then select Properties.
Set the ‘Model’ property to be the model you wish to use.
Note: If you plan to create Extended Data Types, Tables, Views, or Data Entities, then you should set the ‘Synchronize Database on Build’ property to ‘True’. This makes it so when you Build in Visual Studio, the underlying SQL Database gets updated.
Conclusion
Before a developer can add any new objects or code, they need to know how to create a model in D365 to store that information. In In this article I showed you the steps for creating a new Model. And I explained what should go into a Model. I also explained that Models can reference other Models. Finally, I explained how to create a new Visual Studio project that will create objects inside your new Model.