This post is part of a series on creating a module within a Microsoft Dynamics 365 for Finance and Operations application. Links to the other parts are available in the first post: Creating a Module in Microsoft Dynamics 365: Laying the Foundation.
A module in Microsoft Dynamics 365 for Finance and Operations is a grouping of similar business processes and functions that allow users to conduct business. Examples include General Ledger, Accounts Receivable, Accounts Payable, and many others. Developers create new modules to group new functionality in an equivalent manner or to produce third-party solutions.
In this series, I am creating a fictitious module called Generic Application Solution (GAS). The assumption will be that the reader has an intermediate knowledge of development in Dynamics 365 as well as best practices. This post will build upon the foundation laid in the first post by adding the label file and licensing objects.
Create the Label File
The first object for a module should be the label file as all of the other objects will depend on it. When creating the label file, keep in mind that it is a best practice for the label file to have the same name as the module.
On the first page, developers should keep the default for Label File Id as it should match the name of the file.
The second page is where developers select the languages that the module will support.
Page three is the summary.
Create License Code
A license code is an object that allows Independent Software Vendors to control the licensing of their third-party solutions. Since licensing of third-party solutions is outside the scope of this exercise due to complexity, GAS will not include one. However, it is something that is necessary for third-party solutions.
For more information, see this page: ISV Licensing
Create Configuration Key
Configuration keys play a role in licensing as well as security. Developers can assign a license code to a configuration key which will cause the configuration key to not be available unless there is a proper license.
A module should have at least one configuration key. If it includes additional features that an administrator can enable, developers can create additional configuration keys. The recommendation is to have a root configuration key that will act as the parent of any additional keys.
The key properties of configuration keys are Label, License Code, and Parent Key.
- Label: The name of the configuration key as seen in the user interface.
- License Code: Select the license code, if applicable.
- Parent Key: Keys that control additional features within the module should have this property set to the module’s parent key.
In the next part, I will discuss the creation of the parameters table.
Dauvis' Dev Musings 