Hướng dẫn xử lý lỗi error handling trên make.com để tránh sập luồng tự động

Khi xây dựng các hệ thống tự động hóa (automation) cho doanh nghiệp, cảm giác tồi tệ nhất là gì? Đó là khi bạn thức dậy vào buổi sáng và phát hiện ra toàn bộ luồng công việc (scenario) quan trọng đã bị dừng hoạt động (disabled) từ đêm qua chỉ vì một lỗi nhỏ từ API của bên thứ ba. Dữ liệu khách hàng không được đồng bộ, chiến dịch marketing bị đóng băng, và bạn phải tốn hàng giờ để dò lỗi thủ công.

Tôi đã gặp tình huống này không dưới chục lần trong những ngày đầu triển khai hệ thống cho các đối tác. Thực tế, việc xảy ra lỗi là điều không thể tránh khỏi trong thế giới kết nối API. Tuy nhiên, cách chúng ta chuẩn bị và khắc phục lỗi error handling trên make mới là yếu tố quyết định hệ thống của bạn có thực sự “sống khỏe” hay không. Bài viết này tôi sẽ chia sẻ toàn bộ tư duy thực chiến và các bước thiết lập chi tiết để bạn làm chủ kỹ thuật xử lý lỗi chuyên nghiệp trên Make.

Tại sao luồng tự động hóa của bạn bị sập và hậu quả thực tế

Để giải quyết triệt để vấn đề, trước tiên chúng ta phải hiểu rõ cơ chế vận hành của Make và lý do vì sao một lỗi nhỏ lại có thể kéo sập cả một luồng dữ liệu lớn.

Cơ chế dừng luồng tự động của Make

Mặc định, Make được thiết kế để bảo vệ dữ liệu của bạn. Khi một module gặp lỗi mà không có bất kỳ bộ xử lý lỗi (error handler) nào được cấu hình, Make sẽ coi đó là một mối đe dọa đến tính toàn vẹn của dữ liệu. Nếu một scenario gặp lỗi liên tiếp nhiều lần (thường là 3 đến 5 lần tùy thuộc vào loại tài khoản và cấu hình), Make sẽ tự động chuyển trạng thái của scenario đó thành “Disabled” (tắt luồng).

Tôi thường gọi đây là cơ chế “phanh khẩn cấp”. Nó ngăn chặn việc luồng tự động chạy lặp đi lặp lại và tiêu tốn hết lượng transfer (hoặc operation) của bạn vào một tác vụ vô nghĩa, hoặc tệ hơn là ghi đè dữ liệu lỗi vào hệ thống CRM. Nhưng mặt trái là nó khiến toàn bộ quy trình kinh doanh bị gián đoạn hoàn toàn cho đến khi có người vào bật lại luồng thủ công.

Các loại lỗi phổ biến nhất trong vận hành

Trong quá trình vận hành thực tế, lỗi phát sinh thường chia làm ba nhóm chính:
– Lỗi kết nối và mạng (connection & network errors): API của bên thứ ba bị sập tạm thời, mất kết nối internet giữa các máy chủ, hoặc máy chủ đích phản hồi quá chậm dẫn đến lỗi Timeout.
– Lỗi dữ liệu đầu vào (data validation errors): Một trường thông tin bắt buộc trong CRM bị bỏ trống, hoặc khách hàng nhập sai định dạng email, số điện thoại khiến API từ chối xử lý (thường trả về mã lỗi 400 Bad Request).
– Lỗi giới hạn lượt gọi (rate limit errors): Khi bạn gửi quá nhiều yêu cầu cùng một lúc, các nền tảng như Google Sheets, Facebook API hay OpenAI sẽ chặn lại và trả về lỗi 429 Too Many Requests.

Các công cụ xử lý lỗi mặc định trên Make bạn cần biết

