---
title: "Automation Action và giới hạn của nó"
url: "https://bahub.vn/khoa-hoc/erp-cho-ba/automation-action-odoo-gioi-han"
author: "Võ Văn Trí"
published: "2026-09-10"
updated: "2026-11-02"
source: "bahub.vn"
license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc."
---

# Automation Action và giới hạn của nó

> Rất nhiều yêu cầu nghe như phải lập trình thực ra giải được bằng automation có sẵn. Bốn dấu hiệu cho biết yêu cầu đã vượt khỏi tầm và phải viết mã.

- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/automation-action-odoo-gioi-han
- Tác giả: Võ Văn Trí
- Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md)
- Chương: Tùy biến và phân quyền

Buổi khảo sát ở một doanh nghiệp dịch vụ kỹ thuật. Phía kinh doanh nêu liền ba mong muốn:

* đơn bán vừa xác nhận thì khách nhận ngay thư xác nhận
* kế toán và thủ kho được đưa vào danh sách theo dõi của đơn
* và ba ngày sau khi gửi báo giá mà khách chưa trả lời thì hệ thống nhắc sale.

Ba dòng đó vào bảng GAP kèm ghi chú cần customize, đội sale nhân với đơn giá ngày công của developer, rồi con số đi thẳng vào báo giá. Hai tuần sau, lúc dựng demo, cả ba được làm xong trong một buổi chiều trên một màn hình cấu hình có sẵn.

> Ước lượng lệch kiểu này thì báo giá bị thổi lên, rồi khách mang đi so với đối thủ. Chiều ngược lại còn đắt hơn, bởi khi BA trót hứa rằng hệ thống tự làm được cho một yêu cầu mà thực ra phải viết mã, thì tới vòng UAT không ai gỡ được lời hứa đó ra khỏi biên bản.

Màn hình đó là **Automation Rules**, bản tiếng Việt gọi là Quy tắc tự động hóa, và trong nghề vẫn quen gọi là Automation Action. Bài này nói nó được kích hoạt bởi cái gì, làm được những hành động nào, và đâu là dấu hiệu cho biết yêu cầu đã vượt tầm của nó. Toàn bộ phần cơ chế trong bài này tôi mô tả trên Odoo 19, và đây là loại nội dung bạn phải dựng lại trên đúng bản mình đang chạy chứ không nên tin theo trí nhớ.

## Chỗ nó nằm và quyền để mở được nó

Chuyện này hay bị nói sai, và nói sai thì kéo theo cả quyết định chọn phiên bản.

**Automation Action không phải tính năng riêng của bản Enterprise.** Module đứng sau nó là `base_automation`, tên hiển thị Automation Rules, nằm ngay trong Community và phát hành theo giấy phép mở; trên Community bạn chỉ cần cài module đó nếu nó chưa được kéo vào cùng một phân hệ khác.

Tài liệu chính thức của Odoo mô tả công cụ này trong phần Studio nên rất dễ hiểu nhầm, và không ít tài liệu hướng dẫn vẫn xếp nó vào bản Enterprise, nhưng Studio chỉ là một trong hai đường vào. Đường còn lại là bật chế độ nhà phát triển rồi đi Settings, Technical, Automation, Automation Rules, và đường này có ở cả hai bản.

Điều kiện thứ hai chặt hơn hình dung của phần lớn người mới. Trên Odoo 19, **quyền trên quy tắc tự động chỉ được cấp cho đúng một nhóm là nhóm quản trị cài đặt**, nghĩa là key user không tự tạo được quy tắc dù bạn đã mở chế độ nhà phát triển cho họ. Do đó nếu doanh nghiệp muốn tự vận hành phần này sau go-live thì phải nói trước rằng người được giao sẽ cầm một quyền rất rộng.

