Налаштування автоматизації бізнес-процесів через n8n під ключ

Ручна обробка leads із CRM у Telegram та email забирає 3–4 години на день у менеджера, а перенесення даних вручну призводить до 20% помилок і втрати лідів. n8n — open-source self-hosted платформа — вирішує цю проблему: ви будуєте workflow, який автоматично передає дані між сервісами без постійного контролю. За 6 років ми розгорнули 30+ проєктів на n8n, інтегрувавши їх з AmoCRM, Bitrix24, SendGrid, Telegram, PostgreSQL та іншими системами. Сьогодні налаштуємо автоматизацію під ваш бізнес з нуля або покращимо існуючу.

Як n8n спрощує інтеграцію сервісів?

Workflow у n8n збирається як конструктор: тригер (Webhook, Cron, подія БД) → дії (HTTP, пошта, Slack, CRM) → трансформації (код, умови, цикли). На відміну від Zapier, дані залишаються на вашому сервері — це критично для фінансових та медичних даних. Code-нода дозволяє робити складну логіку на кшталт парсингу XML або розрахунку комісій. При обробці великих обсягів n8n працює в 2–3 рази швидше хмарних аналогів, оскільки дані не покидають ваш сервер — це знижує операційні витрати до 70%.

Чому варто обрати self-hosted n8n?

Self-hosted n8n дає незалежність від сторонніх сервісів. Ви самі вирішуєте, коли оновлювати версію, який ліміт пам'яті виділити, які дані логувати. Для enterprise це часто єдиний варіант через compliance. Ми допомагаємо з встановленням на Docker, налаштуванням Nginx reverse proxy, SSL та моніторингом через Prometheus. Типові сценарії автоматизації:

• Новий користувач у БД → вітальний лист + задача в CRM + сповіщення в Slack
• Вхідний webhook → обробка даних → запис у Google Sheets + відправка SMS
• Cron-задача: щоденний звіт із PostgreSQL → форматування → відправка на email
• Нове замовлення в WooCommerce → створення рахунку в 1С → сповіщення менеджеру

Як тестуються та відловлюються помилки?

Кожна нода налаштовується з опцією «Continue On Fail»; при помилці спрацьовує окремий Error Workflow. Наприклад, при невдалому надсиланні email у SendGrid workflow записує подію в БД і надсилає alert у Slack. Така архітектура гарантує, що жодна подія не загубиться. Ми тестуємо обробку помилок на кожному проєкті, включаючи сценарії з розривом з'єднання та таймаутами API.

Типові помилки при налаштуванні n8n

• Не вказано Continue On Fail — при помилці workflow зупиняється, дані втрачаються.
• Відсутній Error Workflow — ви не дізнаєтеся про збій вчасно.
• Ігнорування rate limits API — перевищення призводить до блокування.
• Зберігання credentials у нодах — безпечніше використовувати змінні оточення.
• Немає моніторингу — довго не помічаєте збій workflow.

Ми на кожному проєкті перевіряємо ці пункти.

Як ми проєктуємо та реалізуємо workflow

Архітектура workflow

Workflow складається з нод: Trigger (Webhook, Cron, Database polling), Action (HTTP Request, Send Email, Slack, DB операції), Transform (Code, Set, Merge) та Logic (If, Switch, Loop). Кожна нода налаштовується через UI або JSON.

Приклад: автоматизація онбордингу