Make cung cấp một bộ công cụ cực kỳ mạnh mẽ gọi là các “error handling directives”. Đây là các khối lệnh đặc biệt giúp bạn định tuyến luồng xử lý khi có lỗi xảy ra ở một module bất kỳ. Bạn có thể tìm thấy các khối này bằng cách chuột phải vào module và chọn “Add error handler”.

graph TD
    A[Module gặp lỗi] --> B{Có Error Handler không?}
    B -- Không --> C[Dừng luồng & Tắt scenario sau vài lần lỗi]
    B -- Có --> D{Chọn Directive nào?}
    D --> E[Ignore]
    D --> F[Resume]
    D --> G[Rollback]
    D --> H[Commit]
    D --> I[Break]
    E --> J[Bỏ qua lỗi, chạy tiếp module sau]
    F --> K[Cung cấp dữ liệu thay thế, chạy tiếp]
    G --> L[Hủy bỏ toàn bộ các bước trước đó nếu hỗ trợ]
    H --> M[Chấp nhận kết quả hiện tại và dừng luồng an toàn]
    I --> N[Tạm dừng luồng, lưu vào queue để thử lại sau]

Để tránh gặp phải lỗi error handling trên make ngoài ý muốn, tôi khuyên bạn nên nắm lòng chức năng của 5 directive cốt lõi dưới đây:

Directive Ignore và Resume

• Ignore (Bỏ qua): Đúng như tên gọi, chỉ thị này sẽ bỏ qua hoàn toàn lỗi vừa xảy ra và tiếp tục thực hiện các module phía sau trong luồng. Tuy nhiên, các giá trị đầu ra (output) của module bị lỗi sẽ bị bỏ trống. Directive này cực kỳ hữu ích khi tác vụ bị lỗi không quá quan trọng, ví dụ như gửi thông báo log nội bộ thất bại nhưng dữ liệu khách hàng vẫn cần được ghi vào CRM.
• Resume (Tiếp tục với dữ liệu thay thế): Đây là một phiên bản nâng cấp của Ignore. Nó không chỉ bỏ qua lỗi mà còn cho phép bạn tự định nghĩa một giá trị đầu ra giả lập (mock data) để các module phía sau sử dụng. Ví dụ, nếu bước tìm kiếm khách hàng bị lỗi và không trả về ID, bạn có thể dùng Resume để gán một ID mặc định là “Khách hàng vãng lai” nhằm đảm bảo luồng không bị gãy nửa chừng.

Directive Rollback và Commit

• Rollback (Hoàn tác): Khi xảy ra lỗi, directive này sẽ cố gắng đưa trạng thái dữ liệu về ban đầu trước khi luồng chạy (chỉ áp dụng với các module có hỗ trợ cơ chế transaction như một số cơ sở dữ liệu SQL). Nếu không hỗ trợ, nó hoạt động tương tự như việc dừng luồng lập tức.
• Commit (Xác nhận): Directive này chấp nhận tất cả các thay đổi dữ liệu đã được thực hiện bởi các module trước đó và dừng luồng một cách êm đẹp (không báo đỏ scenario). Nó thường được dùng khi bạn muốn dừng luồng sớm vì một điều kiện logic nào đó không đáp ứng được nhưng không muốn hệ thống coi đó là một lỗi kỹ thuật.

Directive Break – Cứu cánh cho lỗi tạm thời

Đây là directive quan trọng nhất mà tôi khuyên mọi người nên dùng khi xử lý các lỗi mạng hoặc giới hạn API (rate limit). Khi gặp lỗi, Break sẽ chụp lại trạng thái hiện tại của luồng dữ liệu, lưu vào một bộ nhớ đệm (queue) và tự động thử lại (retry) sau một khoảng thời gian bạn thiết lập trước (ví dụ: sau 10 phút, thử lại tối đa 3 lần).

Nếu sau các lần thử lại mà vẫn lỗi, lúc này Make mới chính thức gửi thông báo lỗi và dừng luồng. Cách xử lý này giúp giảm đến 90% số lần sập luồng do mất mạng đột ngột hoặc quá tải máy chủ ở bên thứ ba.

