How to set default “Error Workflow” for new workflows

Feature Requests
1

By the way, in default settings, I want to set general “Error Workflow”.
Could I set default “Error Workflow” by any environment variable?

2

I can’t see an option here: Environment Variables | Docs to set an error workflow from the environment variables… I suspect this could be because it wouldn’t exist on a new install so could cause all sorts of problems.

3

I think an option for default node for error is nessesary.
Error notification is very important, but I usually forgot to set it for new workflow.

1 Like
4

Yeah a global setting somewhere would be handy I am just not sure an env var is the way to handle it.

5

Hey @cmdntd987,

Thank you for creating the Feature Request. I can see how this can be helpful. I don’t think there is an env available.

Do upvote the request!

1 Like
6

Hope this will be merged :sweat_smile:

7

Hello,

In my case it would be a default error workflow per account, as one account represents an organization unit :slight_smile:

8

Hello, reviving this topic to know if this feature can be developed still.
Tried updating all my workflows using the n8n node but sadly it doesn’t give the Error Workflows options =(

9

This would be a helpful feature for us as well, we typically turn on the error workflow for all workflows by default

1 Like
10

Any updates on this at all?

11

Hey @Josh_Sorenson,

Nothing that I have seen in planning meetings recently but I still think this would be a good idea for the future.

12

I can’t believe this hasn’t been fixed yet. Regardless, here’s a workaround:

Do you consistently forget to set a Default Error Workflow when creating new workflows? Then this helper workflow is for you!

When activated, this helper workflow will:

  • Scan ALL other workflows every 4 hours
  • Make sure ALL workflows have a default error workflow set (based on what Workflow ID you provide)
  • This helper will SKIP OVER any workflows that have the default_error:false tag set (make sure your default error workflow has the default_error:false tag set, so that you don’t end up with recursive loops during errors)

Setup Nodes:

  • Once imported, edit the Set Vars node with your default_error_workflow_id value.
  • If you want to change the default_error:false tag to some other tag name, you can do so here as well.
  • You need to update the Set Default Error Workflow node with your PostgreSQL credentials to access the n8n database.
13

This workflow has been published here, also:

14

Hi!

I am iterating your workflow @dkindlund in order to modify the error workflow using the n8n API instead of directly accessing the database, here would be it:

However, it throws an error while updating the workflow: request/body/settings must NOT have additional properties.

Complete error details 
{
  "errorMessage": "Bad request - please check your parameters [item 0]",
  "errorDescription": "request/body/settings must NOT have additional properties",
  "errorDetails": {
    "rawErrorMessage": [
      "Request failed with status code 400"
    ],
    "httpCode": "400",
    "errorData": {
      "message": "request/body/settings must NOT have additional properties"
    }
  },
  "n8nDetails": {
    "nodeName": "Update workflow",
    "nodeType": "n8n-nodes-base.n8n",
    "nodeVersion": 1,
    "resource": "workflow",
    "operation": "update",
    "itemIndex": 0,
    "runIndex": 0,
    "time": "24/05/2024, 08:30:02",
    "n8nVersion": "1.40.0 (Self Hosted)",
    "binaryDataMode": "default",
    "stackTrace": [
      "NodeApiError: Bad request - please check your parameters",
      "    at Object.httpRequestWithAuthentication (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:1164:15)",
      "    at processTicksAndRejections (node:internal/process/task_queues:95:5)",
      "    at Object.httpRequestWithAuthentication (/usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/NodeExecuteFunctions.js:1984:20)",
      "    at RoutingNode.rawRoutingRequest (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/RoutingNode.js:285:29)",
      "    at RoutingNode.makeRoutingRequest (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/RoutingNode.js:371:28)",
      "    at RoutingNode.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/RoutingNode.js:104:32)",
      "    at Workflow.runNode (/usr/local/lib/node_modules/n8n/node_modules/n8n-workflow/dist/Workflow.js:778:23)",
      "    at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:660:53",
      "    at /usr/local/lib/node_modules/n8n/node_modules/n8n-core/dist/WorkflowExecute.js:1062:20"
    ]
  }
}

Have you faced the same problem (and that was the reason to directly modify the workflow in the database)?

I have searched a little bit about the error but I still not get why it is not working.
There is another related bug report, but in that case updating the executionOrder setting instead of the errorWorkflow.
The related error required a fix that got released with n8n 1.37.0, and if we take a look to the fix implementation, it references the schema/workflowSettings.yml which already included the errorWorkflow property.

However, it is also true that there are no errorWorkflow being specified in the n8n API workflow update test case, so I don’t really think that having the errorWorkflow in the workflowSettings schema guarantees that it is supported while updating workflows, or it is just that I am doing something wrong :sweat_smile:

Anyone could confirm if I am missing anything or it is an actual bug? :pray::grimacing:

Thanks! :blush:

Edit: I have found this other post from @Jon stating that the errorWorkflow option is already supported for WorkflowSettings in the API, so I guess I am missing something here :S

15

Hey @JavierCane , yeah, I tried using the official n8n APIs to get it to work, but I couldn’t for similar reasons. That’s why I just wrote directly to the underlying DB instead.

Maybe @Jon can help clarify?

16

Hi @dkindlund and @JavierCane

It looks like this is a highly requested feature, I was not able to use the SQL node so I figured out how to use the API node for N8N

Use the workflow that @dkindlund made and replace the SQL node with another N8N API Node.

Steps to set it up:

Select your N8N account
resource “Workflow”
Operation “update”
Workflow (by ID) map it to {{ $json.id }}

Workflow Object:

{
“name”: “{{ $json.name }}”,
“nodes”: {{ JSON.stringify($json.nodes) }},
“connections”: {{ JSON.stringify($json.connections) }},
“settings”: {
“errorWorkflow”: “BqrrQ816cfbzM4YQ”,
“executionOrder”: “v1”
}
}

Hope that helps

17

@Tier1 I’ve come to this conclusion on my own too. The only drawback is that if you do have any additional workflow settings (like a timeout), it’ll get wiped clean. While not perfect, I think this is a further step in the evolution:

{
“name”: “{{ $json.name }}”,
“nodes”: {{ JSON.stringify($json.nodes) }},
“connections”: {{ JSON.stringify($json.connections) }},
“settings”: {{ JSON.stringify(
(({ callerPolicy, …rest}) => rest)($json.settings)
)}}
}

What that anonymous function does in the settings part is removes unsupported settings. Unfortunately, there’s no way to “PATCH” a workflow via API currently (i.e. overwrite a specific part), so this will have do for now.

@Jon I wonder if we could get a PATCH HTTP verb that handles a differential update rather than an overall replacement of the workflow object? And a quick reminder that all this workaround is because there’s no default Error Workflow for new workflows. I still think the PATCH endpoint would be a good idea, but many in this thread could use the default Error Workflow instead for this use case.

1 Like
18

I created an error handler workflow that’ll attach itself to any workflows that don’t have a handler yet. It already saved me a couple of times from issues that I might not have noticed otherwise!

3 Likes