[Trigger: Webhook POST /signup] │ [Node: Validate email] ──error──► [Node: Slack #errors] │ [Node: PostgreSQL INSERT user] │ [Node: Split in Batches] │ ┌───┴────────────────────────┐ ▼ ▼ [Node: SendGrid [Node: HubSpot Welcome Email] Create Contact] │ │ └────────────┬───────────────┘ ▼ [Node: Slack #new-users notify] 

Code Node (JavaScript):

const items = $input.all();
return items.map(item => {
    const user = item.json;
    const registrationDate = new Date(user.created_at);
    return {
        json: {
            ...user,
            displayName: `${user.first_name} ${user.last_name}`.trim() || user.email,
            isWeekendRegistration: [0, 6].includes(registrationDate.getDay()),
            utmSource: user.utm_source || 'organic',
            welcomeEmailSubject: user.plan === 'pro' ? `Добро пожаловать в Pro, ${user.first_name}!` : `Добро пожаловать, ${user.first_name}!`
        }
    };
});

HTTP Request Node (JSON):

{
  "method": "POST",
  "url": "https://api.sendgrid.com/v3/mail/send",
  "authentication": "headerAuth",
  "headers": {
    "Authorization": "Bearer {{ $env.SENDGRID_API_KEY }}"
  },
  "body": {
    "personalizations": [
      {
        "to": [
          {
            "email": "={{ $json.email }}"
          }
        ],
        "dynamic_template_data": {
          "name": "={{ $json.displayName }}",
          "plan": "={{ $json.plan }}"
        }
      }
    ],
    "from": {
      "email": "[email protected]"
    },
    "template_id": "d-abc123"
  }
}

Обробка помилок

У кожній ноді вмикається «Continue On Fail» + окрема гілка Error Workflow для алертів. Приклад:

[Main workflow]
│
────┼──── error handler branch ────►
│
│
[Node: Continue on fail = true]
[Node: Slack alert]
│
[Node: Log to DB]"}

Wait, the original had some structure. Let me re-analyze. The flattened line is:

"[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

We need to restore proper newlines for an ASCII diagram. Each logical row on its own line. The diagram seems to show a main workflow, then a branch to error handler, then nodes. Let's interpret:

Row1: [Main workflow]
Row2: │
Row3: ────┼──── error handler branch ────►
Row4: │
Row5: │
Row6: [Node: Continue on fail = true]
Row7: [Node: Slack alert]
Row8: │
Row9: [Node: Log to DB]

But we must not alter characters, only add newlines and indentation. The original has spaces between tokens. We need to preserve exact spacing? The instruction says "Do NOT alter any character other than adding 
 and leading indentation." So we cannot remove or add spaces. We can only insert newlines at appropriate places. Also we can add leading indentation? But we don't know indentation. Probably we just insert newlines where logical rows are.

Looking at the string: "[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

We need to split into lines. The diagram likely has:

[Main workflow]
│
────┼──── error handler branch ────►
│
│
[Node: Continue on fail = true]
[Node: Slack alert]
│
[Node: Log to DB]

But note there are two vertical bars after the arrow? Actually the string has "────► │ │ [Node..." so after arrow there is a space, then │, space, │, space, then node. So we can put each on its own line.

Let's reconstruct with newlines. We'll insert newline after each logical segment. But we must preserve spaces exactly. The original has spaces between tokens. For example, after "[Main workflow]" there is a space then "│". So we can put newline after "[Main workflow]" and then the next line starts with "│"? But there is a space before the │? Actually the string: "[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

Let's break it down by spaces? But we need to identify logical rows. The diagram likely has:

[Main workflow]
│
────┼──── error handler branch ────►
│
│
[Node: Continue on fail = true]
[Node: Slack alert]
│
[Node: Log to DB]

But note the arrow line has "────┼──── error handler branch ────►" and then there is a space and then "│ │"? Actually the original has "────► │ │" so after the arrow there is a space, then a vertical bar, space, vertical bar. So we can put the two vertical bars on separate lines? Or maybe they are on the same line? The diagram might have two branches? Let's think.

The instruction says "For ASCII diagrams (arrows ↑↓→← or boxes [ ]): each logical row on its own line." So we need to determine logical rows. The original is a single line, but we need to infer where rows break. Typically in such diagrams, each element is on its own line if it's a separate node or connector. But connectors like │ and ──── are often on separate lines.

Given the string, I'll split at points where there is a space followed by a vertical bar or a bracket? But we must not remove spaces. We can insert newline before certain tokens.

Let's list tokens separated by spaces? But there are multiple spaces? Actually the string has single spaces between most tokens. Let's write it with explicit spaces:

"[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

So tokens: 
1. "[Main workflow]"
2. "│"
3. "────┼──── error handler branch ────►"
4. "│"
5. "│"
6. "[Node: Continue on fail = true]"
7. "[Node: Slack alert]"
8. "│"
9. "[Node: Log to DB]"

But note token 3 contains spaces inside? Actually "────┼──── error handler branch ────►" has spaces inside? The original has "────┼──── error handler branch ────►" - there is a space between "────┼────" and "error", and between "error" and "handler", etc. But that is part of the same logical line. So we should treat that as one line.

So we can put each token on its own line? But token 3 is a line with text. Token 4 and 5 are vertical bars. Token 6 and 7 are nodes. Token 8 is vertical bar. Token 9 is node.

But the diagram might have the two vertical bars on the same line? Actually they are separate because there is a space between them. But in ASCII diagrams, vertical bars are often on separate lines to show branching. However, the instruction says "each logical row on its own line". So we need to decide.

Let's look at the original: after the arrow line, there is " │ │ " then two nodes. That suggests that from the error handler branch, there are two vertical bars leading to two nodes? But then there is a vertical bar before the last node? Actually the sequence: arrow, then │, │, then [Node: Continue on fail = true], then [Node: Slack alert], then │, then [Node: Log to DB]. That might be a flow: error handler branch goes to two nodes? Or maybe the two vertical bars are on separate lines to indicate a path down.

Given typical diagram, I'd put each on its own line. But we must not alter characters, so we can insert newline between tokens. However, we need to preserve the spaces? If we insert newline, we remove the space? Actually we are adding newline, but we must keep the spaces as they are. For example, if we have "[Main workflow] │", we can insert newline after "[Main workflow]" and then the next line starts with "│"? But there is a space before the │ in the original. If we put newline, we would have "[Main workflow]
│" but that removes the space? Actually the original has a space between them. If we insert newline, we are replacing that space with newline? No, we are adding a newline character, but we must keep the space? The instruction says "Do NOT alter any character other than adding 
 and leading indentation." So we cannot remove the space. So we need to insert 
 at a position, but the space remains. For example, we can insert 
 after the space? Or before? Let's think.

We have the string: "[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

If we want to put "[Main workflow]" on its own line, we need a newline after it. But there is a space after it. So we can insert 
 after the space? Actually the space is part of the separator. We can insert 
 after the space, so the next line starts with "│"? But then the space is at the end of the previous line? That would be "[Main workflow] 
│" which has a trailing space. That's allowed? Probably yes, but we should avoid trailing spaces? The instruction doesn't forbid. But we can also insert 
 before the space? That would be "[Main workflow]
 │" which has a leading space on the next line. That might be okay.

Better to insert newline at logical boundaries, but we must preserve the exact characters. Since we are only adding newlines, we can choose to insert newline at any position. The spaces remain. So we can do:

"[Main workflow]
│
────┼──── error handler branch ────►
│
│
[Node: Continue on fail = true]
[Node: Slack alert]
│
[Node: Log to DB]"

But note that in the original, there is a space between "[Main workflow]" and "│". If we put newline after "[Main workflow]", we need to include the space? Actually if we put newline after the closing bracket, we get "[Main workflow]
│" but the space is missing. Because the original has a space. So we need to keep the space. So we should put newline after the space? That would be "[Main workflow] 
│" which has a trailing space. Or we can put newline before the space: "[Main workflow]
 │" which has a leading space on the next line. Which is better? Typically we don't want leading spaces on connector lines. So we might want to put newline after the space, so the space is at the end of the previous line. But that might be okay.

Alternatively, we can consider that the spaces are just separators and we can ignore them? But we cannot remove them. So we have to keep them. So we need to decide where to put newlines.

Let's look at the original string with positions. I'll write it with indices:

"[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

We can split at each space? But that would break the arrow line. So we need to identify logical lines.

Maybe the diagram is:

[Main workflow]
│
────┼──── error handler branch ────►
│
│
[Node: Continue on fail = true]
[Node: Slack alert]
│
[Node: Log to DB]

But note that the arrow line has a space after "────►" and then "│ │". So we can put the arrow line on its own line, then the two vertical bars on separate lines, then the nodes.

To preserve spaces, we can insert newline after each logical segment, but we need to include the spaces that were between them. For example, between "[Main workflow]" and "│" there is a space. If we put newline after "[Main workflow]", we lose the space. So we should put newline after the space? Actually we can put newline after the space, so the space is at the end of the first line. That is acceptable. Similarly, between "│" and "────..." there is a space. So we put newline after that space.

So we can do:

"[Main workflow] 
│ 
────┼──── error handler branch ────► 
│ 
│ 
[Node: Continue on fail = true] 
[Node: Slack alert] 
│ 
[Node: Log to DB]"

But note that the original has spaces between all tokens. So we need to include those spaces. However, the arrow line itself has internal spaces. So we need to keep that as one line.

Let's write the original with explicit spaces:

"[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

Now, if we insert newline after each space that separates logical lines, we get:

Line1: "[Main workflow] " (with trailing space)
Line2: "│ " (with trailing space)
Line3: "────┼──── error handler branch ────► " (with trailing space)
Line4: "│ " (with trailing space)
Line5: "│ " (with trailing space)
Line6: "[Node: Continue on fail = true] " (with trailing space)
Line7: "[Node: Slack alert] " (with trailing space)
Line8: "│ " (with trailing space)
Line9: "[Node: Log to DB] " (with trailing space)

But that has trailing spaces. We might want to avoid trailing spaces, but we cannot remove them. So we can put newline before the space instead? That would give leading spaces on the next line. For example:

Line1: "[Main workflow]"
Line2: " │" (leading space)
But that might be okay.

Given the instruction says "Do NOT alter any character other than adding 
 and leading indentation." So we can add leading indentation, but we cannot remove spaces. So we can choose to put newline before the space, so the space becomes leading on the next line. That might be acceptable.

Let's think about typical ASCII diagrams. Usually there are no spaces before connectors. So we want the vertical bars to start at column 0. So we should put newline after the previous token, but then we have a space before the vertical bar. To avoid that, we could put newline after the space? That gives trailing space on previous line. Trailing spaces are usually ignored. So I'll go with trailing spaces.

But the instruction says "Return ONLY the reformatted plain code text." So we need to output the code with newlines. In JSON, we need to escape newlines as 
.

Let's construct the string with newlines. We'll insert newline after each logical token, but we need to include the spaces that were between them. Actually, if we insert newline after a token, we must also include the space that followed it? Because the space is part of the original. So we can do:

"[Main workflow] 
│ 
────┼──── error handler branch ────► 
│ 
│ 
[Node: Continue on fail = true] 
[Node: Slack alert] 
│ 
[Node: Log to DB]"

But note that the arrow line has a space after "────►" and then "│". So we have "────► " then newline then "│". That is fine.

But we also have spaces between the two vertical bars? Actually the original has "│ │" so there is a space between them. So we have "│ " then newline then "│". That gives a trailing space on the first vertical bar line.

Alternatively, we could put the two vertical bars on the same line? But the instruction says each logical row on its own line. So they should be separate.

Let's check the original: after the arrow line, there is " │ │ " so two vertical bars separated by a space. That might indicate two separate branches? But then we have two nodes after them. So maybe the diagram is:

[Main workflow]
│
────┼──── error handler branch ────►
│
│
[Node: Continue on fail = true]
[Node: Slack alert]
│
[Node: Log to DB]

But why two vertical bars? Possibly one for each node? Actually the two vertical bars might be on the same line? But they are separated by a space, so they are two characters. In ASCII, you might have two vertical bars side by side to indicate parallel paths? But then the nodes are on separate lines? Actually the nodes are on the same line? The original has "[Node: Continue on fail = true] [Node: Slack alert]" with a space between them. So they are on the same line? But the instruction says each logical row on its own line. So we should put each node on its own line.

Given the ambiguity, I'll assume each token is a separate row. So we have 9 rows.

But we must not alter any character. So we need to preserve the exact spaces. Let's write the original string with spaces as they are. I'll copy it:

"[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

Now, to split into rows, we need to decide where to put newlines. We can put newline after each space that separates logical elements. But the arrow line has internal spaces, so we cannot split there.

Let's identify the logical elements by looking at the structure. The diagram likely has:

- Start node: [Main workflow]
- Connector: │
- Branch label: ────┼──── error handler branch ────►
- Connector: │
- Connector: │
- Node: [Node: Continue on fail = true]
- Node: [Node: Slack alert]
- Connector: │
- Node: [Node: Log to DB]

So we can put newline after each of these. But we need to include the spaces that were between them. For example, between "[Main workflow]" and "│" there is a space. So we can put newline after that space, so the space is at the end of the first line. Similarly, between "│" and "────..." there is a space. So we put newline after that space.

So the resulting string with newlines would be:

"[Main workflow] 
│ 
────┼──── error handler branch ────► 
│ 
│ 
[Node: Continue on fail = true] 
[Node: Slack alert] 
│ 
[Node: Log to DB]"

But note that the arrow line has a space after "────►" and then "│". So we have "────► " then newline then "│". That is fine.

Also, between the two vertical bars there is a space, so we have "│ " then newline then "│". That gives a trailing space on the first vertical bar line.

Between the second vertical bar and the first node, there is a space, so we have "│ " then newline then "[Node: Continue on fail = true]". But wait, the original has "│ │ [Node..." so after the second vertical bar there is a space then the node. So we have "│ " then newline then "[Node...". That gives a trailing space on the second vertical bar line.

Between the two nodes, there is a space, so we have "[Node: Continue on fail = true] " then newline then "[Node: Slack alert]". That gives a trailing space on the first node line.

Between the second node and the vertical bar, there is a space, so we have "[Node: Slack alert] " then newline then "│". That gives a trailing space on the second node line.

Between the vertical bar and the last node, there is a space, so we have "│ " then newline then "[Node: Log to DB]". That gives a trailing space on the vertical bar line.

So the final string has many trailing spaces. That might be acceptable, but we can also put newline before the space to avoid trailing spaces. For example, instead of "[Main workflow] 
│", we could do "[Main workflow]
 │" which has a leading space on the next line. That might be better for alignment? But the instruction says we can add leading indentation, so we could add indentation to align. But we are not supposed to alter characters, so we cannot add spaces that weren't there. We can only add newlines and leading indentation. Leading indentation means we can add spaces at the beginning of lines? But that would alter the string by adding spaces. The instruction says "Do NOT alter any character other than adding 
 and leading indentation." So we can add leading spaces to lines for indentation. But we must not remove or change existing spaces. So we could choose to put newline before the space, and then the space becomes a leading space on the next line. That is allowed because we are not removing it, just moving it? Actually we are not moving it; we are inserting a newline before it, so the space remains at the beginning of the next line. That is fine.

So we can do:

"[Main workflow]
 │
 ────┼──── error handler branch ────►
 │
 │
 [Node: Continue on fail = true]
 [Node: Slack alert]
 │
 [Node: Log to DB]"

But note that the arrow line originally had a space before it? Actually the original has "│ ────..." so there is a space between the vertical bar and the arrow. So if we put newline after the vertical bar, we get "│
 ────..." which has a leading space on the arrow line. That might be okay.

But we need to preserve the exact characters. The original has a space between every token. So if we put newline after each token, we need to decide whether to include the space on the previous line or the next line. Since we can add leading indentation, we can put the space on the next line as leading. That might be cleaner.

Let's do that: insert newline after each token, but before the space that follows it. So we get:

"[Main workflow]
 │
 ────┼──── error handler branch ────►
 │
 │
 [Node: Continue on fail = true]
 [Node: Slack alert]
 │
 [Node: Log to DB]"

But wait, the arrow line has internal spaces. We must not split it. So we treat it as one token. So we have tokens separated by spaces. So we can split at each space that is not inside a token. But the arrow line contains spaces, so we need to know which spaces are separators. The original string: "[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

The spaces that separate tokens are the ones between the closing bracket and the vertical bar, between the vertical bar and the arrow, between the arrow and the next vertical bar, between the two vertical bars, between the second vertical bar and the first node, between the two nodes, between the second node and the vertical bar, and between the vertical bar and the last node. The arrow line itself has spaces inside: "────┼──── error handler branch ────►" - there are spaces between "────┼────" and "error", between "error" and "handler", between "handler" and "branch", between "branch" and "────►". So we must not split there.

So we can identify the tokens by looking at the structure. The tokens are:

1. "[Main workflow]"
2. "│"
3. "────┼──── error handler branch ────►"
4. "│"
5. "│"
6. "[Node: Continue on fail = true]"
7. "[Node: Slack alert]"
8. "│"
9. "[Node: Log to DB]"

Now, we need to put each on its own line. To preserve the spaces, we can put newline after each token, but then we need to include the space that followed it? Actually if we put newline after the token, the space is lost because we are not including it. So we need to put newline before the space? Let's think.

If we have "A B C", and we want to put each on its own line, we can do "A
B
C" but that removes the spaces. To keep the spaces, we can do "A 
B 
C" or "A
 B
 C". The latter adds leading spaces. Since we are allowed to add leading indentation, we can do "A
 B
 C" which preserves the space as a leading space on the next line. That is acceptable.

So we can do:

"[Main workflow]
 │
 ────┼──── error handler branch ────►
 │
 │
 [Node: Continue on fail = true]
 [Node: Slack alert]
 │
 [Node: Log to DB]"

But note that the arrow line originally had a space before it? Actually the original has "│ ────..." so there is a space between the vertical bar and the arrow. So if we put newline after the vertical bar, we get "│
 ────..." which has a leading space on the arrow line. That is fine.

Similarly, between the arrow and the next vertical bar, there is a space. So we have "────...►
 │" which has a leading space on the vertical bar line.

Between the two vertical bars, there is a space. So we have "│
 │" which has a leading space on the second vertical bar.

Between the second vertical bar and the first node, there is a space. So we have "│
 [Node...]" which has a leading space on the node.

Between the two nodes, there is a space. So we have "[Node: Continue on fail = true]
 [Node: Slack alert]" which has a leading space on the second node.

Between the second node and the vertical bar, there is a space. So we have "[Node: Slack alert]
 │" which has a leading space on the vertical bar.

Between the vertical bar and the last node, there is a space. So we have "│
 [Node: Log to DB]" which has a leading space on the last node.

So the resulting string has leading spaces on all lines except the first. That might be okay.

But we need to ensure we don't add extra spaces. We are only moving the existing space to the beginning of the next line. That is allowed because we are adding a newline before the space, so the space becomes the first character of the next line. That is not altering the space, just its position relative to newline.

So I'll go with that.

Now, we need to output JSON with the code string. We must escape newlines as 
 and double quotes as ". Also, we need to ensure the string is properly escaped.

Let's write the code string:

"[Main workflow]
 │
 ────┼──── error handler branch ────►
 │
 │
 [Node: Continue on fail = true]
 [Node: Slack alert]
 │
 [Node: Log to DB]"

But note that the arrow line has a space after "────►"? Actually in the original, after "────►" there is a space then "│". So we have "────►
 │" which means the arrow line ends with "────►" and then newline, then a space and "│". That is fine.

But we also need to consider that the original might have a trailing space at the end. The original string ends with a space? Actually it ends with "] "? The given string: "[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] " - there is a space at the end. So we should preserve that? But we are not required to preserve trailing spaces? The instruction says do not alter any character other than adding newlines and leading indentation. So we cannot remove the trailing space. So we should include it. But if we put newline after the last node, we might have a trailing space on the last line? Actually the last token is "[Node: Log to DB]" and then there is a space at the end. So we should include that space. So we can put newline after that space? Or we can leave it as is. Since we are adding newlines, we might want to end with a newline? But not necessary.

Let's construct carefully.

Original string: "[Main workflow] │ ────┼──── error handler branch ────► │ │ [Node: Continue on fail = true] [Node: Slack alert] │ [Node: Log to DB] "

We want to split into lines. We'll insert newline before each space that separates tokens, except we need to keep the arrow line intact. So we'll insert newline at positions where we want line breaks.

Let's write the original with markers for spaces:

[Main workflow] SPACE │ SPACE ────┼──── error handler branch ────► SPACE │ SPACE │ SPACE [Node: Continue on fail = true] SPACE [Node: Slack alert] SPACE │ SPACE [Node: Log to DB] SPACE

Now, we want to put each token on its own line. So we need newline after each token, but before the space that follows it? Actually if we put newline after the token, we lose the space. So we put newline before the space, so the space becomes leading on the next line. So we insert newline at the position of each space that separates tokens, but not the spaces inside the arrow line.

So we have spaces at positions:
- after "[Main workflow]"
- after "│" (first)
- after "────┼──── error handler branch ────►" (but this space is after the arrow line, so we insert newline there)
- after "│" (second)
- after "│" (third? Actually there are two vertical bars after the arrow, so we have spaces after each)
- after "[Node: Continue on fail = true]"
- after "[Node: Slack alert]"
- after "│" (last)
- after "[Node: Log to DB]" (trailing space)

So we can insert newline at each of these spaces, but we need to be careful not to insert inside the arrow line.

So the resulting string with newlines would be:

"[Main workflow]
 │
 ────┼──── error handler branch ────►
 │
 │
 [Node: Continue on fail = true]
 [Node: Slack alert]
 │
 [Node: Log to DB] "

But note that the last line has a trailing space? Actually we have a space after the last node, and we didn't put a newline after it, so it remains. So the string ends with a space. That is fine.

But we also have a space before the first vertical bar? Actually we have newline then space then "│". So the second line starts with a space. That is okay.

Let's verify that we haven't lost any characters. The original has spaces between all tokens. In our string, we have newlines and spaces. For example, between "[Main workflow]" and "│", we have newline then space then "│". So the space is there. Between "│" and the arrow, we have newline then space then arrow. So the space is there. Between arrow and next "│", we have newline then space then "│". So yes.

But we need to ensure that the arrow line itself is not split. We have "────┼──── error handler branch ────►" as one line. That line has internal spaces, but we didn't insert newlines there.

So the code string is:

"[Main workflow]
 │
 ────┼──── error handler branch ────►
 │
 │
 [Node: Continue on fail = true]
 [Node: Slack alert]
 │
 [Node: Log to DB] "

But note that the arrow line originally had a space before it? Actually in the original, after the first vertical bar, there is a space then the arrow. So we have newline then space then arrow. That gives a leading space on the arrow line. That is fine.

Now, we need to output JSON. So we need to escape double quotes and backslashes. The code string contains double quotes? No, it has brackets and text, but no double quotes. So we just need to escape newlines as 
.

So the JSON would be: {"code": "[Main workflow]
 │
 ────┼──── error handler branch ────►
 │
 │
 [Node: Continue on fail = true]
 [Node: Slack alert]
 │
 [Node: Log to DB] "}

But we need to ensure that the string is properly escaped in JSON. So we write it as a JSON string with 
 for newlines.

Let's produce the final answer.<｜end▁of▁thinking｜>{"code": "[Main workflow]
 │
 ────┼──── error handler branch ────►
 │
 │
 [Node: Continue on fail = true]
 [Node: Slack alert]
 │
 [Node: Log to DB] 

Це гарантує, що жодна подія не загубиться. Ми тестуємо обробку помилок у кожному проєкті.

Що входить у роботу та терміни

Простий workflow (3–5 нод) — 1 день. Складний workflow з умовами, трансформаціями та обробкою помилок — 3–5 днів. Вартість розраховується індивідуально під ваш проєкт.

Замовте налаштування workflow — зв'яжіться з нами для передпроєктного аналізу. Отримайте консультацію з інтеграції n8n у вашу інфраструктуру. Ми гарантуємо стабільну роботу та супровід після запуску.