Hướng dẫn từng bước thiết lập lỗi error handling trên make thực chiến

Để giúp bạn dễ dàng hình dung, tôi sẽ hướng dẫn thiết lập một luồng xử lý lỗi thực tế: Gửi thông tin khách hàng từ Zalo webhook vào hệ thống CRM (như HubSpot). Nếu HubSpot bị lỗi (do trùng data hoặc lỗi server), hệ thống sẽ tự động bắt lỗi, gửi cảnh báo về Telegram và ghi nhận lịch sử lỗi vào Google Sheets để kiểm tra sau.

Bước 1: Thêm nhánh xử lý lỗi (error handler) vào module

Tại giao diện thiết kế scenario của Make, bạn tìm đến module có nguy cơ lỗi cao (ở đây là module HubSpot “Create a Contact”).

1. Nhấp chuột phải vào module HubSpot.
2. Chọn Add error handler từ menu ngữ cảnh.
3. Một nhánh phụ màu xám sẽ xuất hiện ngay bên dưới module này. Tại đây, Make sẽ hiển thị danh sách các directive hoặc bạn có thể kết nối với các module thông thường khác để tự xây dựng logic xử lý riêng.

Bước 2: Cấu hình module ghi nhận lỗi và thông báo

Thay vì chỉ chọn một directive đơn giản như Ignore, tôi thường xây dựng một luồng phụ để tôi biết chính xác chuyện gì đang xảy ra:

1. Kết nối một module Google Sheets (Add a Row) vào nhánh error handler mới tạo.
2. Trong file Google Sheets, tạo các cột: Thời gian, Tên scenario, Module bị lỗi, Chi tiết lỗi (Error Message), Dữ liệu đầu vào.
3. Map các thông tin lỗi hệ thống từ module HubSpot sang Google Sheets. Bạn có thể sử dụng các biến hệ thống của Make như {{error.message}}, {{error.type}} để ghi lại lý do lỗi chi tiết.
4. Tiếp tục kết nối thêm một module Telegram (Send a Message) hoặc Zalo để gửi cảnh báo trực tiếp cho đội ngũ kỹ thuật kèm link trực tiếp đến lượt chạy bị lỗi đó.

Bước 3: Đóng luồng xử lý lỗi bằng directive phù hợp

Sau khi đã ghi nhận lỗi và gửi thông báo thành công, bạn bắt buộc phải dùng một directive để kết thúc nhánh lỗi này. Nếu bạn không kết thúc bằng một directive xử lý lỗi (như Ignore hoặc Resume), Make vẫn sẽ coi lượt chạy này là thất bại và tích lũy điểm lỗi để tắt luồng của bạn.

1. Kết nối directive Resume (hoặc Ignore) vào cuối nhánh xử lý lỗi.
2. Cấu hình giá trị trả về mặc định nếu cần thiết để các module tiếp theo (nếu có) vẫn có thể chạy tiếp mà không bị lỗi thiếu dữ liệu đầu vào.

[!IMPORTANT] Khi thiết lập các luồng tự động hóa chạy nền liên tục với khối lượng dữ liệu lớn, việc cài đặt error handling không chỉ là một tính năng phụ, mà nó là điều kiện sống còn để đảm bảo tính ổn định của toàn bộ hệ thống.

Tối ưu hóa luồng với Make.com và các công cụ bổ trợ

Xử lý lỗi thủ công cho từng module đôi khi rất mất thời gian nếu scenario của bạn có hàng chục bước. Để tối ưu hóa quy trình, bạn cần áp dụng các tư duy thiết kế hệ thống thông minh hơn.

Để tìm hiểu sâu hơn về lý do tại sao các doanh nghiệp lại chọn nền tảng này làm xương sống cho hệ thống vận hành của họ, bạn có thể đọc bài phân tích chi tiết của tôi về 5 lý do doanh nghiệp SMEs Việt Nam bắt buộc phải dùng Make.com.

