Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Umbraco Forms is a commercial product. You have a 14-day free trial to try out the product. After your trial expires, you'll need to have a valid license to keep using the product on your site.
Licenses are sold per domain and will also work on all subdomains. With every license, you will be able to configure two development/testing domains.
The licenses are not bound to a specific product version. They will work for all versions of the related product.
Let's say that you have a license configured for your domain, mysite.com, and you've configured two development domains, devdomain.com and devdomain2.com.
The license will cover the following domains:
localhost
*.mysite.com
www.mysite.com
mysite.com.local
devdomain.com
www.devdomain.com
devdomain2.com
www.devdomain2.com
You can have only 1 license per Umbraco installation.
There are a few differences as to what the licenses cover:
A single license covers the installation of Umbraco Forms in 1 production domain, as well as in 2 development domains.
The production domain includes all subdomains (e.g. *.mysite.com), as well as the .local extension (e.g. mysite.com.local).
The development domains work with or without the www subdomain.
The license allows for an unlimited number of forms.
The license also includes localhost as a valid domain.
If you have multiple domains pointing at the same installation, you have the option to purchase and add additional domains to your license.
This is an add-on domain for existing licenses. Refunds will not be given for this product.
When you've bought a license you need to configure it with your domains. You can either configure your license right away or you can do it later by visiting your account on Umbraco.com.
Once you've configured your license with the correct domains, you are ready to install the license on your Umbraco installation.
Download your license from your Umbraco.com account - this will give you a .lic file
Place the file in the /umbraco/Licenses directory in your Umbraco installation
The .lic file must be placed in the /umbraco/Licenses directory to be registered by Umbraco Forms. If the file isn't placed correctly, the application will automatically switch to trial mode.
If you can't include the license file in the /umbraco/Licenses directory for any reason, it is possible to configure an alternative location for the file.
It can be configured in the Umbraco installation's appSettings.json file by adding the following appSetting. The value contains the path of your custom license directory relative to the root of your Umbraco installation.
This will also change the location for other Umbraco-related licenses in this project.
Installing Umbraco Forms
Umbraco contains the Forms section, by default. You will see a similar interface, when you click on the Forms section in the Umbraco Backoffice.
To install the Umbraco Forms package (Umbraco.Forms), follow these steps:
Run the following command on a command prompt of your choice:
Restart the web application using the following command:
Once the installation is successful, you will see a similar screen in the Forms section:
For details on using Forms, see the Editor Documentation.
This article shows how to manually upgrade Umbraco Forms to run the latest version.
When upgrading Umbraco Forms, be sure to also consult the version specific upgrade notes to learn about potential breaking changes and common pitfalls.
To get the latest version of Umbraco Forms, you can upgrade using:
NuGet installs the latest version of the package when you use the dotnet add package Umbraco.Forms command unless you specify a package version: dotnet add package Umbraco.Forms --version <VERSION>
After you have added a package reference to your project by executing the dotnet add package Umbraco.Forms command in the directory that contains your project file, run dotnet restore to install the package.
Go to Tools -> NuGet Package Manager -> Manage NuGet Packages for Solution... in Visual Studio, to upgrade your Forms:
Select Umbraco.Forms.
Select the latest version from the Version drop-down and click Install.
When the command completes, open the .csproj file to make sure the package reference is updated:
Version specific documentation for upgrading to new major versions of Umbraco Forms.
In this article, we'll take a look at the basic steps of creating a Form and adding the Form to your Umbraco site.
You can manage the Forms in the Forms section of the Umbraco backoffice. You need to have access to the section in order to see it.
If you do not see the Forms section, you might need to request access from the site Administrator. An Administrator can give permission to view the Forms section. This is done from within the Users section of the backoffice.
To create a Form, follow these steps:
Navigate to the Forms section.
Click ... next to the Forms folder.
The Create a new Form dialog opens.
Select Empty Form. The Form Designer opens in the editor.
By default, there is a page, a fieldset, and a container available. The rest of the Form has to be added using the interface.
Enter the Name for the Form. Let's call it Our first form.
[Optional] Enter the Page Name. We'll call it The first page. Click Add new page at the bottom of the Forms designer to add more pages.
[Optional] Enter the Group Name. Click Add new group to add another group.
Click the Add Question button to add a new field.
The Add Question dialog opens.
Enter the following details:
In the Sensitive data field, choose if the field stores sensitive data. Once selected, the data from this field will be prevented from being downloaded and viewed by users who do not have permission to do so. Only members of the sensitive data user group will see this option of downloading.
Enter a Default Value for the field.
Add a Placeholder to make it easier for the user to fill in the Form.
Select if the field is Mandatory and customize the message.
Add a Validation to the field. There are some predefined validations available but it is possible to add your own custom validation as well.
Some form fields allow you to show or hide the label that's associated with the field when it is rendered within the form on the website. The default is always to show the field, but if you prefer to hide it, untick the Show label option.
Some of the additional settings are dependent on which answer type was chosen. For example, since we selected Short Answer as our answer type we got two additional settings (Default Value and Placeholder).
Once the configuration is completed, click Submit. You will see that the field has been added to the Form designer.
To edit a field that has already been added to the Form, click the little cog icon next to the field to open the dialog. To delete a field or a group, click the Recycle Bin icon.
Once you've added a few fields to your Form, you might want to change the order of questions. To do so, click Reorder in the top-right corner of the Form designer.
When reordering your Form, you can drag and drop the fields to make it look the way you want. Click I am done reordering to get back to the Form designer.
Forms can be grouped into pages. When rendered, each page will be presented one at a time to the user. They will need to complete the first page before moving onto the second and can navigate back and forth between pages.
You can add a new page directly to the bottom of the form via the Add new page button. This will appear below other pages when at least one exists.
With a page, form fields can be arranged into groups. These will display all together on a single page but can be styled so the fields are appropriately grouped in fieldsets.
New groups are added via the Add new group button.
The last level of structure are columns that can be created within a group. To set the number of columns click the cog icon next to the group. You will then be able to add or move fields to the new columns created.
Once you are satisfied with the Form, you can save the design by clicking the Save button.
If installation of the product is configured for storage of form definitions in the database, you will have the option to store forms within folders. If you are planning to create a number of them, this may help with organization and locating them once created for modification.
To create a folder, access the same dialog used for creating a form. Here, you'll have the option to create a folder, for which you need to provide a name.
You can create folders within folders, rename, move and delete them. You also have the ability to move or copy forms into folders, all via the tree operations available from the ... menu.
To add the Form, follow these steps:
Navigate to the Content section of the Umbraco Backoffice.
Select the content page where you want to insert the Form. The page you choose should either have an Rich Text Editor (RTE) field, a Grid Editor, or a form picker all of which you can add in the Settings section under Document Types.
Click the Insert macro button in the toolbar of the RTE or Grid. The Select Macro dialog opens.
Click Add under Choose a Form and select the Form you want to insert. You will be able to select from the full list of forms. If available on your installation, you will also be able to select using a folder based view, which can be quicker to navigate when many forms have been prepared.
[Optional] Click Add under Theme to choose which theme the Form should use.
Finally you have an option to Exclude Scripts.
Click Submit.
The Form is inserted on to your page. Click the Save and publish button.
The date picker uses a front-end library called to display a UI to pick dates.
Pikaday date picker can be localised based on the page the Form is rendered on.
The date picker displays the picked date in the required locale. Using JavaScript, a hidden field is updated with a standard date format to send to the server for storing record submissions. This avoids the locale mixing up the dates.
To achieve localized date, a Razor partial view is included at /Views/Partials/Forms/Themes/default/DatePicker.cshtml.
The DatePicker.cshtml includes the moment-with-locales.min.js library to help with the date locale formatting and the appropriate changes to Pikaday to support the locales. If you wish to use a different DatePicker component, edit the DatePicker.cshtml file as per your needs.
The Date picker has a configuration setting to control the number of years shown in the picker. The default value is 10 years.
You can configure the settings in the appSettings.json file:
Update DatePickerYearRange to a higher number (for example: 100) to increase the numbers of years available in the Date picker.
A unique migration ID is generated for each Umbraco Forms upgrade that requires a migration. The migration IDs are all listed in this article.
Documentation on how to work with Umbraco Forms for both editors and developers
Umbraco Forms is a tool that lets you build forms of all shapes and sizes and put them on your Umbraco websites. Build forms using a long list of elements like multiple choice, dropdowns, text areas and checkboxes. Choose between a series of different workflow and control what happens once a form has been submitted.
or sign up for an project where Umbraco Forms is part of the package.
Get an overview of the things changed and fixed in each version of Umbraco Forms.
In this section, we have summarized the changes to Umbraco Forms released in each version. Each version is presented with a link to the showing a list of issues resolved in the release. We also link to the individual issues themselves from the detail.
If there are any breaking changes or other issues to be aware of when upgrading they are also noted here.
If you are upgrading to a new major version, you can find information about the breaking changes in the article
This section contains the release notes for Umbraco Forms 8 and 10 including all changes for these versions. For each major version, you can find the details about each release.
You can find the release notes for versions out of support in the and .
In this article, you will find information about accessing the Forms Settings and the validations available to customize your Form.
To access the Form Settings:
Navigate to the Forms section.
Open a Form you wish to customize.
Click Settings in the top-right corner of the screen.
The following options are available in Forms Settings:
By default, all submitted records are saved in the database. This option allows you to view and export the saved records from the queries overview. If you do not want to store data (due to policies in your organization), you can uncheck the box.
Disabling this option will prevent database records from being stored, but any file uploads made as part of the form submission will still be retained. If you do not want the files to be stored, ensure that any process or method used to process, move, or copy them to a different location also removes the file.
Customize the labels of the Submit, Next, and Previous buttons used in your Form.
Set a stylesheet to give your Form custom styling. You have an option to disable the default styling. Enabling the Disable default stylesheet option will prevent a default stylesheet to be added to the pages where the Form is placed.
Define a message that is displayed when a field is mandatory, when a value is not supplied, or when the value is invalid.
The following Validations are available:
The autocomplete setting for the overall form can be changed from the default of "None" to "On" or "Off". Setting this explicitly will control how the browser offers automatic prompts to the user when completing the form.
Enabling this feature allows the moderator to manage the approval status of a form. This can be used in a number of scenarios. For example, if the form submission will be publicly shown, you can control which are published.
By default, a constant set of fields are displayed when form entries are shown in a list. You will see the first three fields in the form, plus some system information like the record state and the date it was created.
To customize this, turn off the "Display default fields" option and select the ones you wish to display.
To help protect site visitor privacy, rules can be configured in this section for the automatic deletion of submissions. You can set how long to retain records for each state (submitted or approved).
This documentation platform covers only major versions of the Umbraco Forms since Umbraco 9+. If you are using an older version of Umbraco Forms, you will need to go elsewhere.
The documentation for Umbraco 7 and 8 lives on .
Additional domains can be purchased from your account on . Each additional domain includes 1 live domain and 2 development/testing domains.
You can look at the pricing, features, and purchase the license on the page.
Once a license has been configured with the domains, it is not possible to reconfigure them. An exception is when there is a mistake in the domain URL. As reconfiguration is not possible, you will either need to purchase an additional domain or a .
You can find the version specific upgrade notes for versions out of support in the .
Set Conditions for the field. For more information on Conditions, see the article.
A background service that carries out the actual removal of records needs to be . If that is not running, a notification will be displayed.
Enter question
Name
Enter help text
Enter your name here
Choose answer type
Short answer
7c7bc5ee-4c5b-42dc-9576-5ce6dfbddb8e
10.0.0
Installs Umbraco Forms.
9f7e6fe6-bbd5-4b2b-8820-e9e0e36cc74c
10.1.0
Adds Culture column to Records table.
1a8f0d04-9396-40a2-9423-39fc9ae3828f
10.1.0
Adds a Record Workflow Audit table.
6e692c5d-c670-4c34-af17-28d8dbf0dcd2
10.1.0
Adds an ExecutionStage column to the Record Workflow Audit table.
5d84fee1-388c-4e5f-b98c-1e66947278f1
10.1.0
No operation migration.
22df962a-ae26-4bdd-b8fd-0513a9c636bf
10.5.2
Ensures the presence of an index on the FolderKey column in the Forms table.
Mandatory error message
The error message is displayed for a field that is marked as mandatory but a value has not been provided upon submission. This setting can be overwritten on a field level - {0} will be replaced with the field caption.
Invalid error message
The error message is displayed for a field if the value provided is not valid (a regular expression has been setup but the input does not match). This setting can be overwritten on a field level - {0} will be replaced with the field caption.
Show validation summary
Enable this option if you wish to display a summary of all the error messages on top of the Form.
Hide field validation labels
Enable this option if you wish to hide individual field error messages from being displayed.
Mark fields
You can choose to not mark any fields or only mark mandatory or optional fields.
Indicator
Choose which indicator to use when a field has been marked as mandatory. The default indicator is *
For Umbraco Forms to work correctly, you need to include some client dependencies.
Umbraco Forms ships with client-side form validation features provided by the ASP.NET Client Validation library.
You can use the following Razor helper to output script tags containing the dependencies. To access this method you will need a reference to Umbraco.Forms.Web:
Alternatively, you can add the dependencies to the body tag:
All dependencies originate from your Umbraco Forms installation, which means that no external references are needed.
If you want to use jQuery as your validation framework for Umbraco Forms, you can manually add the following client dependencies:
jQuery (JavaScript library)
jQuery validate (jQuery plugin that provides client-side Form validation)
jQuery validate unobtrusive (Add-on to jQuery Validation that provides unobtrusive validation via data-* attributes)
You should remove any calls to @Html.RenderUmbracoFormDependencies(Url).
The easiest way to add the dependencies is to fetch them from a CDN. There are various CDN services you can use:
For example: Microsoft CDN.
Other CDN services you might want to look at are https://www.jsdelivr.com/ and https://cdnjs.com/about, which may offer better performance and more reliable service.
To add the three client dependencies, see the examples below:
Example within head tags.
Example within body tags.
When adding the script to the bottom of the page, you will also need to render the scripts. For more information, see Rendering Forms Scripts article.
Learn the different ways of rendering a form on your website when using Umbraco Forms.
There are three options available for rendering a form.
To display a form in your view, you can make a call to a view component:
Four parameters can be provided:
formId is the GUID of a form.
theme is the name of a theme. If not provided, the default theme is used (see Themes).
includeScripts indicates whether scripts should be rendered with the form (see Rendering Scripts.
recordId is an optional existing record GUID, used if editing records via the website is enabled in configuration
Usually, rather than hard-coding the form's GUID, you'll use a form and/or theme picker property on your page:
If you prefer a tag helper syntax, you can use one that ships with Umbraco Forms.
Firstly, in your _ViewImports.cshtml file, add a reference to the Umbraco Forms tag helpers with:
Then in your view you can use:
With a grid or Rich Text Editor, you need to use a macro. This is also available as an option to display a form in your view, where you provide three parameters:
FormGuid is the GUID of a form.
FormTheme is the name of a theme. If not provided, the default theme is used.
ExcludeScripts takes a value of 0 or 1, indicating whether scripts should be excluded from rendering.
Similarly, you can reference a form picker property on your page:
Creating an email template for Umbraco Forms.
We include a Workflow Send email with template (Razor) that allows you to pick a Razor view file that can be used to send out a pretty HTML email for Form submissions.
If you wish to have one or more templates to choose from the Send email with template (Razor), you will need to place all email templates into the ~/Views/Partials/Forms/Emails/ folder.
The Razor view must inherit from FormsHtmlModel:
You now have a model that contains your Form fields which can be used in your email HTML markup, along with the UmbracoHelper methods such as Umbraco.TypedContent and Umbraco.TypedMedia etc.
Below is an example of an email template from the ~/Views/Partials/Forms/Emails/ folder:
Developer documentation on working with Forms record data.
Umbraco Forms includes some helper methods that return records of a given Form, which can be used to output records in your templates using razor.
The methods can be found by injecting the Umbraco.Forms.Core.Services.IRecordReaderService interface. For performance reasons, all these methods are paged.
Returns all records with the state set to approved from all Forms on the Umbraco page with the id = pageId .
Returns all records with the state set to approved from the Form with the id = formId on the Umbraco page with the id = pageId as a PagedResult<IRecord>.
Returns all records with the state set to approved from the Form with the ID = formId as a PagedResult<IRecord>.
Returns all records from all Forms on the Umbraco page with the id = pageId as a PagedResult<IRecord>.
Returns all records from the Form with the id = formId on the Umbraco page with the id = pageId as a PagedResult<IRecord>.
Returns all records from the Form with the ID = formId as a PagedResult<IRecord>.
All of these methods will return an object of type PagedResult<IRecord> so you can iterate through the IRecord objects.
The properties available on a IRecord are:
In order to access custom Form fields, these are available in the RecordFields property. Furthermore there exists an extension method named ValueAsString on IRecord in Umbraco.Forms.Core.Services, such that you can get the value as string given the alias of the field.
This extension method handle multi value fields by comma separating the values. E.g. "A, B, C"
Sample script that is outputting comments using a Form created with the default comment Form template.
This builds on the "adding a type to the provider model" chapter
Add a new class to the Visual Studio solution, make it inherit from Umbraco.Forms.Core.FieldType and fill in the constructor:
In the constructor, we specify the standard provider information:
Id - should be set to a unique GUID.
Alias - an internal alias for the field, used for localized translation keys.
Name - the name of the field presented in the backoffice.
Description - the description of the field presented in the backoffice.
Icon - the icon of the field presented in the backoffice form builder user interface.
DataType - specifies the type of data stored by the field. Options are String, LongString, Integer, DataTime or Bit (boolean).
SupportsRegex - indicates whether pattern based validation using regular expressions can be used with the field.
FieldTypeViewName - indicates the name of the partial view used to render the field.
RenderInputType- indicates how the field should be rendered within the theme, as defined with the RenderInputType enum. The default is Single for a single input field. Multiple should be used for multiple input fields such as checkbox lists. Custom is used for fields without visible input fields.
You will then need to register this new field as a dependency.
Then we will start building the view for the default theme of the Form at Views\Partials\Forms\Themes\default\FieldTypes\FieldType.MyCustomField.cshtml.
The file name for the partial view should match the value set on the FieldTypeViewName property.
This will be rendered when the default theme is used.
If working with Umbraco 9 or earlier versions, you'll find the Views\Partials\Forms\Themes\default\ folder on disk and can create the files in there.
For Umbraco 10 and above, we've moved to distributing the theme as part of a Razor Class Library so the folder won't exist. However, you can create it for your custom field type. If you would like to reference the partial views of the default theme, you can download them as mentioned in the Themes article.
The final step involves building the HTML view which will be rendered in Umbraco as an example of how our end result will look:
In the HTML you can access settings via field.settings, e.g. {{field.settings.Caption}} to render a "Caption" setting. It is also possible to access prevalues via field.parsedPreValues.
For built-in field types, Umbraco Forms look for this file in the virtual folder: App_Plugins\UmbracoForms\backoffice\Common\FieldTypes\. It will expect to find a file with a name matching the class's name, i.e. mycustomfield.html. To add custom fields and themes, create a folder at the specified path (also known as the virtual folder). This is because the client-side code is included in the Razor Class Library. As a result, these files are available as if they're stored at a specific location on disk.
To store in a different location, you can apply the following override to the custom field type's C# representation:
Field settings that will be managed in the backoffice by editors creating forms using the custom field type can be added to the C# class. These settings can be added as properties with a Setting attribute:
The property Name names the setting in the backoffice with the Description providing the help text. Both of these are translatable by providing a user or package language file containing appropriate keys:
The area aliases for the other provider types are as follows:
Data sources - formProviderDataSources
Export types - formProviderExportTypes
Prevalue sources - formProviderPrevalueSources
Recordset actions - formRecordSetActions
Workflows - formProviderWorkflows
The View attribute defines the client-side view used when rendering a preview of the field in the form's designer. Umbraco Forms ships with a number of these, found in a virtual path of App_Plugins\UmbracoForms\backoffice\Common\SettingTypes\.
Again though, you can use your own location, and configure with a full path to the view, e.g.:
To reference the file the setting should be configured with a full path to the view, e.g.:
SupportsPlaceholders is a flag indicating whether the setting can contain "magic string" placeholders and controls whether they are parsed on rendering.
HtmlEncodeReplacedPlaceholderValues takes effect only if SupportsPlaceholders is true. It controls whether the replaced placeholder values should be HTML encoded (as is necessary for rendering within content from a rich text editor).
The third and final client-side view file used for settings is in the rendering of the submitted values for the field. This rendering takes place in the "Entries" section of the backoffice.
These are defined by the RenderView property of a field type and are found in App_Plugins\UmbracoForms\backoffice\Common\RenderTypes\.
As for the other files, if you require a custom render type view, it's better to host them in different location, such as App_Plugins\UmbracoFormsCustomFields\backoffice\Common\RenderTypes\mycustomrenderfield.html.
To reference the file you should override the RenderView property, e.g.:
In Umbraco Forms, it is only possible to store Form data in the database.
If you are upgrading to Umbraco 9 or later and using Forms, you should first migrate the Forms to the database using Forms 8. As of Umbraco Forms version 8.5.0 it is possible to persist all Forms data in the Umbraco database. This includes definitions for each Form and their fields, as well as workflow definitions and prevalues.
Custom file system providers
If custom file system providers are used on your project for storing Umbraco Forms data, the migration will not be able to run.
To persist your Umbraco Forms data in the database, you will need to revert to a standard Umbraco Forms configuration. Use the default provider to store the Forms definition files in the default location.
You need to ensure that your Forms definition files are moved from their previous location. This is a non-default file path, blob storage, or similar to the default location, App_Data/UmbracoForms, that Forms will now be using.
Your configuration is now considered a standard configuration and you can perform the steps required for a normal migration.
To persist Umbraco Forms definitions in the database, follow these steps:
Upgrade to at least Umbraco Forms version 8.5.2.
Open the configuration file App_Plugins\UmbracoForms\UmbracoForms.config.
Locate the StoreUmbracoFormsInDb key in the <settings> section, and make sure it has the following value:
Save the file.
If you are working with a Umbraco Cloud project, make sure you follow the migration steps outlined in the Umbraco Forms on Cloud article.
Enabling the persisting of Umbraco Forms in the database is irreversible. Once you've made the change, reverting to the file approach will not be an option.
When you save the file, the site will restart and run a migration step, migrating the files to the Umbraco database.
You can force Forms to rerun the migration of the file-format Forms if you have a Umbraco 8 site storing Forms in the database.
First of all, you should ensure that you have enabled the setting that persists Forms in the database, as the migration requires this (StoreUmbracoFormsInDb) key. We highly recommend testing this on a local setup before applying it to your live site.
Copy over the Forms, workflows, prevaluesources, and datasource files to the site into ~\App_Data\UmbracoForms\Data.
Go to the database and find the [umbracoKeyValue] table.
Find the Form's row and check that the value is 1d084819-84ba-4ac7-b152-2c3d167d22bc (if not you are not currently working with Forms in the database, changing the setting should be enough).
Change that value to {forms-init-complete}.
Restart the site.
The site will now try to migrate the Forms files into the database. In the umbracoTraceLog, you can follow the progress. It will throw errors if anything goes wrong. Additionally, it will log out "The Umbraco Forms DB table {TableName} already exists" for the 4 Forms tables before starting the migration.
Umbraco Forms functionality can be extended in different ways. In this section we focus on techniques available to a back-end/C# developer.
For front-end extensions, specifically via theming, see the Themes section.
The Forms package comes with many field, workflow, and other built-in types. If you have a requirement that isn't served by any of these, you can create and develop your own.
Many features of Forms use a provider model, which makes it quicker to add new parts to the application.
The model uses the notion that everything must have a type to exist. The type defines the capabilities of the item. For instance a Textfield on a form has a FieldType, this particular field type enables it to render an input field and save text strings. The same goes for workflows, which have a workflow type, datasources which have a datasource type and so on. Using the model you can seamlessly add new types and thereby extend the application.
It is possible to add new Field types, Data Source Types, Prevalue Source Types, Export Types, and Workflow Types.
A field type handles rendering of the UI for a field in a form. It renders a standard ASP.NET Razor partial view and is able to return a list of values when the form is saved.
The concept of provider settings, common to the field and other types, is also discussed in this section.
A data source type enables Umbraco Forms to connect to a custom source of data. A data source consists of any kind of storage if it is possible to return a list of fields Umbraco Forms can map values to. For example: a Database data source can return a list of columns Forms can send data to. This enables Umbraco Forms to map a form to a data source. A data source type is responsible for connecting Forms to external storage.
A prevalue source type connects to 3rd party storage to retrieve values. These values are used on fields supporting prevalues. The source fetches the collection of values.
A workflow can be executed each time a form changes state (when it is submitted for instance). A workflow is responsible for executing logic which can modify the record or notify 3rd party systems.
Export types are responsible for turning form records into any other data format, which is then returned as a file.
Custom magic string format functions to add to the ones shipped with Umbraco Forms can be created in code.
When creating a text field in Umbraco Forms, a validation pattern in the form of a regular expression can be applied. Default patterns can be removed or re-ordered, and custom ones created and added.
Another option for extension via custom code is to hook into one of the many events available.
Form events are raised during the submission life cycle and can be handled for executing custom logic.
When a new form is created, the default behavior is to add a single workflow. This workflow will send a copy of the form to the current backoffice user's email address.
A single "data consent" field will also be added unless it has been disabled via configuration.
It's possible to amend this behavior and change it to fit your needs.
In the course of submitting a form, Umbraco Forms will set values in TempData and/or HttpContext.Items, that you can use to customize the website functionality.
Whether displaying a message or redirecting, a developer can customize the page viewed after the form is submitted based on the presence of TempData variables.
One variable with a key of UmbracoFormSubmitted has a value containing the Guid identifier for the submitted form.
A second variable contains the Guid identifier of the record created from the form submission. You can find this using the Forms_Current_Record_id key.
In order to redirect to an external URL rather than a selected page on the Umbraco website, you will need to use a custom workflow. Within this workflow you can set the required redirect URL on the HttpContext.Items dictionary using the key FormsRedirectAfterFormSubmitUrl (defined in the constant Umbraco.Forms.Core.Constants.ItemKeys.RedirectAfterFormSubmitUrl).
For example, using an injected instance of IHttpContextAccessor:
This builds on the "adding a type to the provider model" chapter
Add a new class to your project and have it inherit from Umbraco.Forms.Core.WorkflowType, implement the class. For this sample we will focus on the execute method. This method process the current record (the data submitted by the form) and have the ability to change data and state.
The Execute() method gets a WorkflowExecutionContext which has properties for the related Form, Record, and FormState. This parameter contains all information related to the workflow.
The Record contains all data and metadata submitted by the form. As shown in the example above, you can iterate over all RecordField values in the form. You can also retrieve a specific record field by alias using the following method:
Having obtained a reference to a record field, the submitted value can be retrieved via:
The ValuesAsString will JSON escape the result by default. If you do not want this escaping to occur, pass false as the parameter.
If the field stores multiple values, they are delimited with a comma. In many cases, you can safely split on that delimiter to obtain the individual values. However, this can lead to issues if the prevalues being selected also contain commas. If that's a concern, the following extension method is available in Umbraco.Forms.Core.Extensions to correctly parse the selected prevalues:
The Form references the form the record is from and FormState provides its state (submitted or approved).
Other context, such as the current HttpContext, if needed can be passed as constructor parameters (for example: the HttpContext can be accessed by injecting IHttpContextAccessor).
To use the new workflow type, you will need to register it as part of application startup.
This builds on the "Adding a type to the provider model" article
Add a new class to your project - inherit it from Umbraco.Forms.Core.FieldPreValueSourceType and implement the class.
The following example shows an illustrative custom prevalue source type that returns a hard-coded list of values. It can be extended for your needs via injection of services via the constructor. (See additional example at the bottom.)
Dynamic settings can be applied and validated as shown in the Validate type settings with ValidateSettings() article.
You will then need to register this new prevalue source type as a dependency.
The PreValue model in Umbraco Forms Versions 8.13.0, 9.5.0, 10.1.0, and above includes a .Caption property. This property is set separately from the .Value property. In the previous versions, the Value is generally used as the caption when rendered on the form.
This example will take a user-provided Content Node and create a custom Prevalue list from the property data on that node. Your own FieldPreValueSourceType can get its data from wherever you like - an API call, custom functions, etc.
You will then need to register this new type as a dependency (either in 'Startup.cs' or in your own IComposer, as shown here).
This builds on the "adding a type to the provider model" chapter and applies to Umbraco Forms version 4.4.1 and higher
Add a new class to your project and have it inherit from Umbraco.Forms.Core.ExportType and you have two options when implementing the class.
When implementing the method public override string ExportRecords(RecordExportFilter filter) in your export provider class. You need to return the final string you wish to write to a file. Such as .txt file or .csv and you can perform your logic to build up a comma separated string for a CSV file in the ExportRecords method.
In the constructor of your provider, you will need a further two properties, FileExtension and Icon.
The FileExtension property is the file extension such as zip, txt or csv of the file you will be generating & serving from the file system as the export file.
In this example below we will create a single HTML file which takes all the submissions/entries to be displayed as a HTML report. We will do this in conjunction with a Razor partial view to help build up our HTML and thus merge it with the form submission data to generate a string of HTML.
This approach gives us more flexibility in creating the file we wish to serve as the exported file. We do this for the export to Excel file export provider we ship in Umbraco Forms. With this we can use a library to create the Excel file and store it in a temporary location before we send back the filepath for the browser to stream down the export file.
In this example we will create a collection of text files, one for each submission which is then zipped up into a single file and served as the export file.
To add a new type, no matter if it's a workflow, field, data source, etc, there is a number of tasks to perform to connect to the Forms provider model. This chapter walks through each step and describes how each part works. This chapter will reference the creation of a workflow type. It is, however, the same process for all types.
Create a new class library project in Visual Studio add references to the Umbraco.Forms.Core.dll (available via referencing the NuGet package). You might also need to reference Umbraco.Forms.Core.Providers.
The Forms API contains a collection of classes that can be registered at startup or in an Umbraco component. So to add a new type to Forms you inherit from the right class. In the sample below we use the class for the workflow type.
When you implement this class you get two methods added. One of them is Execute which performs the execution of the workflow and the other is a method which validates the workflow settings, we will get back to these settings later on.
Any dependencies required that are registered with the dependency injection container can be provided via the constructor.
Even though we have the class inheritance in place, we still need to add a bit of default information.
Even though we have the class inheritance in place, we still need to add a bit of default information. This information is added in the class's constructor like this:
All three are mandatory and the ID must be unique, otherwise the type might conflict with an existing one.
Now that we have a basic class setup, we would like to pass setting items to the type. So we can reuse the type on multiple items but with different settings. To add a setting to a type, we add a property to the class, and give it a specific attribute like this:
The Umbraco.Forms.Core.Attributes.Setting registers the property in Umbraco Forms and there will automatically be UI and storage generated for it. In the attribute, a name, description and the view to be rendered is defined.
With the attribute in place, the property value is set every time the class is instantiated by Umbraco Forms. This means you can use the property in your code like this:
For all types that use the provider model, settings work this way. By adding the Setting attribute Forms automatically registers the property in the UI and sets the value when the class is instantiated.
The ValidateSettings() method which can be found on all types supporting dynamic settings, is used for making sure the data entered by the user is valid and works with the type.
To register the type, ensure your web application project has a reference to the class library - either via a project or NuGet reference - and add the following code into the startup pipeline. In this example, the registration is implemented as an extension method to IUmbracoBuilder and should be called from Startup.cs:
An alternative approach is to use a composer, as per this example:
From Umbraco Forms 9.5 and 10.0, there are further convenience methods you can use for registering custom types. These are found in the namespace Umbraco.Forms.Core.Providers.Extensions.
For example, instead of the following:
Your workflow can be registered using:
Or:
Existing items that are not required in a particular installation can be removed with:
Also look in the reference chapter for complete class implementations of workflows, fields and export types.
It is possible to override and inherit the original provider, be it a Field Type or Workflow etc. The only requirement when inheriting a fieldtype that you wish to override is to ensure you do not override/change the Id set for the provider, and make sure your class is public.
Here is an example of overriding the Textarea field aka Long Answer.
As discussed in the previous section, you must also register the extended field type within a composer. You also need to create the the backoffice field type view.
Composer:
Backoffice View:
Add a new HTML file as per the name of the field class (e.g. textareawithcount.html) to \wwwroot\App_Plugins\umbracoforms\Backoffice\Common\FieldTypes\ within your project. For this example, we can copy the original textarea.html file used by the standard 'Long Answer' field.
The AngularJS client-side files are shipped with Umbraco Forms as part of a Razor Class Library. So you won't find these files on disk when you install the package.
However if you do want to reference them you can view and extract them from the Umbraco.Forms.StaticAssets NuGet package.
Umbraco Forms comes with some built-in fields however it is possible to exclude/remove them if necessary. There might some use cases where you have no use for file upload and don't want editors using them. Or perhaps you want to remove a field to replace it with one with enhanced functionality that you build yourself.
The following class shows how to exclude built-in field types using a custom composer. The Password, Recaptcha2 and RichText field types (or "answers") will no longer be available for selection when creating a form in the backoffice.
Provides details of the built-in provider types available with Umbraco Forms
Documentation on how to apply custom themes to Umbraco Forms
Umbraco Forms supports Themes, allowing forms to be customized in a much simpler manner.
To create a theme, you need to create a folder at /Views/Partials/Forms/Themes/. The name of the folder is the name of theme that will be visible in the backoffice when choosing it.
Copy the explicit files you wish to override in your theme, it may be a single file or all files from the default theme folder. Make the necessary changes you desire to CSS class names, markup etc.
For Umbraco 9 and previous, it's straightforward to copy the files you need from the default theme folder. We highly recommend that you never customize any files found in the default themes folder. There is a risk that any customizations to these files will be lost with any future upgrades you do to Umbraco Forms.
Umbraco 10+ distributes these files as part of a Razor class library, so you won't find them on disk. Instead you should download the appropriate zip file for your Forms version and extract the ones you need.
You can obtain the latest version of the default theme Forms 10 from the following link:
Forms 10 Default Theme (for 10.5.6 and above)
If you are using a lower minor version of Forms than those listed, you should download an older version of the default theme.
The default theme for minor versions are available from the "Source Code" tab available at the bottom of Umbraco Forms Package page. Only versions where changes were made are available.
You should use the theme available for the highest version that's less or equal to the version of Forms you have installed.
For example, when using Umbraco Forms 10.4, and no file for that version is available use version 10.3 instead.
Umbraco Forms conditional JavaScript logic depends on some CSS classes currently and it is advised that you add any additional classes you require but do not remove those already being set.
If adding or amending client-side scripts, you need to copy the Script.cshtml file from the default themes folder. In your copy, amend the .js references to reference your own script files.
To use a theme with a Form use the "Insert Form" macro where you will be presented with the options of the form you wish to insert along with an option to pick a theme. This displays the list of theme folders found at Views/Partials/Forms/Themes.
When you are rendering your form directly in your template, you need to specify your theme by filling out the FormTheme attribute:
If you do not pick and/or set a theme, the default theme will be used to render the form.
When using a theme, Umbraco Forms will try to use a view from the theme folder, but then fallback to the same view in the default theme folder if it can't be found. This allows you to create a theme by only modifying the files necessary to make your customizations.
Files which can be overridden:
Render.cshtml (overrides the entire form - usually not needed)
Form.cshtml (overrides the generation of the fields on the current page)
Script.cshtml (overrides the way files are included with the form)
/Fieldtypes/FieldType.*.cshtml (overrides a specific view for a field)
Sets the primary form theme stylesheet path. This overrides an already assigned stylesheet and will be rendered out when inserting the form into the page
Add a JavaScript file path to include on form render
Adds a class to the form field HTML element of a given type. If no type is given, it will add the class to all fields
Retrieves all classes for a given field type, used when rendering form fieldtype partial views
Adds a class to the div element wrapping around form fields of a given type. If no type is given, it will add the class to all fields
Retrieves all wrapper classes for a given field type, used when rendering form fields. This class wraps both label, help-text and the field itself in the default view
Forms output some JavaScript which is by default rendered right below the markup.
In many cases, you might prefer rendering your scripts at the bottom of the page. For example, before the closing </body> tag. This generally improves site performance.
In order to render your scripts where you want, you need to add a snippet to your template. Make sure you add it below your scripts, right before the closing </body> tag.
By default, Forms uses TempData for tracking the forms rendered on a page. The stored values are used when rendering the form scripts and associated data.
The following snippet should be used.
If you have changed the configuration value TrackRenderedFormsStorageMethod to use HttpContext.Items, the snippet is:
Read more about this configuration option in the configuration article.
If you prefer to use a tag helper, that's an option too.
Firstly, in your _ViewImports.cshtml file, ensure you have a reference to the Umbraco Forms tag helpers with:
Then instead of reading from TempData and invoking the view component directly, you can use:
This will use the appropriate storage method that you have configured.
ExcludeScriptsIf you do not want to render the associated scripts with a Form, you need to explicitly say so. You need to make sure ExcludeScripts is checked/enabled, whether you are inserting your Form using a macro or adding it directly in your template.
To enable ExcludeScripts:
Using the Insert Form with Theme macro:
While inserting Forms directly in your template:
ExcludeScripts = "1" prevents the associated scripts from being rendered. Any other value, an empty value, or if the parameter is excluded, will render the scripts on the Form.
With Umbraco Forms it's possible to customize the outputted markup of a Form, which means you have complete control over what Forms will output.
With Umbraco Forms, it is possible to customize the output markup of a Form, which means you have complete control over what Forms will display.
We recommend using Themes to customize your Forms. This will ensure that nothing is overwritten when you upgrade Forms to a newer version.
The razor macro uses some razor views to output the Form:
1 view for each fieldtype
1 view for the scripts
1 view for the rest of the Form
You can find the default views in the ~\Views\Partials\Forms\Themes\default folder.
To avoid your custom changes to the default views from being overwritten, you need to copy the view you want to customize into your theme folder, e.g. ~\Views\Partials\Forms\Themes\YourTheme, and edit the file in YourTheme folder.
This is the main view responsible for rendering the Form markup.
The view is separated into two parts, one is the actual Form and the other will be shown if the Form is submitted.
This view can be customized, if you do so it will be customized for all your Forms.
This view renders the JavaScript that will take care of the conditional logic, customization won't be needed here.
The rest of the views start with FieldType, like FieldType.Textfield.cshtml and those will output the fields. There is a view for each default fieldtype like textfield, textarea, checkbox, etc)
Contents of the FieldType.Textfield.cshtml view (from the default theme):
Umbraco Forms uses ASP.NET Unobtrusive Validation which is why you see attributes like data-val and data-val-required.
This can be customized but it's important to keep the ID of the control to @Model.Id since that is used to match the value to the Form field. For fields that are conditionally hidden, without an ID of @Model.Id the control won't be shown when the conditions to show the field are met. An ID needs to be added to text controls such as headings and paragraphs.
The view model for the partial view for a field is FieldViewModel. This defines properties that may be useful when creating new themes or custom fields, some of which are shown in the code samples above. Others include:
AdditionalSettings - a dictionary of the settings keys and values populated for the form field. These can be retrieved in typed form by key using e.g. Model.GetSettingValue<int>("MaximumLength", 255);.
The following are available on the model but only populated for fields that support file upload:
AllowAllUploadExtensions- a boolean indicating whether all file extensions are permitted for upload.
AllowedUploadExtensions- a collection of strings indicating the file extensions that are permitted for upload.
AllowMultipleFileUploads- a boolean indicating whether selecting multiple files for upload is allowed.
It is also possible to customize the markup for a specific Form.
You will need to create folder using the ID of the Form: ~\Views\Partials\Forms\{FormId} (find the id of the Form in the URL when you are viewing the Form in the backoffice.)
As an example if your Form ID is 0d3e6b2d-db8a-43e5-8f28-36241d712487 then you can overwrite the Form view by adding the Form.cshtml file to the directory. Start by copying the default one and then making your custom changes: ~\Views\Partials\Forms\0d3e6b2d-db8a-43e5-8f28-36241d712487\Form.cshtml.
You can also overwrite views for one or more fieldtypes by adding the views to the Fieldtypes folder: ~\Views\Partials\Forms\0d3e6b2d-db8a-43e5-8f28-36241d712487\Fieldtypes\Fieldtype.Textfield.cshtml.
How to secure access to Umbraco Forms data and functionality.
Umbraco Forms has a backoffice security model integrated with Umbraco users. Details are managed in the Users section of the backoffice, within a tree named Form Security.
Within the Form Security tree, each user with a backoffice account is listed. Clicking on a user allows each functional permission to be set:
Manage forms - user can create and edit form definitions
View entries - user can view the submitted entries
Edit entries - user can edit the submitted entries
Manage datasources - user can create and edit datasource definitions
Manage prevalue sources - user can create and edit prevalue source definitions
For further control, each form is listed and the user can be granted or denied access to each as appropriate.
As new forms are created, users will automatically be granted access to them, unless the configuration setting DefaultUserAccessToNewForms has been set to a value of Deny.
When form definitions are configured for storage in the database, it allows for the creation of folders to group forms within. It's also possible to define one or more start folders for a user. This is done in order to limit their access to a subset of the forms available.
If no start folders are selected, the user will be able to access all forms in the backoffice according to their permissions.
If a single start folder is selected, that will act as the root of the tree view of forms. The user will have access to all folders and forms below that selected folder.
If more than one start folder is selected, they will appear underneath the root of the tree view of forms. The user will have access to only those folders and their descendant folders and forms.
A new model was introduced allowing for the management of permissions at the level of user groups. Particularly for installations with a large number of users, we expect this to be a more useful setup and require less ongoing administration.
When user groups are involved in permissions, access to a particular resource or feature is determined by the following:
If the user has a specific user permission set, it is used in preference to anything set on the user groups they are a part of.
If the user doesn't have a specific user permission set, they are granted access if at least one of the user groups they are part of has access.
To enable the feature, it's necessary to update the ManageSecurityWithUserGroups configuration setting to true.
With that in place the Form Security tree divides into three sub-trees:
Under Group Permissions, each user group is listed and the same settings as described above for individual users can be set here.
Under User Permissions, each user that has a specific user permission record is listed and can be managed. Records for users can be created or deleted via the tree's action menu.
As new forms are created, user groups with aliases listed in the GrantAccessToNewFormsForUserGroups configuration setting will be automatically given access. For example, with a value of admin,editor, the built-in Administrators and Editors groups would have access.
Start folders are enabled for User Groups. They work in a similar way as the group based permissions described above:
If the user has a specific user permission set, it is used in preference to anything set on the user groups they are a part of.
This means if the user has no start folders defined and the groups they are part of do, they will have access to the root of the Forms tree and be able to access all folders and Forms.
If the user doesn't have a specific user permission set, they are granted access to all the unique folders the groups they are part of have access to.
If they are part of any group that has access to the forms section, permission to manage forms and no start folders defined, they will have access to the root of the Forms tree and be able to access all folders and Forms.
In introducing the user group based permissions, we've taken care to ensure a migration path. This is available for those existing installations running on older versions of Umbraco Forms. In that situation, we'd recommend the following approach.
Upgrade to Umbraco 9.3.
At this stage nothing will have changed in terms of the permissions model in use.
Set the ManageSecurityWithUserGroups configuration value to true and the GrantAccessToNewFormsForUserGroups as appropriate for your setup.
Via the Users > Form Security section, set the required permissions on each user group.
Again at this point nothing will have changed with regard the effective permissions for each user, as they will currently all have an existing user permission record.
Via Users > Form Security > User permissions, delete the permission records for each user.
The effective permissions for each user will now be derived from their user groups.
If you have any exceptions - where a particular user needs a particular combination of permissions that you can't or don't want to provide via the user groups - it's always possible to re-create a user permission record that will take precedence over the group based permissions.
Marking fields and properties as sensitive will hide the data in those fields for backoffice users that are not privy to the data. Built-in features are available to help you secure sensitive information. For more information, see the Sensitive data article.
The following sections covers how to grant or deny access to sensitive data for specific users and how to mark form questions as sensitive.
To allow users to view and handle sensitive data in Umbraco Forms, you must assign them to the Sensitive Data user group:
Navigate to the Users section in the Umbraco Backoffice.
Select the user you want to grant access to.
Click Choose in the Groups field under the Assign access section.
Select Sensitive Data from the list of User Groups.
Click Submit.
Click Save.
Once the users are set up with the appropriate permissions, the next step is to identify which form fields should be marked as sensitive.
Marking a field as sensitive ensures that only authorized users in the Sensitive Data user group can access data from these fields.
To mark questions as sensitive, follow these steps:
Navigate to the Forms section in the Umbraco Backoffice.
Open the form you wish to configure (for example: Contact Form).
Click on the cogwheel icon next to the form field you want to secure.
Enable the Sensitive data setting for the field.
Click Submit.
Click Save.
Umbraco Forms has some magic strings that enable you to render values from various sources, such as session, cookies and Umbraco page fields.
Magic strings can be used in form fields as a label, description or default value. As an example they can be used in default values in hidden fields - normally in the form of referral codes from a session, cookie or request item.
These values can also be used for properties and settings in workflows. This means you can use name and email fields from a form to create a personal 'Thank you' email.
[@SomeRequestItem] this allows you to display an item from the current HttpContext.Request with the key of 'SomeRequestItem'.
Some examples of variables that are normally available in HttpContext.Request:
[@Url]: Insert the current URL
[@Http_Referer]: The previous visited URL (if available)
[@Remote_Addr]: The IP address of the visitor (stored by default by Umbraco)
[@Http_User_Agent]: The browser of the visitor
The variables are not case-sensitive.
You can use it for any available query string variable in the URL as well. If your URL has the query string ?email=foobar@umbraco.com, you can get the value of the query string into your field by using [@email].
For multi-lingual websites, rather than hard-coding labels like form field captions, a dictionary key can be entered as, for example, #MyKey. When the form is rendered, the placeholder will be replaced by the value of the dictionary item identified by the key, according to the current language.
In most cases, the field must contain only the magic string for the replacement to be carried out. This makes sense for translated values, as you will want the whole phrase replaced when, for example, using one for a field's placeholder.
We also translate dictionary keys found within the rich text field, which will be contained within HTML tags. Here we look for dictionary keys making up the full inner text of a tag. So for example, <p>#myKey</p> would be translated, but <p>Lorem ipsum #myKey dolor sit amet.</p> would not.
[%SomeSessionOrCookieItem] this allows you to display an item from the current HttpContext.Session with the key of 'SomeSessionOrCookieItem'. The session key can only contain alphanumeric chars and you cannot use dots for example. [%Member.Firstname] cannot be used, but [%MemberFirstname] can be used. You would have to fill these session keys yourself.
If the item cannot be found in the collection of session keys, it will then try to find the item from the HttpContext.Cookies collection with the same key.
[#myUmbracoField] this allows you to insert a property of that page and is based on the alias of the field. If your page has a property with the alias 'title', you can use [#title] in your form.
Some extra variables are:
[#pageName]: The nodename of the current page
[#pageID]: The node ID of the current page
[$myRecursiveItem] this allows you to parse the Umbraco Document Type property myRecursiveItem. So if the current page does not contain a value for this then it will request it from the parent up until the root or until it finds a value.
{myAliasForFormField} this allows you to display the entered value for that specific field from the form submission. Used in workflows to send an automated email back to the customer based on the email address submitted in the form. The value here needs to be the alias of the field, and not the name of the field.
Some extra variables are:
{record.id}: The ID of the current record - this is only accessible on workflows triggered "on approve" rather than "on submit"
{record.updated}: The updated date/time of the current record
{record.created}: The created date/time of the current record
{record.umbracopageid}: The Umbraco Page ID the form was submitted on
{record.uniqueid}: The unique ID of the current record
{record.ip}: The IP address that was used when the form was submitted
{record.memberkey}: The member key that was used when the form was submitted
{member.FOO} with the prefix of member, the same syntax will allow you to retrieve information about the submission if it was submitted by a logged-in member.
Using a magic string such as in the examples above will output the values exactly as read from the source. From Forms 10.2, it's possible to apply a format string to customize the output.
The syntax follows that of AngularJS filters, i.e. [<magic-string> | <formatFunction>: <arg1>: <arg2>].
For example, to truncate a string value read from an Umbraco page field with alias title, you would use:
Umbraco Forms ships with the following filters:
A service implemented by the IPlaceholderParsingService interface is available for use in custom code or views. It's found in the Umbraco.Forms.Core.Services namespace.
In a controller you can inject it via the constructor and it can also be injected into views via:
The interface implements a single method, ParsePlaceHolders, that can be used for parsing magic strings. There are a few overloads available for use depending on the context.
If parameters for the Record or Form are omitted, magic strings relating to these objects will be removed.
There is also a public extension method ParsePlaceHolders() extending the string object in the Umbraco.Forms.Core.Extensions namespace, again available with some overloads allowing the provision of a Form or Record object if available.
Sometimes you might have a field in your Form, that you want to show only if the user has entered a specific value in another field.
You can achieve this setting by using conditional logic on Fields.
Take a look at the following:
In this case, it makes sense to only show the email or phone field when the corresponding option is selected in the How should we contact you? field.
To enable conditions for the Email and Phone fields, do the following:
Click the cog wheel next to the Email and Phone field. The Edit question dialog opens.
Select Enable Conditions in the Conditions section.
Enabling the condition field displays more options:
Set the appropriate conditions and click Submit.
There are two Action Types:
Show: the field will be displayed if the rules match
Hide: the field will be hidden if the rules match
Next up, you'll need to specify the Logic Type. This setting is only important if you have multiple rules.
All: All of the rules must match
Any: Any of the rules may match
When adding a new condition, you'll need to select the field where you want to evaluate the value and can select an operator.
In this example, we only want to show the Phone field if the value of the How should we contact you field is Phone.
Similarly, you can display the Email field, if the value of the How should we contact you field is Email. You can see the conditions added to each field in the Forms designer:
When both the conditions have been set as shown above, this is how it will look on the frontend:
In this example, we have only selected Phone but it is possible to choose both Phone* and Email and display both the fields.
As well as showing or hiding a field based on conditions, you can also apply conditions to groups of fields (known as fieldsets) or to pages. The process is the same as described above.
When applying a condition to a page, effectively you are controlling the display of the submit button (for a single-page form) or the next/previous buttons (available on multi-page forms). In this way you can ensure that the entry so far is complete before accepting it or allowing the user to move onto the next page.
You can apply conditions to dates as well as strings. When you use the date picker field, you can set a condition if a submitted date is greater/less than a specific date.
There are multiple built-in workflow types that can be used to extend the functionality of your Form.
Used to automatically Approve Record or Delete Record once it is submitted. Configure words that you want to match and select whether these words should trigger an approval or deletion of the record.
Used to post the Form as an XML to a specified URL. The following configuration can be set:
Workflow Name
URL (required)
Method
XsltFile - used to transform the XML
Headers - map the needed files
User
Password
Saves the result of the Form as an XML file by using XSLT. The following configuration can be set:
Workflow Name
Path (required) - where to save the XML file
File extension (required)
XsltFile - used to transform the XML
The path needs to point to a folder, not a file name. The files are then stored locally, and relative paths are resolved to the content root.
When storing the files within the wwwroot or App_Plugins folders, the files will be publicly available by default.
Saves a submitted Form as a new content node. You need to choose a Document type and match the fields in the Form with the properties on the selected Document Type.
You can also choose to set a static value to fill in the properties:
In the example above, a Document Type called Blogpost is selected for creating the new Content node.
The value from the Name field will be added as the Node Name property in the new Content node. The value from the Email field will be used as the Content property.
The following configuration can be set:
Workflow Name
Publish - choose whether to publish the node on submission
Where to save - choose a section in the content tree where this new node should be added
Sends the result of the Form to the specified email address. The following configuration can be set:
Workflow Name
Message (required)
Attachment - specify whether file uploads should be attached to the email
Recipient Email (required)
CC Email
BCC Email
Sender Email
Reply To Email
Subject of the email (required)
If the Sender Email field is not populated, the address used will be read from CMS configuration.
The Content Settings value configured at Umbraco:CMS:Content:Notifications:Email will be used if provided.
If that is not set, the Global Settings value configured at Umbraco:CMS:Global:Smtp will be used.
The fallback behavior also applies to the other email workflows.
Uses a template to send the results of the Form to a specified email address.
You can create your own custom Razor templates to be used to send out emails upon Forms submission. Read more about how to create these templates in the Email Templates article.
The following configuration can be set:
Workflow Name
Email Template (required) - specify which template you want to use
Header text - formatted text that will be rendered above the form entry details
Footer text - formatted text that will be rendered below the form entry details
Attachments - specify whether file uploads should be attached to the email
Recipient Email (required)
CC Email
BCC Email
SenderEmail
Reply To Email
Subject of the email (required)
Sends the Form to a URL either as a HTTP POST or GET. The following configuration can be set:
Workflow Name
URL (required)
Method (required) - POST, GET, PUT or DELETE
Standard Fields - optionally include and map standard form information such as name and page URL
Fields - map the needed fields
User
Password
When mapping fields, if any are selected, only those chosen will be sent in the request to the configured URL. If no fields are mapped, all will be sent.
The receiving endpoint extracts form fields and values using GET for querystrings and POST for form collections.
As an illustrative example, the following code can be used to write the posted form information to a text file:
Sends the result of the Form to an email address with full control over the email contents by providing an xslt file. The following configuration can be set:
Workflow Name
XSLT File - specify which file should be used to transform the content
Recipient Email (required)
CC Email
BCC Email
SenderEmail
Reply To Email
Subject of the email (required)
Allows to post the Form data to a specific channel on Slack. The following configuration can be set:
Workflow Name
Webhook URL (required)
Prevalue sources are a way to pre-define and/or retrieve a list of items from a certain source. They can be added in any field types that include some kind of list like Dropdown and Multiple/Single Choice lists.
Prevalue sources can be managed in the Prevalue sources folder available in the Forms section.
To set a prevalue source:
Navigate to the Forms section.
Right-click the Prevalue sources folder and select Create.
A new page opens in the right-side of the editor where you'll need to setup and configure your prevalue source.
Enter a Name.
Select the type of prevalue source from the Type drop-down. For more information on the different default types, see the Overview of the Prevalue Source Types article.
Depending on the Type you choose, you'll need to provide some additional settings:
Now, provide a file containing the list to use as prevalues. For example: A .txt file containing the following values:
Select Pick File and choose the text file you created.
Once the text file is uploaded, click Save to save the prevalue source.
If the file is successfully uploaded and validated, you will see an overview of the values in a tabular format.
If you would like to have different values presented to your users from the value stored, you can provide two values per line, separated with a vertical bar (|), e.g.:
In this case the user would pick from a list showing the captions, but the single integer values would be stored with the record.
This can be useful if the recorded entries are used in any subsequent workflows or business processes, where particular values, that aren't appropriate for the user to select from, are required.
Sometimes retrieving the list of options for a prevalue source can be an expensive operation. If the source depends on data from external systems, it could be that the list changes regularly or rarely.
Given the variation here, we allow you to select an appropriate level of caching for the list of options.
You can choose between:
No Caching - no caching will be applied and the list of options will be retrieved from source on every request. You will likely only want to choose this option if the information changes frequently and it's important that the latest is presented to website visitors.
Cache For Specified Time - the list will be cached for the period of time provided.
Cache With No Expiry - the list will be cached on first request and not retrieved again until either the prevalue source is edited or the website is restarted. This is most appropriate to use for information held within the prevalue source data itself (such as when uploading a text file).
Once a prevalue source has been created, it can be used while building Forms in the Forms designer.
Example: Let's add a Multiple Choice field type in our Form.
If there is at least one prevalue source defined in the project, the Prevalues source will contain a dropdown from where you can choose the predefined value.
Once you have selected the prevalue source, the values are rendered in the Forms designer from the attached source.
In this article, you can learn how to add extra functionality to your Form by attaching workflows.
Workflows are a way of defining actions after your Form is submitted like sending an email or creating a content node.
By default, when a Form is submitted the record data is stored in the database. This can be configured in the Store records of the Forms settings.
The behavior to display a message to the user who submitted the form can be configured by clicking on the built-in first workflow step. This step is labelled Submit message/Go to page, and it can also configure the redirection to another page.
If a value is selected for Go to page, it will be used to redirect to that page once the form has been submitted.
If no value is selected, the message in Message on submit is displayed to the user on the same page, instead of the form fields. This is implemented via a redirect to the current page, ensuring that the form can't be accidentally resubmitted.
By default, the message is created and rendered in plain text. If you need to add formatting to the message, toggle the Format message in rich text button.
At the bottom of your Form, a default workflow is already attached to the Form, as well as an option to configure the workflows.
Clicking Configure workflow will give you the option to configure existing workflows, as well as setup new ones.
A new workflow can be of different types and Umbraco Forms ships with a few default ones. You can find an overview of the types in the Workflow types article.
Once the Workflow Type has been selected, you will need to configure the workflow. There are different settings depending on the type that has been selected.
To use data from the submitted Form in your workflow, head over to the Magic Strings article and learn more about how that's done.
You can apply conditions to a workflow to ensure it only triggers under specific circumstances. You could as an example enable a condition that enables sending an email only if an email is added.
Select Enable conditions to open the condition editor. In the condition editor, you will see options to create logic that determines when the workflow should run. The condition is generally based on the values of the form fields.
For example: You have a form with a dropdown field labeled Preferred Contact Method with options such as Email and Phone. You can set up a workflow that sends an email notification only when the user selects Email.
Now, this email notification will only be sent when the user selects Email as their preferred contact method.
Fill in the rest of the settings and click Submit. The workflow is added to your Form and displayed at the bottom of the page.
When a form is submitted, any workflows associated with the "submit" stage of the form will run sequentially in the configured order. The record is stored after these workflows are completed, and as such they can make changes to the information recorded.
Similarly, approval of a form entry, whether automatic or manual, will trigger the execution of the workflows associated with the "approve" stage.
If a workflow encounters an unexpected error, it will silently fail from the perspective of the user submitting the form. The exception along with the other details of the failed operation is recorded to the log.
From Umbraco Forms versions 8.13.0 and 10.1, an audit trail has been made available. In the list of entries for a form, a summary is presented that shows how many workflows were executed, and how many were successful:
For each entry, in the backoffice a table can be viewed that shows each of the workflows and the success, or otherwise, of the operation.
For any workflows that did not complete successfully, a "Retry" link is available to trigger the workflow again. This is useful for example if there was a temporary infrastructure issue that perhaps prevented an email going out. You would be able to retrigger the workflow once the issue is resolved.
Umbraco Forms comes with many default Field Types, also known as Answer Types. You can choose from these options when adding new fields to your Forms.
By default, the following Field Types are available:
Short Answer: A textbox allows up to 250 characters.
Long Answer: A bigger text field that allows multiline text and more than 250 characters.
Date: Displays a picker that allows the user to select a date.
Checkbox: Displays a single checkbox that can be checked or not.
File Upload: Allows user to select and upload a local file.
Password: Allows to type a password. The input is not visible when typing.
Multiple Choice: Displays a list of items with a checkbox for each item where the user can select multiple options.
Data Consent: A field for the purpose of asking for data consent. By default, this field is added to all new forms created with Forms version 6+.
Dropdown: Displays a list of items in a drop down box where the user can select a single option.
Single Choice: Displays a list of items with a radio button for each item where the user can select a single option.
Title and Description: Displays a read-only title and description for a set of form fields.
Rich Text: Displays read-only formatted text that can be used to provide additional information and links within a form.
Hidden: A hidden field allows developers to include data that cannot be seen or modified by users when a Form is submitted.
Recaptcha V2: The field displays a single checkbox for the user to select in order to validate the Form.
Recaptcha V3 with Score: This field returns a score for each request without user interaction. The score is based on user interactions with the site and enables you to take an appropriate action for your site based on the score.
There are some default prevalue source types that can be used.
Here is a quick overview of them:
Get values from textfile
Upload a textfile that contains the prevalues. Each prevalue should have its own line in the file. Once the file has been uploaded, you can find it in ~/wwwroot/App_Data/UmbracoForms/Data/PreValueTextFiles/{GUID} where the {GUID}is replaced with the pre-value ID.
Umbraco Documents
Allows to use content nodes from a specific source as prevalues. You can define the root node by either
Choosing a node directly from the Content tree or
Using XPath
Additional settings can be applied:
Select Use current page as root instead of choosing a specific root node. The preview is not available when this setting is enabled.
Select a specific Document type, if the selected root node contains a different Document Type.
Select to include Grand children of the selected root node.
SQL Database
Connect to a OleDB compatible database table and construct a prevalue source from it. Once selected, it will be editable from the Forms interface.
The following configurations need to be set:
Connection string (either choose one from your web.config or add another from a textfield)
Connection String from configuration
Table Name
Key Column
Value Column
Umbraco Data Type Prevalues
Choose an Umbraco Data Type to use its configured prevalue collection.
In the example below, the prevalue collection from a Data Type called Home - Font - Radio button is used:
See an example of validating a form server-side
Add a new class to your project as a handler for the FormValidateNotification notification:
The handler will check the ModelState and Form field values provided in the notification. If validation fails, we add a ModelError.
To register the handler, add the following code into the startup pipeline. In this example, the registration is implemented as an extension method to IUmbracoBuilder and should be called from Startup.cs:
The services available via interfaces IFormService, IFolderService, IDataSourceService and IPrevalueSourceService trigger following notifications before or after an entity handled by the service is modified.
The "-ing" events allow for the entity being changed to be modified before the operation takes place, or to cancel the operation. The "-ed" events fire after the update is complete.
Both can be wired up using a composer and component:
When a form or folder is moved there is no specific service event. However, information available in the State dictionary on the notification object can be used to determine whether the item was moved. If so, it can show where it was moved from:
If a folder is being moved, the key within the State dictionary is "MovedFromParentId".
When an entry for a form is rendered in the backoffice, an event is available to allow modification of the record detail. This event is available before the record details are presented to the user. This is shown in the following example:
Customize the regular expression based validation patterns available for text fields.
When creating a text field in Umbraco Forms, a validation pattern in the form of a regular expression can be applied. Default patterns can be removed or re-ordered, and custom ones created and added.
Umbraco Forms ships with three patterns: number, email, and URL. The class names are Number, Email, and Url respectively, and all are found in the Umbraco.Forms.Core.Providers.ValidationPatterns namespace.
To create a custom format function, create a class that implements IValidationPattern. You will need to initialize five properties:
Alias - an alias that should be unique across the patterns and is typically camel-cased with no spaces.
Name - the name of the pattern that will be visible in the backoffice.
LabelKey - as an alternative to providing a name, a translation key can be provided. This will be used to look-up the name in the correct language for the backoffice user.
Pattern - the regular expression pattern.
ReadOnly - a flag indicating whether the pattern can be edited in the backoffice.
The following example shows the implementation of a pattern for a United Kingdom postcode (credit for the to at StackOverflow).
As with other provider types, the validation pattern needs to be registered. There are options to add, remove, and re-order patterns.
An example registration using the IUmbracoBuilder is shown below:
With the pattern registered it will be available for selection by editors in the backoffice when they create validation for fields supporting this feature.
The labels, descriptions, and buttons that make up the backoffice screens for Umbraco Forms can be translated into different languages.
When an editor chooses a language for their account, Umbraco CMS will render appropriate translations. The translations will contain a file for that language and a key for the label in question. If either of these can't be found, the label will be displayed in English (US).
Umbraco Forms ships with translations for the following languages:
Czech (cs-cz.xml)
Danish (da-dk.xml)
Spanish (es-es.xml)
French (fr-fr.xml)
Italian (it-it.xml)
Polish (pl-pl.xml)
UK English (en-gb.xml)
US English (en-us.xml)
If the language you require does not exist, it's possible to create your own by duplicating the default en-us.xml file. You can then save it with the appropriate culture code for the language you need and replace the English text with the translated version.
As of Forms 10, the file no longer exists on disk and is shipped as part of the Umbraco.Forms.StaticAssets NuGet package. You can open this package, either locally using , or by clicking the "Open in NuGet Package Explorer" link. You'll find the file at staticwebassets/Lang/en-us.xml.
Once translated, the new file should be saved into the App_Plugins/UmbracoForms/app/lang/ folder.
In this article, you will find information about Umbraco Forms-related health checks that can be run from the Umbraco backoffice to ensure that your installation is running seamlessly.
Read the article to learn more about the feature in general.
Running this health check will verify whether the database tables for the Umbraco Forms installation are all set up correctly with the proper data integrity checks.
In this section, you can learn more about the background for adding this check, as well as how to use and understand the results.
With version 8.7, a health check was introduced to confirm the Umbraco Forms database tables are all set up with the expected data integrity checks - i.e. primary keys, foreign keys and unique constraints.
In most cases, you can expect them all to be in place without any developer intervention. For new installs, the database schema is initialized with all the necessary integrity constraints. And for upgrades, any new schema changes are automatically applied.
There remains the possibility though that not all will be in place for a particular installation. For example, this could happen if a constraint is added in a new version. It can't be added via an automated migration due to existing data integrity issues.
In particular, prior to version 8.7, there were a number of tables that weren't defined as strictly as they should be in this area. So we've added some primary key, foreign key and unique constraints with this version. If you've been running a version prior to this and are upgrading, these schema updates will be applied automatically unless there is existing data in the tables that prevent them from being added.
There shouldn't be - but without these constraints in place it's always possible for an application bug to exist that allows for example the creation of duplicate records, or the orphaning of records, that aren't correct. This is the reason for the constraints to exist, and why we want to ensure they are in place.
To run the health check:
Navigate to the Health Check dashboard in the Settings section in the Umbraco backoffice.
Click on the Forms button and select Check Group. You'll see a result that looks something like this:
If you have a full set of green ticks, then you're all good - and no need to read on!
If you have one or more red crosses though, that means a particular constraint wasn't able to be applied via the automatic schema migrations when you installed a new version of Umbraco Forms, due to existing data issues.
It isn't essential that they are resolved - the package can and does function correctly without them - but for reasons of ensuring data integrity and performance, it is recommended that they are.
When Umbraco Forms installs an upgrade, it will attempt to apply any schema changes. If though, the update isn't essential, and it can't proceed due to existing data integrity issues, the failed update will be logged and then the rest of the migration will continue.
As well as in the log files, such issues will be visible via the health check and will need to be resolved by applying scripts directly to the database.
To support this, we provide the following SQL scripts:
The first of these provides the SQL statements required to apply the schema updates for 8.7.0+ to the common Umbraco Forms tables. The second applies to those tables used for when Forms are stored in the database, and hence only need to be applied if that option is configured.
Before running any scripts or queries, please be sure to have a database backup in place.
To take an example, let's say that via the health check results you can see that the "Unique constraint on table 'UFForms', column 'Key' is missing."
If you look in the SQL script you'll see that in order to apply this directly to the database, you would need to run the following SQL statement:
If you run it though, you'll see the reason why the migration that ran when Umbraco Forms was upgraded couldn't apply the change:
The constraint can't be applied if there are existing duplicate values, so first they need to be found and removed.
To find duplicate values in the 'Key' field in this table you can run the following SQL statement:
Running the statement above will list out the 'Key' fields that are duplicated in the table.
To see the full details of the duplicate records, you can use this query:
From the Id field you can identify the Form records that are duplicated and should be removed, and delete the records. To check you have found them all, run one of the above queries again, and confirm you find no records returned.
Finally you can run the ALTER TABLE... statement shown above to apply the constraint, and confirm via the health check that it's now in place.
By repeating similar steps as required, you'll be able to ensure that all recommended keys, constraints and indexes are in place.
If for any reason you wish to revert the changes - perhaps when testing these updates in a non-production environment - reversion scripts for all the 8.7 updates are also provided:
To support this, we provide the following SQL scripts:
In Umbraco Forms it's possible to customize the functionality with various configuration values.
With Umbraco Forms it's possible to customize the functionality with various configuration values.
All configuration for Umbraco Forms is held in the appSettings.json file found at the root of your Umbraco website. If the configuration has been customized to use another source, then the same keys and values discussed in this article can be applied there.
The convention for Umbraco configuration is to have package based options stored as a child structure below the Umbraco element, and as a sibling of CMS. Forms configuration follows this pattern, i.e.:
All configuration for Forms is optional. In other words, all values have defaults that will be applied if no configuration is available for a particular key.
For illustration purposes, the following structure represents the full set of options for configuration of Forms, along with the default values. This will help when you need to provide a different setting to understand where it should be applied.
This configuration value expects a true or false value and can be used to disable the feature where all new forms are provided with a default "Consent for storing submitted data" field on creation. Defaults to false.
This configuration value expects a true or false value and can be used to toggle if new forms that are created adds an email workflow to send the result of the form to the current user who created the form. Defaults to false.
This setting controls the maximum number of columns that can be created by editors when they configure groups within a form. The default value used if the setting value is not provided is 12.
This setting allows you to configure the name of the theme to use when an editor has not specifically selected one for a form. If empty or missing, the default value of "default" is used. If a custom default theme is configured, it will be used for rendering forms where the requested file exists, and where not, will fall back to the out of the box default theme.
When creating an empty form, a single workflow is added that will send an email to the current user's address. By default, the template shipped with Umbraco Forms is available at Forms/Emails/Example-Template.cshtml is used.
If you have created a custom template and would like to use that as the default instead, you can set the path here using this configuration setting.
From Forms 10.2, the provided template can be removed from the selection if you have created email templates for the "send Razor email" workflow. To do this, set this value to true.
Similarly, from Forms 10.2, the provided form templates available from the form creation dialog can be removed from selection. To do this, set this configuration value to true.
For example, providing a value of "f_" will apply a prefix of "f_" to each fieldset and field id attribute.
Forms 10.2 introduced the ability to configure settings for the field, workflow, data source, and prevalue sources. The default behavior, when a new field or workflow is added to a form, is for each setting to be empty. The values are then completed by the editor. All settings defined on the type are displayed for entry.
In some situations, you may want to hide certain settings from entry, so they always take an empty value. In others, you may want to provide a default value that the editor can accept or amend. And lastly, you may have a requirement for a fixed, non-empty value, that's enforced by the organization and not editable. Each of these scenarios can be supported by this configuration setting.
It consists of four dictionaries, one for each type:
DataSourceTypes
FieldTypes
PrevalueSourceTypes
WorkflowTypes
Each dictionary can be identified using the GUID or alias of the type as the key. The value is set to the following structure that contains three settings:
IsHidden - if provided and set to true the setting will be hidden and will always have an empty value.
DefaultValue - if provided the value will be pre-filled when a type using it is created.
IsReadOnly - used in conjunction with the above, if set the field won't be editable and hence whatever is set as the DefaultValue won't be able to be changed. If set to false (or omitted) the editor can change the value from the default.
In this example, the sender address field on a workflow for sending emails can be hidden, such that the system configured value is always used:
Here an organization-approved reCAPTCHA score threshold is defined, that can't be changed by editors:
Take care to not hide any settings that are required for the particular field or workflow type (for example, the Subject field for email workflows). If you do that, the item will fail validation when an editor tries to create it.
The default value and read-only settings apply to most setting types. There is an exception for complex ones where a default string value isn't appropriate. An example of one of these is the field mapper used in the "Send to URL" workflow.
The following configured values are applied to all forms as they are created. They can then be amended on a per-form basis via the Umbraco backoffice.
Once the form has been created, the values are set explicitly on the form, so subsequent changes to the defaults in configuration won't change the settings used on existing forms.
This setting needs to be a true or false value and will allow you to toggle if a form allows submissions to be post moderated. Most use cases are for publicly shown entries such as blog post comments or submissions for a social campaign. Defaults to false.
This setting needs to be a true or false value and will allow you to toggle if the form will include some default styling with the Umbraco Forms CSS stylesheet. Defaults to false.
This setting can have the following values to allow you to toggle the mode of marking mandatory or optional fields:
NoIndicator (default)
MarkMandatoryFields
MarkOptionalFields
This setting is used to mark the mandatory or optional fields based on the setting above. By default this is an asterisk *.
This allows you to configure the required error validation message. By default this is Please provide a value for {0} where the {0} is used to replace the name of the field that is required.
This allows you to configure the invalid error validation message. By default this is Please provide a valid value for {0} where the {0} is used to replace the name of the field that is invalid.
This setting needs to be a true or false value and will allow you to toggle if the form will display all form validation error messages in a validation summary together. Defaults to false.
This setting needs to be a true or false value and will allow you to toggle if the form will show inline validation error messages next to the form field that is invalid. Defaults to false.
These settings configure the default next, previous, and submit button labels. By default, these are Next, Previous, and Submit respectively. These labels can be amended on a form-by-form basis via the form's Settings section.
This allows you to configure what text is displayed when a form is submitted and is not being redirected to a different content node. Defaults to Thank you.
This setting needs to be a True or False value and will allow you to toggle if form submission data should be stored in the Umbraco Forms database tables. By default this is set to True.
This setting provides a value to be used for the autocomplete attribute for newly created forms. By default the value is empty, but can be set to on or off to have that value applied as the attribute value used when rendering the form.
Introduced in 10.2, this setting controls the initial value of the number of days to retain form submission records for newly created forms. By default the value is 0, which means records will not be deleted at any time and are retained forever.
If set to a positive number, a date value calculated by taking away the number of days configured from the current date is found. Records in the 'submitted' state, that are older than this date, will be flagged for removal.
Applies as per DaysToRetainSubmittedRecordsFor but for records in the 'approved' state.
This configuration expects a True or False string value, or a comma-separated list of form names, and allows you to toggle if a form submission is edited again, that the workflows on the form will re-fire after an update to the form submission. This is used in conjunction with the AllowEditableFormSubmissions configuration value. Defaults to True.
This configuration key is experimental and will allow Workflows to be executed in an asynchronous manner. The value can be a True or False string value, or a comma-separated list of form names. Defaults to False.
This configuration value expects a true or false value and can be used to toggle the functionality to allow a form submission to be editable and re-submitted. When the value is set to true it allows Form Submissions to be edited using the following querystring for the page containing the form on the site. ?recordId=GUID Replace GUID with the GUID of the form submission. Defaults to false.
There was a typo in this setting where it had been named as AllowEditableFormSubmissions. This is the name that needs to be used in configuration for Forms 9. In Forms 10 this was be corrected to the now documented value of AllowEditableFormSubmissions.
Enable this feature ONLY if you understand the security implications.
When redirecting following a form submission, a TempData value is set that is used to ensure the submission message is displayed rather than the form itself. In certain situations, such as hosting pages with forms in IFRAMEs from other websites, this value is not persisted between requests.
By setting the following value to True, a querystring value of formSubmitted=<id of submitted form>, will be used to indicate a form submitted on the previous request.
This setting has been added in 9.5 and 10.1, to help resolve an issue with multi-lingual setups.
When Umbraco Forms stores data for a record, it saves the values submitted for each field into a dedicated table for each type (string, date etc.). It also saves a second copy of the record in a JSON structure which is more suitable for fast look-up and display in the backoffice. Date values are serialized using the culture used by the front-end website when the form entry is stored.
When displaying the data in the backoffice, the date value needs to be parsed back into an actual date object for formatting. And this can cause a problem if the backoffice user is using a different language, and hence culture setting, than that used when the value was stored.
From 9.5 and 10.1 onwards, the culture used when storing the form entry is recorded, thus we can ensure the correct value is used when parsing the date. However, this doesn't help for historically stored records. To at least partially mitigate the problem, when you have editors using different languages to a single language presented on the website front-end, you can set this value to match the culture code used on the website. This ensures the date fields in the backoffice are correctly presented.
Taking an example of a website globalization culture code setting of "en-US" (and a date format of m/d/y), but an editor uses "en-GB" (which formats dates as of d/m/y). By setting the value of this configuration key to "en-US", you can ensure that the culture when parsing dates for presentation in the backoffice will match that used when the value was stored.
If no value is set, and no culture value was stored alongside the form entry, the culture based on the language associated with the current backoffice user will be used.
This configuration setting provides control over the client-side event used to trigger conditions. The change event is the default used if this setting is empty. It can also be set to a value of input. The main difference seen here relates to text fields, with the "input" event firing on each key press, and the "change" only when the field loses focus.
Scheduled deletion of records older than a specified number of days was a feature introduced in Forms 10.2. It uses a background task to run the cleanup operation, which can be customized with the following settings.
By default this value is false and no data will be removed. Even if forms are configured to have submitted data cleaned up, no records will be deleted. A note will be displayed in the backoffice indicating this status.
Set to true to enabled the background task.
This will configure when the record deletion process will run for the first time. If the value is not configured the health checks will run after a short delay following the website start. The value is specified as a string in crontab format. For example, a value of "* 4 * * *" will first run the operation at 4 a.m.
Defines how often the record deletion process will run. The default value is 1.00:00:00 which is equivalent to once every 24 hours. Shorter or longer periods can be set using different datetime strings.
Set this value to true to disable the default behavior of indexing the form submissions into the Examine index.
If indexing has already occurred, you will still need to manually remove the files (found in App_Data\TEMP\ExamineIndexes\UmbracoFormsRecords). They will be recreated if indexing is subsequently re-enabled.
Set this value to true to enable the Forms API supporting headless and AJAX forms.
The user's IP address is recorded by default when a form is submitted and stored in the UFRecords database table.
To remove this behavior set this value to false.
In Forms 10.5 amends were made to the default theme for Forms that improved accessibility. Specifically we provide the option to use alternative markup for rendering checkbox and radio button lists. These use the more semantically correct fieldset and legend elements, instead of the previously used div and label.
Although this semantic markup is preferred, it could be a presentational breaking change for those styling the default theme. As such we have made this markup improvement optional. You can opt into using it by setting this configuration value to true.
In Umbraco 13 this configuration option will be removed and the semantic rendering made the only option.
Forms will by default track relations between forms and the content pages they are used on. This allows editors to see where forms are being used in their Umbraco website.
If you would like to disable this feature, you can set the value of this setting to false.
By default, TempData is used as the storage mechanism for this tracking.
This can cause some issues when applying a Content Delivery Network (CDN) to your website, and as such an alternative is available using HttpContext.Items.
To switch to this storage mechanism change the value of this setting from the default of TempData to HttpContextItems.
We expect HttpContextItems to be the default option from Forms 14 onwards.
When using the File Upload field in a form, editors can choose which file extensions they want to accept. When an image is expected, they can for example specify that only .jpg or .png files are uploaded.
There are certain file extensions that in almost all cases should never be allowed, which are held in this configuration value. This means that even if an editor has selected to allow all files, any files that match the extensions listed here will be blocked.
By default, .NET related code files like .config and .aspx are included in this deny list. You can add or - if you are sure - remove values from this list to meet your needs.
This setting needs to be a true or false value and will enable the ASP.NET Anti Forgery Token and we recommend that you enable this option. Defaults to true.
In certain circumstances, including hosting pages with forms in IFRAMEs from other websites, this may need to be set to false.
This setting needs to be a true or false value and controls whether password fields provided in forms will be saved to the database. Defaults to false.
In Umbraco Forms 9.2.0, protection was added to uploaded files to prevent users from accessing them if they aren't logged into the backoffice and have permission to manage the form for which the file was submitted. As a policy of being "secure by default", the out of the box behavior is that this access protection is in place.
If for any reason you need to revert to the previous behavior, or have other reasons where you want to permit unauthenticated users from accessing the files, you can turn off this protection by setting this configuration value to true.
In Umbraco Forms 9.3.0, this setting was added to add control over access to new forms. The default behavior is for all users to be granted access to newly created forms. To amend that to deny access, the setting can be updated to a value of Deny. A value of Grant or configuration with the setting absent preserves the default behavior.
Umbraco Forms 9.3.0 introduced the ability to administer access to Umbraco Forms using Umbraco's user groups. This can be used instead or in addition to the legacy administration which is at the level of the individual user. Set this option to true to enable the user group permission management functionality.
Also introduced in Umbraco Forms 9.3.0, this setting takes a comma-separated list of user group aliases which will be granted access automatically to newly created forms. This setting only takes effect when ManageSecurityWithUserGroups is set to true.
There are two "special" values that can be applied within or instead of the comma-separated list.
A value of all will give access to the form to all user groups.
A value of form-creator will give access to all the user groups that the user who created the form is part of.
Available from Forms 10.2.1, the FormsApiKey configuration setting can be used to secure the Forms Headless API in server-to-server integrations. When set, API calls will be rejected unless the value of this setting is provided in an HTTP header.
Setting the value of EnableAntiForgeryTokenForFormsApi to false will disable the anti-forgery protection for the Forms Headless/AJAX API. You need to do this for server-to-server integrations where it's not possible to provide a valid anti-forgery token in the request.
This setting is used to configure the Date Picker form field range of years that is available in the date picker. By default this is a small range of 10 years.
Google has renamed these recently and the Site Key refers to RecaptchaPublicKey and Secret Key is to be used for RecaptchaPrivateKey
Both of these configuration values are needed in order to use the "reCAPTCHA V3 with Score" field type implementing ReCaptcha V3 from Google.
This setting defines the domain from which the client-side assets for using the reCAPTCHA service are requested.
Sets the Data Type Guid to use to obtain the configuration for the rich text field type. If the setting is absent, the value of the default rich text Data Type created by Umbraco on a new install is used.
When using the "title and description" field type, editors can provide HTML in the "description" field and have that rendered on the website.
As a tightened security measure, you can set this value to false which will ensure HTML is no longer rendered.
As some installations may be relying on HTML rendering, to preserve backward compatible behavior the default value of this setting is true.
We expect to make the default value of this option false from Forms 14 onwards.
How to amend the built-in behavior of adding fields and associating workflows with new forms
By default, a single workflow is added when a new form is created. This workflow will send a copy of the form to the email address of the current backoffice user.
A single "data consent" field will also be added unless it has been disabled via configuration.
It's possible to amend this behavior and change it to fit your needs.
Two interfaces are used to abstract the logic for setting default fields and workflows for a form. They are IApplyDefaultFieldsBehavior and IApplyDefaultWorkflowsBehavior respectively.
The default behaviors are defined using built-in, internal classes that implement this interface.
You can create your own implementation of these interfaces.
An illustrative example, adding a custom workflow that writes to the log, is shown below.
Firstly, the custom workflow:
Secondly, the custom implementation of IApplyDefaultWorkflowsBehavior:
Finally, to register the custom implementation in place of the default one:
When adding a default workflow in code, it's possible to make it mandatory, which will prevent editors from removing it from a form.
You can see this in the example above, where the IsMandatory property of the created FormWorkflowWithTypeSettings instance is set to true.
The following class shows the default implementation provided with Forms. You can copy this and customize it to your needs.
Again, you will need to register your custom class, for example, in a composer with:
can be configured to appear alongside forms in the Umbraco Forms backoffice section.
They will appear after the default "Design" and "Settings" apps when editing a form in the backoffice:
A content app such as the following would display only in the forms section:
Within the /App_Plugins/TestFormsContentApp/ folder we need the client-side files, for which an example is shown below:
package.manifest:
testformscontentapp.html:
testformscontentapp.controller.js:
Finally, it needs to be registered via a composer:
Umbraco Forms provides an API for client-side rendering and submission of forms. This will be useful when you want to handle forms in a headless style scenario.
The Forms API is disabled by default. To enable it, set the Umbraco:Forms:Options:EnableFormsApi configuration key to true.
For example:
The API supports two endpoints, one for rendering a form and one for submitting it.
As well as this documentation, the definition of the API can also be reviewed via the Swagger UI, available at the following path: /umbraco/forms/api/swagger/index.html.
The Open API specification is available from: /umbraco/forms/api/openapi.json
To request the definition of a form, the following request can be made:
The GET request requires the Guid identifying the form.
A culture parameter can also be provided, expected as an ISO code identifying a language used in the Umbraco installation (for example, en-US). This will be used to ensure the correct translation for dictionary keys is used. It will also retrieve page content from the appropriate language variant. If the parameter is not provided in the request, the default Umbraco language will be used.
If the requested form is not found, a 404 status code will be returned.
A successful request will return a 200 status code. An example response is as follows. It will differ depending on the pages, fields and other settings available for the form.
To submit a form entry, the following request can be made:
The POST request requires the Guid identifying the form.
It also requires a Content-Type header of application/json and accepts a body as per this example:
The values collection consists of a set of name/value pairs, where the name is the alias of a form field. The value is the value of the submitted field, which can either be a string, or an array of strings. In this way we support fields that accept multiple values, such as checkbox lists.
The contentId and culture parameters are optional. If provided they will be used to customize the response for the current page and language respectively.
In the case of a validation error, a 422 "Unprocessable Entity" status code will be returned, along with a response similar to the following:
A successful response will return a 202 "Accepted" status code.
When posting forms in the traditional way, via a full page post back, an anti-forgery token is generated and validated. This provides protection against Cross-Site Request Forgery (CSRF) attacks.
The same protection is available for forms submitted via AJAX techniques.
In order to generate the token and provide it in the form post, the following code can be applied to the .cshtml template:
When posting the form, the header value generated can be provided, where it will be validated server-side before accepting the request.
The antiforgery token security approach is valid when building a client-side integration with API calls made from the browser.
Providing the token isn't possible though in other headless situations such as server-to-server requests. In these situations, an alternative approach to securing the API is available.
Firstly, with server-to-server integrations you will want to disable the antiforgery token protection.
This is done by setting the Umbraco:Forms:Security:EnableAntiForgeryTokenForFormsApi configuration key to a value of false.
You should then configure an API key Umbraco:Forms:Security:FormsApiKey. The string value can be anything, but it should not be susceptible to a brute force attack.
With this in place any request to the Forms API will be rejected unless the configured value is provided in an HTTP header named Api-Key.
Examples demonstrating how to handle a file upload and use reCAPTCHA fields are included.
Umbraco Forms contains a built-in Get value from textfile that stores the uploaded text file into the physical file system (by default in umbraco\Data\UmbracoForms\PreValueTextFiles).
You can replace the default implementation by writing your own IPreValueTextFileStorage and registering that using e.g. builder.Services.AddUnique<IPreValueTextFileStorage, CustomPreValueTextFileStorage>() (in Startup.cs or a composer).
You can also use/inherit from PreValueTextFileSystemStorage to change the underlying IFileSystem that's used to store the prevalue text files.
You can use the following composer to move the prevalue text files into the media file system. If the media file system is using Azure Blob Storage, this will remove the files from the local physical file system.
You need to manually move the existing files from umbraco\Data\UmbracoForms\PreValueTextFiles to your media storage. The final file path/URL will look like ~/media/PreValueTextFiles/{GUID}/{filename.txt} and be accessible from the browser.
Next, add the following composer that adds the Forms storage container and stores the prevalue text files into Azure Blob Storage (in forms/PreValueTextFiles/{GUID}/{filename.txt}):
You need to manually move the existing files from umbraco\Data\UmbracoForms\PreValueTextFiles to your storage container. If you've disabled public access, the stored files are not accessible from the browser.
The format strings used for formatting dates and numbers are the standard or custom .NET and format strings respectively.
Further magic string format functions can be for use in forms.
In this walk-through, we will select Get values from textfile from the Type drop-down.
Apply database integrity schema changes for 8.7.0+ -
Apply database integrity schema changes for 8.7.0+ (Forms in database tables) -
Revert database integrity schema changes for 8.7.0+ -
Revert database integrity schema changes for 8.7.0+ (Forms in database tables) -
By default the value of HTML id attribute rendered for fieldsets and fields using the default theme is the GUID associated with the form element. Although , some browsers, particularly Safari, may report issues with this if the identifier begins with a number. To avoid such issues, from Forms 10.2, the attribute values can be prefixed with the value provided in this configuration element.
In order to configure this setting, you will need to know the GUID or alias for the type and the property name for each setting. You can find .
If recording IPs and your site is behind a proxy, load balancer or CDN, we recommend using to ensure the correct value for the client IP is resolved.
Forms tracks the forms rendered on a page in order that the associated scripts can be placed in a different location within the HTML. Usually this is used to ) at the bottom of the page.
For more information, see the article.
Both of these configuration values are needed in order to use the "Recaptcha2" field type implementing legacy ReCaptcha V2 from Google. You can obtain both of these values after signing up to create a ReCaptcha key here -
You can obtain both of these values after signing up to create a ReCaptcha key here: .
Valid options are Google (the default) or Recaptcha. You may want to use the latter for control of which domains are setting cookies on your site. .
An optional contentId parameter can be provided, which can either be the integer or GUID identifier for the current page. If provided, the content item identified will be used for Forms features requiring information from the page the form is hosted on. This includes the parsing of .
For an illustrative example showing how a form can be rendered, validated and submitted using the API and vanilla JavaScript, please .
First, install and configure the Forms storage container, for example by adding the following to your appsettings.json:
Bound a number
bound
min and max bound
[#field | bound: 1: 10]
Convert string to lower case
lower
[#field | lower]
Convert string to upper case
upper
[#field | upper]
Truncate a string
truncate
number of characters
[#field | truncate: 10]
Format a number
number
format string
[#field | number: #0.##%]
Format a number as a currency
currency
[#field | currency]
Format a date
date
format string
[#field | date: dd-MM-yyyy HH:mm]
HTML encode a string
html
[#field | html]
Umbraco Forms comes with a number of Field Types to allow you to request certain data in the forms that you design & build. This documentation is to guide specific details about field types that we ship that require some detail in how they work.
The date picker uses a front-end library called PikaDay.js to display a UI to pick dates from. We have added the support for the Pikaday date picker to be localized based on the page the form is rendered on. This displays the picked date in the correct locale. In JavaScript, we update a hidden field with a standard date format. This is done to send the date to the server, ensuring the record submission is stored in a standard format. This is to avoid locale mixing up dates.
To achieve this a new Razor partial view is included /Views/Partials/Forms/DatePicker.cshtml. Once on a page with a form that includes a Date Picker, it also includes the MomentJS library to assist with date locale formatting. Additionally, there are appropriate changes to Pikaday.js to support the locales. If you wish to use a different DatePicker component this is the file that you would customize to your needs.
The DatePicker has one configuration setting to control the number of year shown. The default is 10 years which makes the picker unusable for picking birth dates.
Go to your appsettings.json and add:
You can then change the DatePickerYearRange to a higher number (for example 100).
When working with the Block List editor, the editor experience is enhanced by defining a label for the appearance of the Block.
These labels can contain AngularJS filters.
From Forms 10.2, a filter umbFormsFormName is available for use.
If you add a reference to a property containing a form to the block's label, it will render with the form's Id.
For example, assuming a property containing a picked form with an alias of contactForm:
By using the filter as follows, the form's name will be displayed instead.
In Umbraco Forms, reCAPTCHA V2 comes out of the box to help you to protect your site from spam, malicious people, and so on.
Follow these steps to enable reCAPTCHA V2 in Umbraco Forms:
Go to the Forms section in the backoffice.
Find the form that should have ReCAPTCHA v2 enabled.
Add a new question and select ReCAPTCHA v2 as its answer type.
Make sure the field is set as Mandatory.
Configure ReCAPTCHA settings in the appSettings.json file to include public and private keys:
You can create your keys by logging into your reCAPTCHA account.
In Umbraco Forms, reCAPTCHA V3 comes out of the box.
reCAPTCHA v3 allows you to verify if an interaction is legitimate without any user interaction.
Follow these steps to enable reCAPTCHA V3 in Umbraco Forms:
Go to the Forms section in the backoffice.
Find the form that should have ReCAPTCHA v3 enabled.
Add a new question and select ReCAPTCHA v3 with Score as its answer type.
Make sure the field is set as Mandatory.
Configure ReCAPTCHA settings in the appSettings.json file to include public and private keys:
You can create your keys by logging into your reCAPTCHA account.
Expand the Form in the tree to view the Entries for each Form.
When accessing the Entries viewer, you will be able to see all the entries submitted via the Form.
By default, the list is filtered to show entries only from the past month. If you want to change the date range, pick the appropriate time period from the date picker. You can also filter the entries by specific words using the Search field on the left.
Clicking on the first field for each record in the list will open the full set of information recorded for the form entry. Next and previous buttons allow you to navigate through the entry list.
If configured via the permissions model and supported by the version of Umbraco Forms you are running, entries may be editable via the backoffice. If available, click the Edit button to switch the read-only view of an entry to an editable one and Save to record the changes. An audit trail will show who and when updates on the entry were made.
Validation will operate as is configured for the form in terms of mandatory fields and those that must match a particular pattern. Conditional display of fields is not supported.
To export all the entries from your Form:
Go to the Forms section.
Navigate to the Entries you wish to export.
Click Export in the top-right corner of the screen.
The Export dialog opens. Choose a format such as Microsoft Excel to export the Form records to.
Click Done.
If you have fields that allow the user to upload files within your form, you will also have the option to download a zip file containing these files. You can either download the files in the structure that they are stored on the web server's disk. Or you can download them organised by entry, so it's easier to match up the entry listed in the spreadsheet download with the uploaded file(s).
When selecting entries, it is possible to execute Actions. To select an entry, click anywhere on the entry.
Clicking on the Name opens a view where you can see the entire entry details.
Select at least 1 record to see the available actions in the top-right corner. By default, there are 2 possible actions:
Approve
Delete
The File Upload field allows the users to upload a file along with the Form on your website.
In this article, you will find details about the configuration options you have for the File Upload field.
You can choose to specify which files you want to allow the user to upload, when accessing the Form.
To allow only specific files:
Select the File Type checkbox the user should be able to upload.
Click Submit.
We recommend selecting Allow only specified files, to limit malicious code to be uploaded, whenever the user is submitting the Form.
If the list of predefined file types do not include a specific file type, you can add additional ones.
To add new file type:
Type a file extension name in the User defined allowed file types field and click add.
Click Submit.
This builds on the "" chapter
Umbraco Forms can be used to replace placeholders within form elements with values from different sources. Sources include the HTTP request or the Umbraco page where the form is hosted.
These values can be formatted using .
Filter functions for common operations such as truncating a string or formatting a date or number are provided. It's also possible to create custom ones in code.
To create a custom format function, create a class that implements IParsedPlaceholderFormatter.
The FunctionName property provides the name of the function that will be used within the form's magic string.
The FormatValue property parses the provided value and arguments and returns the formatted value as a string.
The following example shows the implementation of a function that bounds an integer value. It takes two arguments, a minimum and maximum value. If the value read from the magic string source is numeric, and fits within the two bounds, it is returned. Otherwise, either the minimum or maximum value is returned depending on whether the value is lower or higher than the bounds respectively.
As with other provider types, the custom function needs to be registered. An example registration using the IUmbracoBuilder is shown below:
The format function can be used within a form's magic string in the same way as the ones provided with Umbraco Forms.
For the example provided, it would be used like this:
Gets or sets the form entry's values.
Gets or sets an optional ID of the content page through which the form was submitted.
Gets or sets an optional culture code for which the form submission should be processed.
Gets or sets the form's ID.
Gets or sets the form's name.
Gets or sets the form's indicator for mandatory fields.
Gets or sets the form's CSS class.
Gets or sets the form's label for the next page button.
Gets or sets the form's label for the previous page button.
Gets or sets the form's button submit label.
Gets or sets a value indicating whether to disable the form's default stylesheet.
Gets or sets the form's field mandatory or optional field indication type.
Enumeration for field indications.
Gets or sets a value indicating whether to hide field validation.
Gets or sets the form's message to display on submission.
Gets or sets a value indicating whether the form's message to display on submission is in HTML format.
Gets or sets a value indicating whether to show the form's validation summary.
Gets or sets the form's page to redirect to following submission.
Gets or sets the form's pages.
Gets or sets the form page's caption.
Gets or sets the form page's condition.
Gets or sets the form condition's action type.
Enumeration for field condition display options.
Gets or sets the form condition's logic type.
Enumeration for field condition logic matches.
Gets or sets the form condition's rules.
Gets or sets fhe form condition rules's field.
Gets or sets fhe form condition rules's operator.
Enumeration for field condition rule operators.
Gets or sets fhe form condition rules's value.
Gets or sets the form page's fieldsets.
Gets or sets the form fieldset's ID.
Gets or sets the form fieldset's caption.
Gets or sets the form fieldset's condition.
Gets or sets the form condition's action type.
Enumeration for field condition display options.
Gets or sets the form condition's logic type.
Enumeration for field condition logic matches.
Gets or sets the form condition's rules.
Gets or sets fhe form condition rules's field.
Gets or sets fhe form condition rules's operator.
Enumeration for field condition rule operators.
Gets or sets fhe form condition rules's value.
Gets or sets the form fieldset's columns.
Gets or sets the form fieldset column's caption.
Gets or sets the form fieldset column's width.
Gets or sets the form fieldset column's fields.
Gets or sets the form field's ID.
Gets or sets the form field's catpion.
Gets or sets the form field's help text.
Gets or sets the form field's placeholder.
Gets or sets the form field's CSS class.
Gets or sets the form field's alias.
Gets or sets a value indicating whether the form field is required to be completed.
Gets or sets the form field's message to display if the required field is not completed.
Gets or sets the form field's validation pattern (regular expression).
Gets or sets the form field's message to display if the field does not match the provided pattern.
Gets or sets the form field's condition.
Gets or sets the form condition's action type.
Enumeration for field condition display options.
Gets or sets the form condition's logic type.
Enumeration for field condition logic matches.
Gets or sets the form condition's rules.
Gets or sets fhe form condition rules's field.
Gets or sets fhe form condition rules's operator.
Enumeration for field condition rule operators.
Gets or sets fhe form condition rules's value.
Gets or sets the form field's file upload options.
Gets or sets a value indicating whether all file extensions are allowed.
Gets or sets the allowed file extensions.
Gets or sets a value indicating whether multiple file uploads are allowed.
Gets or sets the form field's prevalues.
Gets or sets the form field prevalue's value.
Gets or sets the form field prevalue's caption.
Gets or sets the form field's settings.
Gets or sets the form field's type.
Gets or sets the form type's ID.
Gets or sets the form type's name.
Gets or sets a value indicating whether the form type's supports prevalues.
Gets or sets a value indicating whether the form type's supports file uploads.
Gets or sets a value indicating how the the field should be rendered, as a single input, multiple inputs within an an HTML fieldset (e.g. a radio button or check box list).
