Populate form fields from existing data

We have an issue in one of our migrations - iFormprovider has been deprecated.
One of our portals heavily relies on users updating existing form submission information as a part of an applicaiton process that can take multiple sessions.
We are looking at our options for how we can populate form values at load or render without this function. The only proposal we have currently is to completely rebuild all the field types manually - besides this being a lot of work, it is difficult to maintain and will mean any update point is fragile.

Does anyone have a similar problem or solution to this issue?

Environment

Tags:
Form Builder

Answers

The deprecation warnings are annoying, but it's worth noting that the [Obsolete] on IFormProvider was added in v30.12.0 (13 November 2025).

We're like 9 refreshes (and a major) past that, and the interface has been untouched - Kentico still heavily rely on it in their own Form widget and model binder etc. They actually suppress the warning:

#pragma warning disable CS0618 // Type or member is obsolete
private readonly IFormProvider formProvider;
#pragma warning restore CS0618 // Type or member is obsolete

From what I understand Kentico are replacing the Form Builder in stages - e.g. new the validation rules that were released in a refresh, so I think in time the rest of the API will be replaced and the changelog will provide guidance at that point.

I'd personally keep on using it, until this guidance happens and then switch to a newer API. Today there are no good documented alternatives.

I don't think I've had to handle the scenario you've described in XbyK yet - typically if it's a larger more complex form (maybe with save & continue) we might even custom build the form entirely rather than relying on the Form Builder.

Good practical advice Liam Goldfinch, and you're right that IFormProvider is only obsolete (a compiler warning), not removed — the #pragma suppression is fine as a stopgap.

Two things to add:

1. On the deprecation source: per the official changelog, the Form Builder deprecations around that time were the legacy validation-rule API (v30.12.0) and legacy visibility-condition API (v31.0.0). IFormProvider itself isn't listed as newly obsolete in the changelog, so I'd treat the exact "v30.12.0" attribution as unconfirmed.

2. On populating fields from existing data (the original question): the documented, non-deprecated route is to work with the stored record via BizFormItem and render the form from your own controller/widget, rather than letting IFormProvider hydrate the built-in Form widget:

using CMS.OnlineForms;

// Load an existing submission to pre-fill your edit form
BizFormItem item = BizFormItemProvider.GetItem(submissionId, "bizform.applicationform");
string firstName = item.GetStringValue("FirstName", "");

// Save edits back to the same record
item.SetValue("FirstName", updatedFirstName);
item.SubmitChanges(false);

Values can also be set programmatically via hidden fields - see Handle form events. So, the custom-build the form suggestion is exactly the supported path for a multi-session edit flow.

To response this discussion, you have to login first.