I get this question quite frequently in multiple variations, but the problem is always the same. You create a schema using a JSON that you get from somewhere, but when you run your Flow, you get an "Invalid type. Expected X but got Null". The problem has a simple solution (you can check it below), but I'll first show you why it happens to better frame the solution.

The problem

The issue is in the schema that the "Parse JSON" action requires to run. When you use the "Generate from Sample", Power Automate will try its best to build the schema that describes the data received.

You don't need to know what a schema is, but if you're curious, here's an article explaining it in detail.

The schema describes the type of data that the JSON has. Think of it as a translator between JSON and "Power Automate language" so you can then pick the fields from the "Dynamic content" in other actions.

For example, let's say that we have the following JSON:

{
	"name": "Manuel Gomes",
	"age": 41,
	"address":""
}

Power Automate will generate the following schema:

{
    "type": "object",
    "properties": {
        "name": {
            "type": "string"
        },
        "age": {
            "type": "integer"
        },
        "address": {
            "type": "string"
        }
    }
}

If we insert a "Compose" action, for example, we can now find the values in the "Dynamic Content" tab:

But what about if I was shy about my age and didn't provide it so that the service would return something like this:

{
	"name": "Manuel Gomes",
	"age": null,
	"address":""
}

We will get a "ValidationFailed. The schema validation failed."

Power Automate provides a bit more information below with the error message.

"Invalid type. Expected Integer but got Null."

If the field were a string, then you would get the following:

"Invalid type. Expected String but got Null."

This applies to all types, not just integers and strings. You can also get "Expected Array but got Null", "Expected Boolean but got Null", or "Expected Object but got Null". The solution is the same regardless of the type.

This error commonly shows up when working with SharePoint columns that have empty values, external APIs with optional fields, or SQL queries that return NULLs.

So now that we have the error simulated, let's see how to fix it.

The solution

The solution is to tell Power Automate that it should be able to receive both integers and null values. This is because a "null" value differs entirely from an integer or a string. A "null" value is not the same as "empty" since an "empty" string is a string nevertheless. A "null" field indicates that the field doesn't have "anything" inside it. And since Power Automate doesn't know if "anything" is the same as a string or an integer, it defines it as a distinct type.

So let's add the "null" as a possible value, but how do we know what field has issues? To find it is easy. Just look at the fields below the error message:

In this case, it's indicating that the "property" called "age" has the problem.

Now that we know where to fix it, let's look again at the schema:

{
    "type": "object",
    "properties": {
        "name": {
            "type": "string"
        },
        "age": {
            "type": "integer"
        },
        "address": {
            "type": "string"
        }
    }
}

Currently, the "type" for the "age" is only an integer, but we need to tell Power Automate to allow "null" as well. Since we want "multiple" types, we need to use an array of potential types of values, like:

["integer","null"]

Now we replace the type from only one value with a range of values.

{
    "type": "object",
    "properties": {
        "name": {
            "type": "string"
        },
        "age": {
            "type": ["integer","null"]
        },
        "address": {
            "type": "string"
        }
    }
}

And the Flow should run without issues. If you get this error again, please check the error message above and see the field's name. You may have multiple fields that need to be changed, so repeat the steps until your Flow runs without issues.

Alternative: removing the required fields

When Power Automate generates a schema, it sometimes includes a "required" array at the top level listing the fields that must be present. If a field is optional and might not appear at all in the response, you can remove it from the "required" array instead of changing the type. For example:

{
    "type": "object",
    "properties": {
        "name": {
            "type": "string"
        },
        "age": {
            "type": "integer"
        }
    },
    "required": ["name"]
}

By removing "age" from the "required" array, Power Automate won't complain if the field is missing entirely. This is a good option when the field might not be returned at all, not just when it's null.

Your Questions

How to save the Parse JSON error into a variable?

I got this question quite a few times: "How do I save the Parse JSON error into a variable instead of having the Flow fail?" This is useful when you want to handle the error gracefully, for example, by logging it or sending a notification.

The trick is to use "Configure run after" on the action that follows the Parse JSON. By default, actions only run when the previous action succeeds, but you can change this to run when it fails as well.

Here's how to do it:

1. Add an "Initialize variable" action before the Parse JSON action. Set it as a string and leave it empty.
2. After the Parse JSON action, add a "Set variable" action.
3. Click the three dots on the "Set variable" action and select "Configure run after".
4. Check "has failed" (and uncheck "is successful" if you only want to capture failures).
5. Set the variable value to the following expression:

outputs('Parse_JSON')?['errors']

Keep in mind that the error returned is not a single message but an array with multiple items, one for each validation issue found. Here's an example of what you might get:

{
    "errors": [
        {
            "message": "Required properties are missing from object: break.",
            "lineNumber": 0,
            "linePosition": 0,
            "path": "",
            "value": [
                "break"
            ],
            "schemaId": "#",
            "errorType": "required",
            "childErrors": []
        }
    ]
}

This way, instead of your Flow failing, it continues running and you have the error details stored in a variable. You can then use it to send an email, log it, or handle it however you need.

Thanks to Lumi for the question...

Final Thoughts

The solution to this issue is relatively easy once you understand where it comes from. Please be careful editing more complex schemas. You can always generate a new one and start over, but take your time and check if you're replacing the field with problems.

Photo by Michael Dziedzic on Unsplash