Ngoài ra, khi hệ thống tự động hóa của bạn phát triển phức tạp hơn, có thể bạn sẽ cần tích hợp các AI Agent để xử lý các dữ liệu không cấu trúc trước khi đưa vào luồng chính, nhằm giảm thiểu tối đa các lỗi về định dạng dữ liệu đầu vào.

Để có một cái nhìn toàn diện hơn về các kỹ thuật nâng cao, hãy tham khảo bài viết chi tiết của tôi về cách xử lý lỗi (error handling) chuyên nghiệp trong make.com để tránh sập hệ thống.

Hộp đăng ký tài khoản hỗ trợ tối ưu luồng tự động

Nếu bạn chưa có tài khoản hoặc đang sử dụng gói miễn phí giới hạn, hãy đăng ký qua liên kết đối tác chính thức dưới đây của Để AI Tính để nhận được các ưu đãi tốt nhất và hỗ trợ trực tiếp từ tôi khi thiết lập các luồng xử lý phức tạp.

Để tham khảo chi tiết hơn về các tài liệu kỹ thuật chính thức liên quan đến xử lý lỗi, bạn có thể truy cập trực tiếp trang hỗ trợ của họ tại Make Help Center để cập nhật những thay đổi mới nhất về chính sách quản lý lỗi của hệ thống.

4 lưu ý vàng khi xử lý lỗi trên Make tránh mất tiền oan

Dưới đây là những kinh nghiệm xương máu mà tôi đã rút ra sau nhiều dự án triển khai thực tế. Việc áp dụng đúng không chỉ giúp luồng chạy ổn định mà còn tiết kiệm hàng triệu đồng chi phí vận hành hàng tháng.

Tránh vòng lặp vô hạn (infinite loop)

Khi bạn sử dụng directive Break hoặc thiết lập luồng tự động chạy lại khi có lỗi, hãy cực kỳ cẩn thận. Nếu module của bạn lỗi do dữ liệu đầu vào sai định dạng (ví dụ: email thiếu chữ @), việc thử lại 100 lần vẫn sẽ thất bại. Mỗi lần thử lại như vậy sẽ tiêu tốn của bạn 1 operation. Nếu chạy liên tục, tài khoản của bạn sẽ hết sạch dung lượng chỉ sau một đêm.
– Giải pháp: Chỉ dùng tự động thử lại (Break) cho các lỗi mang tính chất tạm thời như lỗi 500, lỗi 429 hoặc lỗi Timeout. Với lỗi dữ liệu đầu vào (400, 403), hãy dùng Ignore hoặc Resume để chuyển hướng xử lý lỗi sang luồng cảnh báo ngay lập tức.

Sử dụng bộ lọc filter hợp lý trước khi xử lý

Không phải lỗi nào cũng cần xử lý như nhau. Trên nhánh error handler, bạn có thể thiết lập các bộ lọc (filter) dựa trên mã lỗi (error code) hoặc thông điệp lỗi (error message).
– Tạo một filter chỉ bắt các lỗi kết nối để gửi vào nhánh Break (thử lại sau).
– Tạo một filter khác bắt các lỗi dữ liệu để gửi cảnh báo trực tiếp về nhóm chat hỗ trợ sửa tay.

Kiểm tra lịch sử chạy (history) thường xuyên

Không có hệ thống xử lý lỗi nào là hoàn hảo mãi mãi. Hãy thiết lập thói quen kiểm tra mục “History” của scenario hàng tuần. Việc xem các biểu đồ lượt chạy lỗi sẽ giúp bạn nhận diện các mẫu lỗi lặp đi lặp lại để tối ưu hóa lại kịch bản, tăng độ bền bỉ cho toàn bộ hệ thống.

Các câu hỏi thường gặp về xử lý lỗi trên Make