Workflow Orchestration trong Bee CRM: Transactional Outbox, Idempotency, Human Approval và Saga cho luồng có side effect

CRM record không phải workflow engine

Một automation đơn giản có thể bắt đầu từ điều kiện “lead mới thì phân công sales”. Khi luồng thêm enrichment API, chấm điểm, kiểm tra policy, chờ quản lý duyệt, tạo task, gửi thông báo và xác minh hệ thống nhận cuối cùng, việc chỉ quan sát vài field trên CRM trở nên mong manh. Không biết rõ flow đang kẹt ở bước nào, đã retry bao nhiêu lần, ai duyệt hay downstream đã nhận side effect chưa.

Thiết kế bền vững tách ba khái niệm. Command là yêu cầu hành động như AssignLead. Event là sự việc đã xảy ra như LeadAssigned. Workflow state là trạng thái điều phối như awaiting_compliance_review. Bee CRM lưu business outcome mà đội vận hành cần nhìn. Engine điều phối lưu vòng đời thực thi, deadline và bằng chứng cần để khôi phục sau lỗi.

Lead mới
  │
  ├─▶ Validate + dedupe
  ├─▶ Enrich + score
  ├─▶ Policy check
  ├─▶ Human approval nếu vượt ngưỡng rủi ro
  ├─▶ Assign owner + create CRM task
  ├─▶ Notify
  ├─▶ Verify downstream state
  └─▶ Close hoặc compensate

Lớp 1. Transactional outbox: không để update và publish sống hai đời riêng

Dual-write là lỗi kinh điển: transaction cập nhật CRM projection thành công nhưng publish event thất bại, hoặc event đã đi nhưng transaction bị rollback. Transactional outbox ghi business change và outbox record trong cùng transaction. Một publisher độc lập đọc outbox, phát event và đánh dấu tiến trình. Khi publisher bị chết sau khi phát nhưng trước khi đánh dấu, event có thể phát lại. Đó là lý do outbox giảm inconsistency, không tạo exactly-once magic.

Idempotency key phải đại diện cho business intent, không chỉ cho một HTTP request. Ví dụ lead:{leadId}:assign:{assignmentVersion} giúp consumer biết đây là cùng ý định phân công kể cả request bị retry từ worker khác. HTTP method idempotent cũng không tự làm side effect downstream idempotent. Key cần đi cùng persistence, TTL hợp lý, kết quả thực thi và semantic version của intent.

Lớp 2. Retry, approval và deadline là state bền vững

Workflow cần per-step timeout, workflow deadline, max attempts, exponential backoff, jitter, DLQ và đường redrive có kiểm soát. Retry chỉ phù hợp với lỗi transient như dependency tạm unavailable. Lỗi business, policy hoặc authorization cần kết thúc có lý do rõ ràng hoặc đưa vào manual queue. Đừng để một lead bị từ chối consent liên tục bị worker đánh thức mỗi vài giây.

Human approval là boundary bảo vệ, không phải dấu hiệu automation thất bại. Các thay đổi owner quan trọng, outbound có cam kết, cập nhật dữ liệu nhạy cảm hoặc action do AI đề xuất vượt ngưỡng rủi ro nên pause workflow bằng durable signal. Approval payload phải có record tác động, thay đổi đề xuất, evidence, confidence, policy version, reviewer, expiry và escalation. Polling CRM liên tục để đoán quản lý đã duyệt hay chưa tạo độ trễ, tải vô ích và không có audit rõ ràng.

Lớp 3. Saga và compensation khi side effect không nằm chung transaction

Không có ACID transaction xuyên Bee CRM, provider nhắn tin, ERP và hệ thống lịch ngoài. Saga điều phối một chuỗi local transaction, theo dõi bước nào thành công và chạy compensating action khi cần. Nhưng compensation không đồng nghĩa rollback tuyệt đối. Email đã gửi không thể thu hồi bằng một database update; biện pháp đúng có thể là suppress chiến dịch tiếp theo, tạo case ưu tiên hoặc gửi thông báo đính chính theo policy đã phê duyệt.

• Thiết kế compensation trước khi bật side effect, nhất là action tài chính, lịch hẹn và outbound communication.
• Lưu workflow_id, run_id, step, attempt, input_version, policy_version và correlation ID ở mọi boundary.
• Xác minh state downstream sau thao tác quan trọng. Thành công HTTP không luôn đồng nghĩa business state đúng.
• Đưa task quá deadline, retry exhaustion và DLQ tăng liên tục vào alert theo business impact, không chỉ theo CPU hoặc memory.