[Ranh giới giữa cấu hình và customize](https://bahub.vn/khoa-hoc/erp-cho-ba/cau-hinh-hay-customize-erp) đã có bài riêng nói đủ; ở đây chỉ cần nhớ Automation Action nằm trọn bên phía cấu hình cho tới khi chạm vào hai thứ nói ở phần sau.

## Năm nhóm sự kiện kích hoạt

Một quy tắc gồm ba tầng nối tiếp nhau: sự kiện khởi chạy, bộ điều kiện lọc, rồi danh sách hành động. Sự kiện kích hoạt được chia thành năm nhóm, và danh sách thực tế hiện ra đổi theo model bạn chọn.

* **Nhóm giá trị được cập nhật** gồm giai đoạn hoặc trạng thái được đặt thành một giá trị cụ thể, người phụ trách được gán, thẻ được thêm, mức ưu tiên được đặt, bản ghi được lưu trữ hoặc bỏ lưu trữ.
* **Nhóm sự kiện thư** gồm khi bản ghi nhận thư đến và khi gửi thư đi.
* **Nhóm điều kiện thời gian** gồm mốc theo một trường ngày bất kỳ, mốc tính từ lúc tạo, và mốc tính từ lần cập nhật cuối.
* **Nhóm tùy chỉnh** gồm khi tạo mới, khi tạo mới và mỗi lần sửa về sau, khi xóa, và khi giá trị trên màn hình bị đổi mà chưa lưu.
* **Nhóm bên ngoài** là webhook.

Cần lưu ý rằng các lựa chọn giai đoạn, trạng thái, thẻ và mức ưu tiên đều bắt buộc chỉ đích danh một giá trị, còn người phụ trách được gán thì không, nên quy tắc sẽ chạy với bất kỳ ai được gán.

![Năm nhóm sự kiện kích hoạt cùng dẫn về một quy tắc tự động](https://bahub.vn/uploads/2026/11/1793631009180-k4hzzw-automation-action-odoo-gioi-han-1.webp "Năm nhóm sự kiện kích hoạt cùng dẫn về một quy tắc tự động")

Tầng điều kiện có hai ô. Ô Apply on mô tả bản ghi phải thỏa gì sau khi sự kiện xảy ra, còn ô Before Update Domain mô tả bản ghi đang ở trạng thái nào ngay trước đó, và ô này chỉ hiện đầy đủ khi bật chế độ nhà phát triển.

Ô thứ hai đáng nhớ hơn, bởi nó giải một bài toán mà không có nó thì phải viết mã: gửi thư xác nhận khi đơn chuyển sang trạng thái đơn hàng, nhưng chỉ với đơn trước đó còn ở trạng thái nháp, để khách đã nhận thư báo giá thì không nhận thêm thư nữa. Tuy nhiên **điều kiện trước không được kiểm khi bản ghi vừa được tạo**.

## Danh sách hành động có sẵn

Danh sách này ngắn hơn nhiều người tưởng, và chính độ ngắn của nó vạch ra ranh giới.

* Bạn cập nhật được một trường trên chính bản ghi hoặc trên bản ghi liên quan qua quan hệ
* tạo bản ghi mới ở model khác rồi gán ngược về nguồn qua một trường liên kết
* nhân bản một bản ghi
* tạo activity giao cho người cụ thể hoặc giao động theo người phụ trách của đơn
* gửi thư theo mẫu
* gửi tin nhắn SMS
* thêm hoặc bớt người theo dõi
* và gọi chạy nhiều hành động khác cùng lúc

Trên bản Enterprise danh sách dài thêm vài lựa chọn như cập nhật trường bằng AI hay gửi tin WhatsApp, cả hai đều phụ thuộc ứng dụng không có trong Community.

> Còn lại đúng hai hành động là thực thi mã và gửi thông báo webhook, và đó chính là ranh giới giữa việc của BA với việc của developer.

## Dấu hiệu thứ nhất: vòng lặp và xử lý theo lô

**Automation Action tác động lên chính những bản ghi đã kích hoạt nó**, không có khái niệm duyệt qua một tập bản ghi khác, không có vòng lặp, và không cộng dồn được kết quả qua nhiều dòng.

Do đó **hễ yêu cầu có chữ với tất cả, từng dòng một, hoặc gom lại rồi, thì bạn nên dừng lại**. Yêu cầu kiểu mỗi tối rà toàn bộ hợp đồng sắp hết hạn rồi tạo bản kê gửi trưởng phòng là việc của một tác vụ theo lịch có mã bên trong. Trong trường hợp các dòng độc lập với nhau thì vẫn lách được bằng một điều kiện thật hẹp, để mỗi bản ghi tự chạy phần của nó, nhưng khi đầu ra là một bản tổng hợp thì không có đường lách.

## Dấu hiệu thứ hai: gọi ra hệ thống ngoài

Hễ dữ liệu phải đi ra khỏi Odoo hoặc đi vào từ bên ngoài, tức đẩy chứng từ sang hệ thống hóa đơn hay nhận trạng thái giao hàng từ nhà vận chuyển, là bạn đang ở vùng tích hợp.

Hệ thống có sẵn hai đầu cho việc này, một sự kiện nhận webhook vào và một hành động bắn webhook ra, nên về kỹ thuật thì cấu hình được. Tuy nhiên chính tài liệu của Odoo khuyến nghị có developer hoặc người làm kỹ thuật tham gia từ lúc quyết định dùng webhook và suốt quá trình triển khai, bởi cấu hình sai có thể làm rối cơ sở dữ liệu và mất thời gian gỡ lại.

> Phần cấu hình thì mười phút, còn phần khiến nó chạy đúng thì không nằm trên màn hình đó.

![Cấu hình webhook mất mười phút, phần khiến nó chạy đúng cần người kỹ thuật](https://bahub.vn/uploads/2026/11/1793631012049-3toxoz-automation-action-odoo-gioi-han-2.webp "Cấu hình webhook mất mười phút, phần khiến nó chạy đúng cần người kỹ thuật")

## Dấu hiệu thứ ba: rẽ nhánh theo dữ liệu ở nhiều bảng

**Ô điều kiện là một bộ lọc chứ không phải một đoạn logic.**

Nó nối các vế bằng và, hoặc, phủ định, đi qua được trường quan hệ, nhưng chỉ trả lời đúng một câu là bản ghi này có thỏa hay không. Vì vậy ngay khi yêu cầu có dạng nếu thế này thì làm A, nếu thế kia thì làm B, còn lại thì làm C, và mỗi nhánh phụ thuộc dữ liệu ở một bảng khác, thì bạn đã ra khỏi vùng cấu hình.

Tách ba quy tắc cho ba nhánh thì về lý thuyết vẫn được, và với hai nhánh rõ ràng thì chấp nhận được. Nhưng từ ba nhánh trở lên với điều kiện chồng lấn nhau, **bạn đang giấu một cây quyết định vào ba màn hình rời nhau**, và người tiếp quản sáu tháng sau phải dò ngược từng quy tắc mới hiểu vì sao một đơn lại đi nhánh này.

## Dấu hiệu thứ tư: chạy trước khi bản ghi được lưu

Yêu cầu dạng vừa gõ vào ô này thì ô kia phải tự đổi ngay, chưa cần bấm lưu, nghe rất nhỏ, nhưng nó là dấu hiệu rõ nhất trong bốn dấu hiệu.

Hệ thống có đúng một lựa chọn cho việc này là sự kiện On UI change, và đi kèm hai ràng buộc: **nó chỉ dùng được với hành động thực thi mã**, và chỉ chạy khi người dùng sửa tay chứ không chạy khi trường bị một quy tắc khác đổi. Ràng buộc thứ nhất nghĩa là yêu cầu này luôn cần developer, không có đường vòng.

Đây cũng là chỗ nên nói thẳng về giới hạn của vai trò. Một người triển khai Odoo lâu năm khi hướng dẫn phần này đã nhấn mạnh rằng BA thường không dùng được hành động thực thi mã và cần dev hỗ trợ, còn mục đích của việc nắm công cụ chỉ là **biết hệ thống làm được gì để tư vấn đúng**. Trên Odoo 19 ràng buộc còn cứng hơn, bởi ô nhập mã chỉ dành cho nhóm quản trị cài đặt, nên tài khoản ngoài nhóm đó sẽ không thấy ô nhập.

## Độ trễ của sự kiện theo thời gian

Còn một giới hạn nữa nằm ngoài bốn dấu hiệu trên, và nó làm hỏng nhiều cam kết nhất.

**Quy tắc theo thời gian không tự chạy đúng vào lúc tới hạn.** Nó chờ một tác vụ theo lịch tên là Automation Rules: check and execute quét qua rồi mới thực thi, và tác vụ này mặc định chạy bốn tiếng một lần.

Điểm tinh tế mà phần lớn tài liệu hướng dẫn chưa nêu là chu kỳ đó không cố định. Khi có một quy tắc thời gian với độ trễ ngắn, hệ thống tự rút chu kỳ quét xuống còn khoảng một phần mười độ trễ đó, chẳng hạn độ trễ ba tiếng thì chu kỳ về mười tám phút, với mức sàn một phút và mức trần bốn tiếng.

Nhưng cơ chế này **chỉ biết rút ngắn chứ không biết nới ra**, và chu kỳ là của cả hệ thống chứ không của riêng quy tắc bạn vừa tạo.

Hệ quả về lâu dài là thêm một quy tắc có độ trễ dài hơn thì chu kỳ vẫn giữ nguyên, và ngay cả khi bạn tắt hết mọi quy tắc theo thời gian thì tác vụ theo lịch vẫn nằm ở chu kỳ ngắn nhất mà nó từng bị kéo xuống, chỉ có điều nó chuyển sang trạng thái không hoạt động. Muốn đưa chu kỳ về lại bốn tiếng thì bạn phải mở tác vụ theo lịch đó ra sửa tay.

![Quy tắc theo thời gian chờ lượt quét định kỳ, không chạy đúng lúc tới hạn](https://bahub.vn/uploads/2026/11/1793631014582-6brrvu-automation-action-odoo-gioi-han-3.webp "Quy tắc theo thời gian chờ lượt quét định kỳ, không chạy đúng lúc tới hạn")

Gói lại cho lúc ngồi với khách: bốn tiếng là mặc định và là mức chậm nhất, nhưng đây vẫn là quét theo lô nên **đừng cam kết mốc phản hồi tính bằng phút**.

Đi kèm là một bẫy vận hành. Sau khi lưu quy tắc theo thời gian, bạn phải mở tác vụ theo lịch đó ra bấm Run manually một lần để đặt lại mốc lần chạy gần nhất, bởi quy tắc chỉ thực thi với những mốc rơi vào khoảng giữa lần chạy trước và lần chạy hiện tại; bỏ bước này thì quy tắc có thể chạy hồi tố lên dữ liệu lịch sử, và thứ bạn nhận được là hàng loạt thư sinh ra cùng lúc.

## Hiệu ứng dây chuyền khi automation chồng nhau

Trong một quy tắc, **các hành động chạy đúng thứ tự bạn xếp**, nên đặt gửi thư trước rồi mới cập nhật trường thì thư mang giá trị cũ.

Giữa các quy tắc thì rối hơn, bởi chúng gọi lẫn nhau. Một quy tắc trên cơ hội tạo ra bản ghi hợp đồng, việc tạo bản ghi đó lại kích hoạt một quy tắc khác trên model hợp đồng, quy tắc này cập nhật một trường trên liên hệ, và trường đó lại đang được một quy tắc thứ ba theo dõi. Giao diện không có chỗ nào cho bạn thấy chuỗi đó.

Rủi ro rõ nhất nằm ở sự kiện tạo mới và mỗi lần sửa. Tài liệu của Odoo yêu cầu phải chọn trường được theo dõi trong ô When updating, nhưng màn hình không chặn bạn để trống, và **để trống thì hành động có thể chạy nhiều lần trên một bản ghi**, tức chạy lại ở mỗi lần bấm lưu.

Cách mô tả thường gặp còn nặng hơn, ở mức chạy lặp vô hạn; trên Odoo 19 hệ thống có đánh dấu những bản ghi mà một quy tắc đã xử lý trong cùng một lượt để quy tắc đó không tự gọi lại chính nó, nên cách nói chính xác là quy tắc chạy lại mỗi lần lưu chứ không phải lặp không dừng.

Thêm một lớp về quyền: trên Odoo 19, **quy tắc được tìm, lọc và thực thi dưới quyền hệ thống chứ không dưới quyền người vừa bấm lưu**, nên đừng giả định người dùng thiếu quyền trên một model thì quy tắc sẽ không chạm được vào model đó.

Vì vậy trước khi đưa một quy tắc lên hệ thống thật, hãy chạy qua danh sách này:

* Đặt tên quy tắc bằng mô tả nghiệp vụ đầy đủ
* Ghi mục đích và cách hoạt động vào tab Notes của quy tắc
* Liệt kê các quy tắc khác chạy trên cùng model và trên model bị chạm tới
* Kiểm ô trường được theo dõi, không để trống
* Thử cả nhánh chạy và nhánh không chạy
* Với quy tắc theo thời gian, bấm chạy tay tác vụ theo lịch trước khi bật

Nếu dự án có yêu cầu rơi vào bốn dấu hiệu trên thì đó không còn là chuyện cấu hình, và lúc đó bài về [nguyên tắc làm toàn bộ bằng code cho cả dự án](https://bahub.vn/khoa-hoc/erp-cho-ba/nguyen-tac-100-phan-tram-code) là thứ nên đọc trước khi quyết định. Cần nói thêm rằng chính công cụ kéo thả đi cùng Automation Action lại hữu dụng nhất ở một giai đoạn sớm hơn nhiều, khi bạn cần dựng một màn hình mẫu để khách nhìn thấy thứ mình đang mô tả.

---

Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/automation-action-odoo-gioi-han — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.
