Theo dõi báo cáo thực thi Adaflow và xử lý luồng bị lỗi
Báo cáo thực thi Adaflow giúp kiểm tra lượt chạy, trạng thái từng bước và dữ liệu được truyền trong quy trình tự động.
Báo cáo thực thi Adaflow giúp kiểm tra lượt chạy, trạng thái từng bước và dữ liệu được truyền trong quy trình tự động.
Khi kết quả chưa đúng, cần xác định sự kiện, phiên chạy và khối liên quan trước khi sửa hoặc chạy lại. Phần hướng dẫn giữ nguyên nội dung và ảnh từ tài liệu gốc.
Vì sao cần theo dõi sau khi xuất bản?
Một luồng đã kiểm thử có thể gặp dữ liệu thiếu, tài khoản tích hợp hết hiệu lực hoặc điều kiện nhân sự thay đổi khi chạy thực tế. Giám sát giúp phát hiện các trường hợp này trước khi việc tồn đọng tăng lên.
Nên xác định người kiểm tra và tần suất phù hợp với mức độ quan trọng của quy trình. Luồng tham gia tiếp nhận khách cần được theo dõi sát hơn những tác vụ ít ảnh hưởng tới người dùng.
Sau xuất bản, luồng tiếp nhận dữ liệu thật có thể gặp những trường hợp chưa xuất hiện trong bài thử. Báo cáo thực thi giúp người vận hành xem một hồ sơ đi qua bước nào và kết quả tại từng bước. Mục tiêu là kiểm tra công việc doanh nghiệp mong muốn có thực sự hoàn tất, không chỉ kiểm tra luồng có thể được bật hay không.
Ví dụ giả định, một luồng tạo công việc tư vấn khi khách đổi trạng thái. Nhóm cần xem công việc có gắn đúng hồ sơ và đúng người phụ trách sau khi chạy. Nếu trạng thái phiên thành công nhưng công việc không đáp ứng yêu cầu, phải rà soát cấu hình nghiệp vụ và dữ liệu; kết quả kỹ thuật không thay thế kết quả sử dụng.
Đọc tổng quan trước, truy vết phiên cụ thể sau
Chỉ số tổng quan giúp nhìn số lượt thành công và lỗi, còn phiên chạy cụ thể cho biết điều gì đã xảy ra với một bản ghi. Hai mức thông tin bổ sung cho nhau, không thay thế nhau.
Nếu chưa thấy dữ liệu, kiểm tra bộ lọc thời gian và sự kiện kích hoạt. Danh sách trống chưa đủ để kết luận hệ thống không hoạt động.
Đọc tổng quan giúp chọn nơi cần kiểm tra, nhưng một tỷ lệ lỗi chưa giải thích được nguyên nhân. Có thể nhiều phiên cùng thiếu một trường hoặc một phiên đang chờ tới thời điểm đã cấu hình. Nên chọn một phiên tiêu biểu trong từng nhóm tình trạng để đọc diễn biến, rồi đối chiếu dữ liệu thực tế.
Ví dụ giả định, nhóm thấy số lượt hoàn tất giảm vào cuối ngày. Cần kiểm tra số phiên mới bắt đầu, các bước có khoảng chờ và khung ngày đang xem trước khi kết luận có sự cố. Báo cáo theo một khoảng thời gian không nên được so với một kỳ khác có lượng đầu vào rất khác mà thiếu giải thích phạm vi.
Tìm nguyên nhân từ đầu vào và đầu ra
Tại bước có vấn đề, đối chiếu dữ liệu đầu vào, kết quả đầu ra và thông báo lỗi. Cần xác định liệu bước trước đã cung cấp đủ thông tin hay bước hiện tại chưa đáp ứng yêu cầu.
Ví dụ giả định: một tác vụ cần số điện thoại nhưng đầu vào thiếu thông tin này. Sửa địa chỉ tích hợp sẽ không giải quyết được lỗi dữ liệu; cần xử lý đúng nguyên nhân tại bước tạo hoặc ánh xạ.
Tìm nguyên nhân nên bắt đầu từ bước đầu tiên có kết quả không phù hợp. Đối chiếu đầu vào của bước đó với kết quả của bước trước, rồi xem yêu cầu cấu hình và thông báo. Việc sửa nhiều khối cùng lúc có thể làm khó xác định điều gì thực sự giải quyết vấn đề.
Ví dụ giả định, bước tạo lịch thiếu email người tham gia. Nhóm kiểm tra dữ liệu có ở hồ sơ hay chưa, giá trị có được truyền đúng và đối tượng được chọn có phù hợp. Nếu thông tin chưa được khách xác nhận, cách xử lý là bổ sung đầu vào trong quy trình. Đây là lỗi nghiệp vụ dữ liệu, khác với một lỗi cấu hình tài khoản kết nối.
Chạy lại có kiểm tra để tránh trùng hành động
Trước khi chạy lại, cần biết bước nào đã hoàn tất và hành động nào có thể lặp. Tạo công việc, thêm khách vào chiến dịch hoặc gửi thông điệp đều có thể ảnh hưởng tới hoạt động thực tế nếu được thực hiện nhiều lần.
Tài liệu có hướng dẫn chạy lại phiên; doanh nghiệp vẫn cần kiểm tra kết quả sau xử lý và lưu thông tin sự cố. Mục tiêu là hoàn tất việc còn thiếu, không chỉ làm trạng thái chuyển sang thành công.
Chạy lại cần được xem như một hành động có thể ảnh hưởng tới dữ liệu và khách hàng. Trước khi thực hiện, xác định những bước đã hoàn tất và những bước còn thiếu. Một bước tạo việc hoặc gửi thông điệp có thể không nên được lặp nếu kết quả trước đó đã tồn tại; kiểm tra cơ chế và thao tác mà phiên bản hỗ trợ.
Sau xử lý, đối chiếu kết quả trên hồ sơ, lưu nguyên nhân và sửa điểm khiến lỗi phát sinh. Nghiên cứu về quy trình dịch vụ năm 2025 nhấn mạnh đánh giá khả năng giải quyết yêu cầu qua tình huống mô phỏng. Nguồn: Choubey và cộng sự, Turning Conversations into Workflows, ACL 2025 Trong vận hành, có thể bổ sung tình huống lỗi vừa gặp vào bộ thử để lần sửa sau không làm mất khả năng xử lý một trường hợp đã được kiểm tra.
Hướng dẫn sử dụng theo tài liệu gốc
Phần dưới giữ nguyên nội dung thao tác và hình ảnh của tài liệu hướng dẫn. Các tên nút và thuật ngữ giao diện được giữ để bạn đối chiếu khi sử dụng.
Nguồn hướng dẫn: Hướng dẫn sử dụng: Theo Dõi Báo Cáo Thực Thi & Xử Lý Sự Cố (Execution Reports).
II. Đọc Hiểu Chỉ Số Tổng Quan Tại Màn Hình Danh Sách
Ngay tại màn hình quản lý danh sách luồng (/dashboard/<company_id>/auto_flow), hệ thống cung cấp các chỉ số vận hành tức thì cho từng quy trình:
Ý Nghĩa Cột “Số lượt chạy”:
- Biểu đồ tròn (Donut Chart):
- Màu xanh dương: Thể hiện tỷ lệ % các phiên chạy hoàn thành trơn tru không lỗi.
- Màu cam: Thể hiện tỷ lệ % các phiên chạy bị lỗi hoặc dừng giữa chừng.
- Văn bản tỷ lệ: Hiển thị dưới dạng
X/Y thành công(Trong đó:Xlà số lượt thành công,Ylà tổng số lượt kích hoạt).- Ví dụ:
85/85 thành công(100% xanh) thể hiện quy trình đang vận hành hoàn hảo. - Nếu hiển thị
0/0 thành công: Luồng mới xuất bản và chưa có sự kiện thực tế nào phát sinh.
- Ví dụ:
III. Màn Hình Báo Cáo Chi Tiết Lịch Sử Thực Thi (Execution Logs)
Đường dẫn truy cập:
- Cách 1: Từ màn hình danh sách luồng, nhấn nút Báo cáo (màu xanh lá) tại dòng luồng cần kiểm tra.
- Cách 2: Từ màn hình Flow Builder, nhấn nút Báo cáo chi tiết trên thanh header trên cùng.
Các Thành Phần Trên Màn Hình Báo Cáo:
- Thanh điều hướng Breadcrumb:
Tự động hoá > Báo cáogiúp định vị nhanh vị trí. - Tiêu đề luồng: Tên quy trình đang được theo dõi (Ví dụ:
Thu-Chia lead - Hằng). - Bộ lọc Ngày bắt đầu ➔ Ngày kết thúc: Cho phép chọn khoảng thời gian cụ thể (Hôm nay, 7 ngày qua, Tháng này, hoặc Tùy chọn) để giới hạn nhật ký tra cứu.
- Nút “Chỉnh sửa flow”: Nhấp để quay trở lại ngay màn hình thiết kế canvas nếu phát hiện quy trình cần điều chỉnh tham số.
IV. Bảng Nhật Ký Phiên Chạy & Phân Tích Từng Bước (Step Trace)
Khi có các phiên thực thi phát sinh trong khoảng thời gian đã chọn, bảng nhật ký sẽ hiển thị chi tiết từng phiên chạy (Run Session):
| Trường Thông Tin | Ý Nghĩa Nghiệp Vụ & Dữ Liệu |
|---|---|
| Mã phiên chạy (Run ID) | Mã chuỗi định danh duy nhất của lượt chạy (Ví dụ: run_9a8f2c1). |
| Thời gian bắt đầu | Ngày giờ chính xác đến từng giây khi Trigger được kích nổ. |
| Thời lượng (Duration) | Tổng thời gian hệ thống xử lý từ node đầu đến node cuối (Ví dụ: 1.2s hoặc 15m 30s nếu có node Chờ). |
| Bản ghi kích hoạt | Tên hoặc ID của đối tượng CRM làm khởi phát luồng (Ví dụ: Khách hàng Nguyễn Văn A). |
| Trạng thái chung | Thành công (Success) (xanh lá), Thất bại (Failed) (đỏ), Đang xử lý (Running) (xanh dương), hoặc Tạm dừng (Paused). |
Xem Chi Tiết Từng Bước (Step-by-Step Execution Trace):
Nhấp chuột vào bất kỳ phiên chạy nào trên bảng để mở cửa sổ phân tích luồng dữ liệu:
- Trực quan hóa trạng thái từng node: Mỗi node trên luồng sẽ có huy hiệu trạng thái tương ứng (Tick xanh nếu chạy thành công, Dấu X đỏ nếu bị lỗi, Icon đồng hồ cát nếu đang trong thời gian chờ).
- Kiểm tra Payload Đầu vào (Input Data): Xem chính xác dữ liệu mà node đó nhận được từ bước trước (Ví dụ: Tên, Số điện thoại, ID đơn hàng).
- Kiểm tra Kết quả Đầu ra (Output Data): Xem dữ liệu mà node vừa sinh ra hoặc phản hồi từ hệ thống ngoài (Ví dụ: HTTP Response Code 200, Mã cuộc gọi Callbot vừa tạo).
- Thông báo lỗi chi tiết (Error Details): Nếu một node bị thất bại, hệ thống sẽ trích xuất chính xác thông báo lỗi kỹ thuật (Ví dụ:
Phone number is required,Invalid JSON format,Connection timeout).
V. Ma Trận Xử Lý Sự Cố Thường Gặp (Troubleshooting Matrix)
Bảng ma trận 3 cột chuẩn mực dưới đây tổng hợp các sự cố vận hành thường gặp nhất và giải pháp xử lý triệt để:
| Hiện tượng lỗi / Thông báo | Nguyên nhân cốt lõi | Hướng dẫn khắc phục cụ thể |
|---|---|---|
| Trạng thái phiên báo “Thất bại” tại Node Callbot | 1. Số điện thoại của khách hàng không đúng định dạng (thiếu số, chứa ký tự chữ). 2. Chiến dịch Callbot đã hết hạn mức số phút gọi hoặc đang bị Tắt. |
1. Thêm một node Rẽ nhánh điều kiện phía trước để kiểm tra tính hợp lệ của số điện thoại. 2. Vào phân hệ Chiến dịch Callbot, kiểm tra số dư phút gọi và bật lại chiến dịch sang trạng thái Đang chạy. |
| Phiên chạy bị kẹt ở trạng thái “Đang xử lý” quá lâu | Luồng đang đi qua một node Hẹn giờ (Delay) có cấu hình thời gian chờ kéo dài (Ví dụ: chờ 24 giờ hoặc 3 ngày). | Đây là hành vi hoàn toàn bình thường của hệ thống. Kiểm tra cấu hình thời gian của node Hẹn giờ; phiên chạy sẽ tự động tiếp tục và hoàn tất khi hết thời gian đếm ngược. |
| Node HTTP Request báo lỗi “401 Unauthorized” | Khóa xác thực API (API Key, Bearer Token) trong Header đã hết hạn hoặc bị đổi mật khẩu trên hệ thống bên thứ ba. | Vào tab Cài đặt của node HTTP Request, cập nhật lại chuỗi Token xác thực mới nhất vào mục Headers, sau đó bấm Kiểm thử lại kết nối. |
| Node Gán nhân viên báo lỗi “No eligible user found” | Toàn bộ nhân sự trong danh sách phân bổ đều đang bật trạng thái ngoài ca trực hoặc vượt quá định mức Lead cho phép. | Mở cấu hình node Gán nhân viên, bổ sung thêm tài khoản dự phòng hoặc nới lỏng giới hạn số lượng lead tiếp nhận tối đa trong ngày. |
| Báo cáo không hiển thị bất kỳ dòng dữ liệu nào | Bộ lọc thời gian mặc định chưa bao gồm thời điểm phát sinh sự kiện, hoặc luồng chưa được kích hoạt lần nào. | Mở rộng khoảng ngày trong bộ lọc Ngày bắt đầu ➔ Ngày kết thúc; thực hiện tạo một bản ghi thử nghiệm trên CRM để kích hoạt luồng. |
Câu hỏi thường gặp
Không thấy phiên chạy cần kiểm tra gì?
Kiểm tra khoảng ngày, sự kiện kích hoạt và điều kiện luồng trước khi kết luận có lỗi.
Đang xử lý lâu có phải phiên bị kẹt không?
Có thể đang chờ tại khối Hẹn giờ. Đối chiếu thời gian đã cấu hình và nhật ký.
Có nên chạy lại toàn bộ ngay khi thấy lỗi không?
Cần xác định các bước đã hoàn tất và ảnh hưởng của việc lặp trước khi áp dụng hướng dẫn chạy lại.
Để chọn cách triển khai phù hợp, tìm hiểu giải pháp gọi điện tự động UCALL và phần mềm quản lý khách hàng Adahub. Bạn có thể kết hợp cuộc gọi, hồ sơ khách hàng và quy trình chăm sóc theo nhu cầu thực tế của doanh nghiệp.