Lớp 4. Observability theo business deadline

Mỗi workflow run nên trace xuyên từ interaction event tới CRM write, notification và callback bằng trace_id, correlation_id và workflow_id. Metrics vận hành gồm success rate, end-to-end latency p50/p95, retry exhaustion, duplicate suppression, stuck approval, DLQ age, write error, completion after deadline và compensation rate. Trace giúp điều tra một case. Metrics cho biết xu hướng. Audit log nói ai đã phê duyệt hoặc đảo quyết định.

Các kiến trúc này là nền cho luồng có thể cấu hình trong Bee CRM, từ follow-up lead tới đặt lịch và đồng bộ với CRM sẵn có. Bắt đầu nên là một luồng có side effect rõ ràng, policy đã được business owner duyệt và tiêu chí thành công đo được, không phải một chuỗi webhook fire-and-forget phủ toàn bộ doanh nghiệp.

Lớp 5. Thiết kế workflow có thể khôi phục sau deploy, restart và thay đổi rule

Workflow dài có thể sống qua nhiều deploy, worker restart và thay đổi business rule. Vì vậy input của từng run phải được version hóa, không phụ thuộc ngầm vào code hiện tại. Một run khởi tạo với policy version A cần giữ policy A hoặc được migrate tường minh; không nên đang chờ approval thì vô tình áp rule B mới chỉ vì service vừa deploy. Tương tự, payload event nên có schema version để consumer mới vẫn xử lý được event cũ hoặc biết chắc khi nào phải quarantine.

Recovery cần có quyết định hữu hạn. Worker phải đọc persistent state để biết step đã complete, pending hay timed out; không suy ra chỉ từ log. Với mỗi step, runbook nên nêu retry được không, retry bao lâu, check downstream state ở đâu, ai có quyền redrive và compensation nào còn hợp lệ. Điều này đặc biệt quan trọng khi side effect đã làm thay đổi lịch hẹn hoặc thông báo cho khách. Re-run toàn workflow có thể tạo duplicate hoặc đảo thứ tự business intent.

Lớp 6. Phân quyền cho automation không giống phân quyền cho người dùng

Service account chạy workflow không nên có quyền quản trị mọi record chỉ vì workflow cần làm việc nhanh. Mỗi integration cần scope theo action và tenant, secret rotation, audit identity và giới hạn rate. Khi tool do AI đề xuất gọi, policy engine xác thực action against allowlist, schema, record scope và business rule trước khi service account nhận lệnh. Tách quyền đề xuất, quyền phê duyệt và quyền thực thi làm giảm tác động của prompt injection, config sai hoặc lỗi routing.

Với outbound communication, ngoài permission kỹ thuật còn có ownership business: template ai duyệt, mục đích nào được gửi, thời gian nào không gửi, frequency cap bao nhiêu, unsubscribe xử lý ra sao. Workflow engine có thể đảm bảo bước được thực thi nhất quán, nhưng không thể tự quyết định rule đó có đúng với doanh nghiệp hay pháp lý hay không. Rule phải thuộc về owner xác định, có version và review cycle.

Lớp 7. Test theo failure mode trước khi mở rộng automation

Test unit cho decision logic là cần nhưng chưa đủ. Cần scenario test chứa duplicate event, out-of-order event, provider 429, callback mất, downstream success nhưng response timeout, approval hết hạn, policy bị rút giữa workflow và manual CRM edit. Mỗi scenario phải có expected business state cuối cùng, audit trail và cách operator can thiệp. Đây là các golden workflow cases, tương tự golden set cho RAG nhưng tập trung vào transition và side effect.

Một rollout hợp lý bắt đầu bằng shadow hoặc dry run: workflow tính decision, ghi trace và đề xuất task nhưng chưa tự side effect. Sau khi đối chiếu với xử lý thực tế, phạm vi automation chỉ mở cho action có precision, override rate và reconciliation lag đạt ngưỡng mà business owner chấp nhận. Các chỉ số đó phải báo theo action, tenant và cohort, không gộp thành một tỷ lệ thành công đẹp nhưng che lỗi ở luồng rủi ro cao.

“Tự động hóa đáng tin không được đo bằng số bước chạy không có người. Nó được đo bằng khả năng giải thích, khôi phục và sửa đúng khi hệ thống ngoài không hoàn hảo.”