Type: Troubleshooting
Category: Umbraco Cloud > CI/CD & Deployments
Tags: FieldType Provider, GUID, restore failed, ProcessArtifactException, forms-form artifact, Umbraco Forms, reCAPTCHA, recaptcha2, appsettings, environment configuration, Deploy restore, Process package on target

Product: Umbraco Cloud, Umbraco Deploy, Umbraco Forms
Version: All versions

A restore or deployment between Umbraco Cloud environments fails partway through with an error saying the target site does not contain a FieldType Provider with a given GUID. This article explains what that GUID means, why the provider is usually present but unusable rather than actually missing, and how to resolve it.

Who this applies to. This error comes from Umbraco Forms. It is only relevant if your project has Umbraco Forms installed and the failing artifact in the log starts with umb://forms-form/. If your project does not use Forms, see How to Troubleshoot Common Deployment Errors in Umbraco Cloud instead.

Symptoms

A restore from another environment, or a deployment, fails at the Process package on target stage.
The deployment log contains an error of this shape:

System.InvalidOperationException: Target site does not contain a FieldType Provider with the GUID:<guid> Ensure the DLL containing this provider has been deployed to the target.Umbraco.Deploy.Core.Exceptions.ProcessArtifactException: Process pass #<n> failed for artifact umb://forms-form/<artifact-id>.

The inner stack trace names Umbraco.Forms.Deploy.ServiceConnectors.FormConnector.
The error is reproducible: retrying the restore fails at the same point every time.

If you have already cleared signatures and updated the schema. Running Clear signatures, Set signatures and Update schema from the Deploy dashboard is a sensible early step, and it does resolve a number of extraction and restore failures on a newly created environment — see How to Troubleshoot Common Deployment Errors in Umbraco Cloud. If the restore still fails with the FieldType Provider error afterwards, continue with the steps below: at that point the blocker is the field type rather than the schema.

Cause

Umbraco Deploy transfers each form as an artifact. To write that artifact into the target environment, the target must have a registered field type provider for every field the form uses. The GUID in the error identifies which field type is unavailable.

Despite the wording of the message, a missing DLL is rarely the actual cause. There are two realistic explanations:

The field type is a built-in reCAPTCHA field, and its keys do not resolve in the target environment. This is the most common cause. The reCAPTCHA field types need their configuration values in order to be usable, so on an environment where those values are absent the provider is effectively not available to Deploy, even though the assembly is present.
The field type is a custom one, added through the Umbraco Forms provider model, and the assembly containing it really has not reached the target. Here the message is literal.

This most often surfaces on a newly created environment, because a new environment starts without any environment-specific configuration that the older environments may have accumulated.

Solution

Step 1 — Identify the field type from the GUID

Look the GUID up in the field type table in the Umbraco Forms documentation: Type details. The reCAPTCHA field types are the ones most often involved:

Field type	GUID
reCAPTCHA 2	`B69DEAEB-ED75-4DC9-BFB8-D036BF9D3730`
reCAPTCHA 3	`663AA19B-423D-4F38-A1D6-C840C926EF86`
reCAPTCHA Enterprise	`1BAB78CB-52B1-495C-BBC2-A46540642828`

If the GUID is not in that table, it belongs to a custom field type in your own solution. Go to Step 3.

Step 2 — If it is a reCAPTCHA field type, make the keys resolve on the target

Check where the reCAPTCHA settings currently live in your solution. If they are only in environment-specific files such as appsettings.Staging.json or appsettings.Production.json, the target environment will not pick them up, because those files only apply to an environment running under that name.
Move the reCAPTCHA settings into the global appsettings.json so that every environment resolves them. For reCAPTCHA 2 the keys are:

{
  "Umbraco": {
    "Forms": {
      "FieldTypes": {
        "Recaptcha2": {
          "PublicKey": "{your-site-key}",
          "PrivateKey": "{your-secret-key}"
        }
      }
    }
  }
}

Note the key name is PublicKey, not SiteKey. reCAPTCHA 3 and reCAPTCHA Enterprise use SiteKey and PrivateKey instead — check Configuration for the exact keys for your field type.

Deploy the change so it reaches the target environment.
Run the restore or deployment again.

Keep the site key and secret out of source control if your repository is shared. Set the values through your normal secret-handling method as long as it resolves for every environment, not just one.

Step 3 — If it is a custom field type, confirm the assembly reached the target

Confirm the package or project containing the field type is referenced in the deployed solution, and that the reference is present in the .csproj that Cloud builds.
Confirm the build actually succeeded on the target environment. Check the Deployment Kudu Log on the Project History page.
Confirm any configuration the field type needs is also available on the target, for the same reason as Step 2.
Redeploy, then re-run the restore.

Step 4 — If the field type is genuinely no longer part of the project

If the GUID maps to a field type that has been removed from the solution, existing forms may still reference it. Contact Umbraco Support with the full error and the artifact reference rather than deleting the form or recreating the environment. Both are hard to undo, and recreating an environment can affect your deployment order and media.

Prevention

Keep Umbraco Forms provider configuration in the global appsettings.json rather than in per-environment files, so a new environment works on first restore.
Before creating a new environment, check that any configuration your forms depend on is not scoped to a single environment.
Read the deployment log before acting. The GUID and the artifact reference in the error tell you exactly which field type and which form are involved.

Still having issues?

If the restore still fails after the relevant step above, contact Umbraco Cloud support with the full error message and stack trace from the deployment log, including the GUID and the umb://forms-form/ artifact reference. If you are already in a support conversation, ask to talk to a human agent.

Restore fails with "Target site does not contain a FieldType Provider with the GUID" on Umbraco Cloud