Taking full advantage of Microsoft’s OneVersion continuous updates is predicated on the expectation that businesses, and their solutions, have primarily aligned with the adopt not adapt approach.
The F&O solution has evolved to support organisations and partners on this journey with features such as configurable business documents; addressing the almost constant need for output documents to be tailored to specific customer needs, which moves the document changes out of X++ code development and into the user interface.
Another great feature is the ability to customise the F&O forms to add new ‘custom’ fields to the user interface.
In this post I’ll be delving into the custom fields a bit more, showing how to interact with them and also additional activities required to update the supporting data entities.
Creating a custom field
In the following walkthrough, I’ll be working with a scenario of an organisation requiring the ability to internally classify and categorise their customers, which does not naturally fit within any of the existing customer record fields.
Note – This scenario is to provide context to the changes and not a specific recommendation. I appreciate the potential of ABC codes, customer groups etc, that may also address this requirement.
Navigate to Sales ledger > Customers > All customers and select ‘Personalise this page’:
I have gone into more depth around the personalisation options in my post, D365 F&O – Let’s make it personal!, but for the purposes of this example, select ‘Add a field’ from the personalise ribbon and choose the form that you wish to add the field to:
We want to select ‘Create new field’, rather than add an existing field:
This will open up a new dialog box where you can add the specifics for your new custom field:
A brief overview of the purposes of each selection here is as follows:
Table Name – this is the specific table that you want to customise and add the new field to. In our case is will be the ‘Customers’ table, but all tables with a direct relation to the customer record will also be listed here for selection.
Name Prefix – This is the filed name that will be prefixed to the new table field, which is previewed in the Field name box. Note: special characters, such as spaces, are not allowed.
Type – This is where you select the specific filed type. Options include; Text1, Number, Decimal, DateTime, Date, Picklist2 and Checkbox.
Label – This is the field label displayed to users on screen and should align with the Name prefix as much as possible.
For the purposes of this walkthrough the following settings were used:
Once you have completed the form, select ‘Save’ and acknowledge the dialog box warning you that you will be updating the selected table.
The new field will then be displayed in the list and will be selected as default so simply, select ‘Update’ to add the new field to your form.
The new field will then be displayed but the forms requires a refresh to allow users to interact with changes that have been made.
Note – to save you having to repeat some of the previous steps I would recommending creating a custom view at this point, before you refresh your session.
You’re new field should then be displayed as normal and available for selection/population:
Data Entity Update
This step may not be required, it will depend on the purpose of the custom field. However, if there is a need to reference this externally e.g. as part of a data migration routine, export to Azure synapse for reporting etc, then the supporting data entity will need to be updated to capture the changes.
Navigate to the custom fields setup page at System administration > Setup > Custom fields:
You will initially be presented with an empty screen, but the ‘Table’ drop down will list all the tables where custom fields have been applied. Select the relevant table and custom field:
This is also the place where any changes to the custom field would be applied, including adding any required translations. However, on this case we want to review the entities related to the chosen table and ‘enable’ the field on that entity. Once the updates are made you must select ‘Apply changes’ for the them to take effect:
Once the changes to the entities have been made the data entities must be refreshed so that the new field is available.
Navigate to System administration > Workspaces > Data management and select ‘Framework parameters’:
Select the ‘Entity settings’ tab and trigger the ‘Refresh entity list’ batch job:
You will receive a notification in the data management workspace while the entity list is being refreshed. Once the batch job has finished navigate back to the data management workspace and open up the list of data entities:
Navigate to the entity on which you applied the changes and select target fields:
Finally, search for your custom field to validate that it is now part of the data entity and can be used during data import and export processes:
As simple as that, a new field can be added to the application and updates applied to any of the related data entities – with no need for technical or developer input, and absolutely no need for X++ coding.
Leveraging the standard functionality available to extend your F&O solution, rather than custom code, helps to maintain alignment with the standard toolset and reduces the risk of rework and/or overhead during your OneVersion service updates.