Umbraco Forms 17.5.0 – FieldMapper setting gives "The configured property editor UI could not be found"

charlesa-ccs · August 27, 2026, 1:33pm

Hello :D.

I’m migrating a custom Umbraco Forms workflow from Umbraco 13 to Umbraco 17.

I’m running:

Umbraco CMS: 17.6.2
Umbraco Forms: 17.5.0

The workflow contains this setting:

[Setting(
    "Field to update",
    Description = "Field that will be populated with the score",
    View = "FieldMapper")]
public string? Field { get; set; }

When I open the workflow in the Umbraco 17 backoffice, the setting label appears:

Field that will be populated with the score

but the FieldMapper control fails with:

The configured property editor UI could not be found.

The additional details say:

This property editor UI is missing. Ensure your custom UI is registered correctly and the alias matches your configuration.

I’ve investigated the Forms JavaScript because I found the Forms TypeScript declaration for:

FormsFieldMapperPropertyUiElement

with the element name:

forms-field-mapper-property-editor

However, in the browser console:

customElements.get('forms-field-mapper-property-editor')

returns:

undefined

I’ve also searched the loaded Forms JavaScript bundles for forms-field-mapper-property-editor and FormsFieldMapperPropertyUiElement, but cannot find the implementation in the loaded runtime bundles.

I can see that Forms 17 has a FieldMapper property editor declaration, so I’m trying to understand whether this is:

A Forms 17.5.0 bug/regression,
A missing backoffice registration,
A change to the View = "FieldMapper" syntax in Forms 17, or
Something else required when migrating a custom workflow from Forms 13.

Has anyone successfully used View = "FieldMapper" on a custom workflow setting with Umbraco Forms 17.5.x?

I’m deliberately trying to use the supported Forms FieldMapper rather than create a custom replacement.

justin-nevitech · August 27, 2026, 3:45pm

Hi @charlesa-ccs

Looking at the docs, the alias you need is:

Forms.PropertyEditorUi.FieldMapper

Although, a different field mapper type may be more appropriate for what you are trying to capture, such as:

Forms.PropertyEditorUi.TextWithFieldPicker

Justin

charlesa-ccs · August 27, 2026, 3:51pm

Hi @justin-nevitech that’s what I have been trying, it does not seem to work though. Is there a way I can raise a bug? I looked at the repository in GitHub but that’s restricted?

        [Setting(
            "Field to update",
            Description = "Field that will be populated with the score",
           View = "Forms.PropertyEditorUi.FieldMapper")]
        public string? Field { get; set; }

mistyn8 · August 27, 2026, 4:43pm

Don’t seem to have the same issue?
(just added the settings to the test workflow from the docs)

works for me with both string or string? too as the backing type.

using Umbraco.Cms.Core.Composing;
using Umbraco.Forms.Core;
using Umbraco.Forms.Core.Enums;
using Umbraco.Forms.Core.Persistence.Dtos;
using Umbraco.Forms.Core.Providers;

namespace MyFormsExtensions
{
    public class TestWorkflow : WorkflowType
    {
        private readonly ILogger<TestWorkflow> _logger;

        #region Settings
        [Umbraco.Forms.Core.Attributes.Setting("Message", View = "Umb.PropertyEditorUi.TextBox")]
        public string Message { get; set; }

        [Umbraco.Forms.Core.Attributes.Setting("Mapping", View = "Forms.PropertyEditorUi.FieldMapper")]
        public string? Mapping { get; set; }

        #endregion Settings

        public TestWorkflow(ILogger<TestWorkflow> logger)
        {
            _logger = logger;

            this.Id = new Guid("ccbeb0d5-adaa-4729-8b4c-4bb439dc0202");
            ...
         }
  }
}

PS Umbraco 17.6.2 for me.. (not the 17.6.3 you mentioned as not sure that’s a thing )

greystate · August 28, 2026, 6:16am

Hi Charles

