A first look on unmapped fields in event registration forms

With the new feature, which is currently in preview, unmapped fields in Dynamics 365 Customer Insights – Journeys can now also be integrated into registration forms without having to adapt the data model. In this article, I’ll show you how the feature works, what happens technically in the background and why it’s so exciting for marketers.

What are unmapped fields?

Unmapped fields are user-defined form fields that are not directly linked to entities such as “Contact” or “Event Registration”. Instead, they are treated as independent fields within the event context. So if a specific query is required for one (or more) events, you simply create a new field directly in the editor for the registration form, the rest happens completely in the background and fully automatically. The value can later be used as normal for personalization, segmentation or journey orchestration.

Unmapped fields in registration forms are:

  • not mapped, independent of the core data model
  • Reusable once they have been created
  • nevertheless technically traceable, as they are stored in the background as structured data objects and assigned to the registry
  • usable for personalization and segmentation

Step-by-step: how it works in practice

Form editor: Activation and first hurdle

Before the new feature can be used, it must be activated in the feature switches. The option for unmapped fields is then available in the form editor – but only after the form has been saved once.

Create field in the editor

New fields can now be added in the form editor – all common field types are available (text, textarea, option set, multiselect, radio buttons, number fields, checkboxes and date fields).

I used the following examples in my test:

  • “On which days do you require a meal?” – Multi-option set
  • “Your food preferences” – Option set
  • „Your preferred name for badge“ – Textfield

Save field for reuse

Created unmapped fields can be saved and reused in other forms. To do this, simply click on “Save field” on the field object in the editor, assign a name and the field is saved in the background. After saving, the field is available for selection and can be inserted directly into the registration form.

Time for a test: transferring values in the form

After I have enriched the registration form with my three fields, it is time for a first test. The fields are neither saved on the contact nor directly on the registration record. Nevertheless, I am automatically able to see the submitted values thanks to a new automation of Dynamics 365 Customer Insights – Journeys. More on this in a moment. First, let’s take a look at the form submission with the individual field submissions:

A look under the hood: what happens technically

Automatically generated system view

A new system view is automatically created for each registration with unmapped fields. This is used in the subgrid of the event and also displays the user-defined fields. A great extension that allows marketers to see the new fields directly.

A note on this: It takes a few minutes for the new system view to be created and linked to the event. So don’t lose patience and refresh the browser after a short time.

There is currently still one “flaw”: dropdown entries are not saved with the label, but with the value of the field. This is why “Food Preferences” shows a “1” as the value in the view. I think that the development team at Microsoft will improve this when the time comes. Until then, we’ll have to make do with the values. Theoretically, the values can also be defined when creating the unmapped dropdown field, but I only realized this later.

Unterstanding the FetchXML of the view

Up to this point, the functionality is very clear and really easy to use. Nevertheless, I wanted to know what actually happens in the background and how I can use these fields. To do this, I took a closer look at the system view. It is noticeable that the fields are pulled into the view via a linked entity from the “Event registration custom field” table. This means one thing above all: unlike in the old outbound marketing, where the custom field values were created as records, a new Dataverse column is actually created in this table for each new field that is created! This means that the transferred values can be used in all typical places in customer insights journeys: for personalization, for segmentation or for journey orchestration. A real improvement!

New table for unmapped fields

The values of the unmapped fields are saved in the Event registration custom field table (msevtmgt_eventregistrationcustomfield). A separate column with the prefix “cuf_” is created for each field. All “cuf” fields are pure text fields, i.e. the transmitted values are always saved as a string. Unfortunately, as already mentioned, the value is currently used for choice fields instead of the readable label.

Update June 2025: With the last update on Dynamics 365 Customer Insights it is now possible to grab the choice label rather than the value. So from now on, you won’t have to deal with the value as described above.

For each form submission via a form that contains custom unmapped fields, a new data record of the “Event registration custom field” table is now created in addition to the event registration. This data record is linked to the registration via lookup.

Usage in emails

The transmitted values can be used in emails, simply use the context of the trigger in the personalization (e.g. “New event registration created”) and then select the “Event registration custom fields” table, which is located below the reference to the event registration. All custom unmapped fields can now be selected here.

A condition must be created in order to also use the transferred values from drop-down fields. We can then define a separate text for each case. You can find out more about how conditions are used in emails here in the documentation: How to use inline conditions – Dynamics 365 Customer Insights | Microsoft Learn

Advantages for marketeers

Flexibility without changing the data modelAd-hoc questions such as meal requests or individual badge names can be created directly in the form without any IT effort.
ReusabilityOnce unmapped fields have been created, they are available in other forms – consistently and efficiently.
Segmentation and personalizationThe data collected can be used specifically for segmentation or personalized communication – directly as part of the event journey.
Clear separation from the core data modelThe information remains clear because it is stored and processed separately – without any risk to the data structure.

Current disadvantage: Value instead of label for option sets

For normal option sets (dropdowns, radio buttons), only the technical value is saved – e.g. “1” instead of “Vegetarian”. This makes further use more difficult, for example in emails. With multi-option sets, on the other hand, the label is saved correctly. However, when defining an unmapped choice field, the technical value can theoretically also be adapted so that it becomes readable. However, this results in double work, because I still have to define the label additionally.

Update June 2025: With the last update on Dynamics 365 Customer Insights it is now possible to grab the choice label rather than the value. So from now on, you won’t have to deal with the value as described above.

Conclusion

Unmapped fields are now available not only for normal marketing forms, but also for registration forms. They are a welcome addition to event management in Dynamics 365 Customer Insights – Journeys. Due to the structure with the custom table and real fields, these fields can be used for further automation and personalization, which is very positive. Above all, custom unmapped fields are easy to implement, do not require a developer and do not change the data model of the contact.

I am looking forward to this feature, whose general availability is planned for August 2025, as you can see here: Collect extra event attendee information without updating your data model​ | Microsoft Learn

Try out this feature, but as always with preview features, it is not recommended to use it in a production environment, as there may still be unforeseen behavior and there is no full support yet.


Stay informed

Never miss a new post and simply subscribe to the newsletter.

2 Comments

  1. Hi Johannes, thank you so much for this useful blog post! I wonder if I can also fetch the data from custom form fields in a from a regular form submission (i.e. not an event registration) to reuse it as personalization in e-mails. So far, I haven’t found out how… but maybe you’ve got an idea?

    • Hi Ariane, you are very welcome and thanks for your feedback!
      Your request is possible, although not quite as “convenient” as with the unmapped registration fields. What is available to you is the 1:n relation of field submissions to form submissions. Therefore we have to work with the “lists” feature. In the following example, I simply use the “Marketing Form Submitted” trigger and then search for the field submissions via the Form Submission Entity Reference. Here I set a filter to the desired field name (in my case “stringfield_1”) – but you can also see this in the form submissions. I would then recommend returning a maximum of one element, as lists can generally return several data records, but we only want one value here. This way are on the safe side. The field value should then be selected as the column.

      Definition of field value

      You can then insert your list (which will only de facto contain one value) into the email body.

      Integration of field value

      I hope, that this helps 🙂
      Best, Johannes

Leave a Comment

Your email address will not be published. Required fields are marked *