Custom fields: handle with care!

The Microsoft team did release platform update 13 for Microsoft Dynamics 365 for Finance and Operations, Enterprise edition. One of the new features is Custom fields. This feature lets a power user or system administrator configure new fields on existing tables without using the development environment and deploy it on the other environments. It is a neat feature which can be of interest, but you also have to be aware of all pitfalls and downsides. In this post, I will tell you more about the custom fields.

What are the custom fields?

When you are in the need for some additional details on a customer, vendor or worker, usually you would ask a developer for creating fields in the tables and add them on the form using extensions. Then a deployable package is used to move the changes to your production environment. With the new feature in platform update 13, you can now configure the fields. The reason for adding this feature by Microsoft is to provide an easy and cost-effective solution to add simple details to existing tables and use them within Dynamics 365 for Finance and Operations. Using the configuration option, you could save on development, testing and code life cycle.

Important notice from Microsoft:

This feature is part of a targeted release and is available only to users who have opted in to the Continuous Auto-update Advantage Program (CAAP). This feature will be included in another upcoming general availability release. For more information about standard and targeted releases, see Standard and targeted platform releases.

The process is very easy. Of course, not all users can do it themselves. You have to be a system administrator or have the role Runtime customization power user assigned. It is described on the next documentation page: Custom fields

The next screenshots show some of the steps to create a new field on the customer table which represents a legacy/old customer number. As mentioned in the documentation, start with personalizing the form:

There are options to define your custom field:

Once completed and reloaded the form, you can maintain the new field:

Difference with the development approach

When configuring fields, you cannot control things like indexes and coding to validate or automate entry. These options are available when a developer will create a field in the meta data. When a field is created in the meta data and deployed on all environments, it would also be possible to include this field in new or customized reports. So, it is not possible to configure a field and have the field visible in the development environment for reporting. It is possible to add a configured field to data entities on runtime.

Within an implementation, you have to careful consider if you want to configure a field or needs to have more control options and let a developer create an extension. Fields in the application metadata are more sustainable. In advance, you should know the purpose of this field.

Some important limitations of configured custom fields are:

• Not able to add business logic as it requires coding. (Side note: my company has a Data Quality Studio ISV solution which also handles the custom fields)
• Not able to add indexes on runtime. Searching on the field in larger tables can cause slowness.
• Not able to add the field on existing reports.
• Showing the field on forms is done with personalization. Users should add the new field themselves or an administrator can copy a template to all or selected users.
• You cannot control the size of the field. E.g. text fields created with 100 characters will be displayed in a smaller single line field. It is not possible to enlarge the field or make it a multi line.
• Update January 2023: The size of text fields is limited to 100 characters. In case you need a larger size, you must consider creating the field via development.

Expose custom fields on data entities

It is possible to include the new configured fields on existing entities using the Custom fields maintenance form. When enabled, you can use the field in the Data Management features and Open in Excel. Using data management, you could use reporting tools like Power BI to expose your custom field.

When you do configure a custom field, Dynamics 365 will create runtime table extensions and also a physical field on the table in the database.

There are some limitations defined by Microsoft. These constraints were added to prevent issues like performance degradation. The next rules are valid for tables (taken from the documentation):

• The table must be tagged as one of these groups: Group, WorksheetHeader, Main, Miscellaneous, Parameter, Reference, TransactionHeader
• The table cannot not extend another table.
• The table cannot be marked as a system table.
• The table cannot be a temporary table.

When creating a picklist field, a list with possible values are maintained in a table which will be used as lookup when entering the data.

I have tested the custom fields on a table of our own add-on which was also working correctly. Technically, Microsoft did a very good job here.

Also, there is a maximum on the number of fields to be added on a single table using the configurable custom fields option. The maximum number is 20. When creating fields, be careful with lengthy text fields. Too many longer text fields will cause growth of the record size which could lead to performance penalties. Though, it is a bit strange that 20 fields are allowed, where the best practice check in Visual Studio will give a warning if you create more than 10 in one extension.

Handle with care

As stated, there are limitations and you should not provide access to every user to be able to create their own fields. I do think configuring the custom fields should be considered very carefully. Showing the custom fields are presented to the user as form personalization. If a system administrator will push a new “form layout” to all users, earlier created personalizations will be overwritten. Also, a user could easily remove the field himself or reset the personalization without knowing he is losing the new field. So possibly development would be more expensive, but there is a better governance that it will not have negative side effects. If you run into problems, troubleshooting is also costing money…

As mentioned above, searching on non indexed fields and too many large text fields can cause performance issues.

A fellow MVP, Ievgen Miroshnikov, found another danger.  A developer could add a table extension ending with _SysCustomFields and add the field with exact the same name (in my example OldNumber_Custom). Then deploy it to an environment where the custom field was created. Assuming the custom field record is not required anymore, delete the field from the configuration. It will then forget that it was included in a deployable package and the field will be physically removed from the database. So, never, ever use fields as developer end with ‘_custom’ and don’t use table extension names ending with ‘_SysCustomFields’. Usually we would not use these keywords, but thinking to “move” the configuration to development based extensions could lead to assumptions and one attempt. So, you are alerted now! Read below for a work around…

Move custom field to development environment

Like stated above, it is not possible to move the custom field one-on-one to Visual Studio. The best would be developing a complete new field as extension (different naming convention). Also extend standard data entity with the new field. Once these changes are deployed , you have an environment with two fields for the same. Export the data using data management. Then you can import it into the new field. Once you have checked this was successfully completed, you can delete the custom field.

There is more…

It is not documented by Microsoft, but you can enable database logging on the custom fields. Just like any ordinary field, you can select the custom field in the list for updates logging.

If you want to learn more about this feature, I will host a MVP session for the AXUG on this topic on Monday, February 12, 2018 at 9 AM EST (3PM CET).

Update: The recording and slides of this recording can be found on the D365UG Webinar recordings page. This requires a membership login from D365UG.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!