The closed source parts of Umbraco usually have a dedicated “Issues” repository – for Forms that’s Umbraco.Forms.Issues on GitHub.

/Chriztian

charlesa-ccs · August 28, 2026, 8:25am

Thanks, yes I have upgraded the description to 17.6.2. . I am now more confused. I will remove everything and just try to get this working on its own i guess

[Umbraco.Forms.Core.Attributes.Setting(“Mapping”, View = “Forms.PropertyEditorUi.FieldMapper”)]
public string? Mapping { get; set; }

charlesa-ccs · August 28, 2026, 1:27pm

So I named the property

        public string? Mapping { get; set; }

and it started working. Thanks everyone

Luuk · August 28, 2026, 1:28pm

View = "FieldMapper" is v13-style. It’s an AngularJS view name, and those stopped being a thing in v14. Since v14 the View property takes a property editor UI alias, so it needs to be `View = "Forms.PropertyEditorUi.FieldMapper"`.

AI can explain in more detail:

Why it fails the way it does

The View property survived the v14 rewrite but changed meaning entirely. In v13 it named an AngularJS view that Forms resolved to an HTML file under App_Plugins. From v14 the backoffice is built on Web Components, and View is now just the alias of a registered property editor UI — the same kind of alias you’d use for Umb.PropertyEditorUi.TextBox or Umb.PropertyEditorUi.Dropdown.

That value is passed through to the backoffice as-is and handed to Umbraco’s property element. There’s no legacy-name translation and no server-side validation of the alias, so a v13-era value isn’t rejected anywhere — it just travels all the way to the client, matches no registered editor, and you get the generic “The configured property editor UI could not be found.”

The console message about forms-field-mapper-property-editor being undefined is a red herring, by the way. Property editor UIs are lazy-loaded via their manifest, so the custom element is only defined once the alias resolves. The undefined element is a symptom of the unresolved alias, not a missing bundle.

A few things worth checking while you’re in there

Audit every [Setting] in the code you migrated, not just this one. Anything whose View isn’t prefixed Umb.PropertyEditorUi. or Forms.PropertyEditorUi. is stale and will fail the same way. Omitting View entirely gives you a textbox, which is a safe default.
Your stored values are fine — the field mapper’s value format (a JSON array of alias/value/staticValue entries) didn’t change, so existing v13 settings will load once the alias is corrected. There’s nothing to migrate in the database.
The field mapper reads the current form to build its list of fields, so it works on workflow and field type settings but will come up empty if you try to reuse it outside a form’s editing context.
Both string and string? work as the backing property type.

The documentation on setting types lists the available aliases and is the reference to work from for the rest of the migration.

mistyn8 · August 28, 2026, 1:55pm

Peeked my interest so I tested with

        [Umbraco.Forms.Core.Attributes.Setting("Mapping", View = "Forms.PropertyEditorUi.FieldMapper")]
        public string? Field { get; set; }

and

        [Umbraco.Forms.Core.Attributes.Setting("Field", View = "Forms.PropertyEditorUi.FieldMapper")]
        public string? Field { get; set; }

and both worked… (could have been a collision or a reserved keyword Field but doesn’t seem to hold true ?)

So I wonder if just the action of a build (rebuild, clean and build ??) has resulted in stale webcomponent JS being updated, or indeed created for the forms Forms.PropertyEditorUi.FieldMapper side of things?

Or maybe old bad data stored in the property causing issue? (don’t know if this was a rebuild or a migration in place on the DB from your initial post)

charlesa-ccs · August 28, 2026, 2:23pm

Thanks @mistyn8. It still wont work with that name (I will try again). It been driving me nuts! Did not start working until I changed the name

Luuk · August 28, 2026, 2:25pm

The first parameter is only the display label and is not used for anything else, so it’s value does not matter at all. I guess stale cache or an old build is the most likely cause.

charlesa-ccs · August 28, 2026, 2:28pm

But I did change the property name to Mapping from Field

public string? Mapping { get; set; }