Điều hướng theo ngưỡng cho phép lưu trữ quy tắc phê duyệt trong bảng theo số tiền, phòng ban hoặc vùng, nên thay đổi chính sách không cần sửa mã.
Quy tắc phê duyệt gắn cứng trong mã có vẻ ổn ban đầu. Một lập trình viên thêm vài điều kiện, luồng chạy, và đội tiếp tục công việc.
Vấn đề xuất hiện khi doanh nghiệp thay đổi. Tài chính tăng giới hạn chi, một vùng áp dụng chính sách khác, hoặc một phòng ban cần thêm người phê duyệt cho một số yêu cầu. Một thay đổi nhỏ giờ trở thành việc sửa logic ứng dụng, kiểm thử và chờ phát hành.
Sự chậm trễ đó tốn kém. Một cập nhật chính sách lẽ ra chỉ mất vài phút có thể kéo dài thành vài ngày nếu phụ thuộc vào công việc kỹ thuật. Trong lúc đó, nhân viên vẫn theo quy tắc cũ, phê duyệt bị tắc và quản lý phải xử lý ngoại lệ qua email hoặc chat.
Các ngoại lệ ẩn làm tình hình tồi tệ hơn. Theo thời gian, đội thêm các quy tắc một lần như 'nếu số tiền trên 5.000 và phòng ban là Sales thì gửi cho Giám đốc A' hoặc 'nếu yêu cầu đến từ châu Âu thì bỏ qua bước này.' Khi những quy tắc đó nằm sâu trong luồng, chỉ vài người mới thấy được.
Rồi những câu hỏi đơn giản trở nên khó trả lời:
Khi không ai xem được toàn bộ tập quy tắc, sai sót xảy ra. Ai đó nghĩ họ đang tuân theo chính sách nhưng ứng dụng vẫn dùng quy tắc cũ. Một quản lý mới nhận yêu cầu họ không nên thấy, trong khi người phê duyệt thực sự bị bỏ ngoài.
Đó là lý do điều hướng theo ngưỡng phù hợp hơn khi chính sách phê duyệt thay đổi thường xuyên. Thay vì coi quy tắc là phần cố định của ứng dụng, bạn lưu chúng dưới dạng dữ liệu doanh nghiệp để có thể xem xét và cập nhật.
Hãy tưởng tượng một chính sách chi tiêu đơn giản. Yêu cầu dưới $1,000 đi tới trưởng nhóm, từ $1,000 đến $10,000 đi tới trưởng phòng, và trên mức đó đi tới bộ phận tài chính. Nếu các giới hạn đó thay đổi tháng tới, doanh nghiệp không nên cần lập trình viên chỉ để các phê duyệt tiếp tục hoạt động.
Mã hóa cứng biến các cập nhật chính sách bình thường thành dự án phần mềm. Đó mới là chi phí thực sự.
Điều hướng theo ngưỡng nghĩa là đường phê duyệt thay đổi dựa trên các giá trị bạn định nghĩa trước. Một ngưỡng đơn giản là một ranh giới, như số tiền lớn hơn $1,000, một yêu cầu từ phòng Tài chính, hoặc một giao dịch thực hiện ở châu Âu.
Thay vì viết những quy tắc đó trực tiếp vào ứng dụng, bạn lưu chúng trong các bảng. Luồng công việc đọc bảng, tìm quy tắc phù hợp và gửi yêu cầu tới người đúng.
Một cấu hình cơ bản có thể trông như sau:
Quy trình giữ nguyên, nhưng các giá trị điều khiển nó có thể thay đổi.
Đây là ý tưởng chính. Logic là phần nói rằng 'kiểm tra bảng quy tắc và chọn khớp đầu tiên.' Dữ liệu chính sách là danh sách quy tắc: khoảng tiền, phòng ban, vùng, người phê duyệt và độ ưu tiên.
Khi logic và chính sách bị trộn, ngay cả một thay đổi nhỏ cũng cần lập trình viên chỉnh sửa luồng. Khi tách biệt, luồng công việc ổn định và chỉ các hàng quy tắc thay đổi.
Ví dụ, nếu Sales ở APAC giờ cần phê duyệt của giám đốc cho số tiền trên $3,000 thay vì $5,000, bạn chỉ cập nhật một hàng trong bảng. Bạn không phải xây lại toàn bộ quy trình phê duyệt.
Điều này dễ quản lý hơn vì chính sách thay đổi thường xuyên hơn cấu trúc quy trình. Đội tái cơ cấu, ngân sách dịch chuyển và vùng có người phụ trách mới. Một bảng xử lý điều đó tốt hơn so với điều kiện gắn cứng trong mã.
Trong một nền tảng no-code như AppMaster, điều này thường có nghĩa là tạo một bảng quy tắc và để quy trình nghiệp vụ kiểm tra bảng đó khi chạy. Mô hình dễ hiểu cho đội không chuyên vì giống cách viết chính sách trong thực tế: nếu điều kiện này khớp thì gửi tới đây.
Một bảng quy tắc tốt trả lời một câu hỏi đơn giản: khi một yêu cầu khớp các điều kiện này thì ai cần phê duyệt?
Nếu định tuyến phụ thuộc vào giá trị ẩn trong mã, mọi cập nhật chính sách thành một lần xây dựng lại. Một bảng giữ các thay đổi đó công khai và dễ quản lý hơn.
Bảng quy tắc thực tế thường bắt đầu với các trường mô tả yêu cầu:
Số tiền và loại tiền quan trọng vì cùng một con số có thể mang ý nghĩa khác nhau theo ngân sách hoặc quốc gia. Yêu cầu 5,000 USD có thể theo một đường, trong khi 5,000 EUR hoặc 500,000 JPY có thể theo đường khác.
Phòng ban và vùng phản ánh cách các công ty thực sự hoạt động. Tài chính, HR và Operations thường có đường phê duyệt khác nhau ngay cả với cùng mức chi. Vùng cũng quan trọng khi luật địa phương hoặc người quản lý khác nhau.
Loại yêu cầu là bộ lọc hữu ích khác. Đi công tác, mua phần mềm, thanh toán nhà cung cấp và duyệt giảm giá có thể cần người xét khác nhau. Nếu thiếu trường này, những yêu cầu không liên quan có thể dùng cùng quy tắc.
Với người phê duyệt, lưu vai trò thay vì tên cá nhân. Dùng giá trị như Department Manager, Regional Director, hoặc Finance Controller. Khi ai đó đổi vị trí, bạn cập nhật ánh xạ vai trò một lần thay vì sửa mọi quy tắc.
Cũng nên thêm ngày bắt đầu và kết thúc. Điều này phù hợp cho chính sách bắt đầu vào một ngày nhất định, quy tắc tạm trong mùa ngân sách, hoặc thay đổi dự kiến cho quý tới. Bạn giữ lịch sử mà không để quy tắc hết hạn vẫn được áp dụng.
Một trường ưu tiên cũng đáng thêm vào. Một quy tắc như 'EU + Finance + trên 10,000' thường nên thắng quy tắc rộng hơn như 'tất cả phòng ban + trên 10,000.' Độ ưu tiên rõ ràng giữ cho việc định tuyến có thể dự đoán được.
Giữ cấu trúc đơn giản: một hàng tương ứng một quy tắc phê duyệt.
Nếu chi phí marketing trên $2,000 ở châu Âu cần quản lý vùng, đó nên là một bản ghi. Khi mỗi hàng có ý nghĩa rõ ràng, việc cập nhật, kiểm thử và kiểm toán dễ hơn.
Bảng chính nên tập trung vào hai thứ: các điều kiện kích hoạt quy tắc và kết quả nói luồng phải làm gì tiếp theo. Điều này giúp người dùng doanh nghiệp và người xây luồng đều dễ đọc.
Một bảng sạch thường bao gồm các trường sau:
Với các cột điều kiện, dùng trường chính xác thay vì nhập tự do khi có thể. Một department ID an toàn hơn so với gõ 'Finance' mỗi lần. Điều tương tự áp dụng cho mã vùng, loại yêu cầu và mã cost center. Bảng tra cứu nhỏ cho phòng ban, vùng và vai trò giúp tránh lỗi chính tả và dễ lọc hơn.
Với cột kết quả, quyết định luồng nên trả về gì. Một số đội để quy tắc trỏ tới một người cụ thể. Những đội khác định tuyến tới vai trò như Regional Manager hoặc Finance Director. Chọn một cách và giữ nhất quán.
Ưu tiên quan trọng vì có thể hơn một quy tắc khớp cùng yêu cầu. Đừng dựa vào thứ tự hàng hay ngày tạo. Thêm trường ưu tiên số và định nghĩa cách hoạt động, ví dụ 1 kiểm tra trước và 100 kiểm tra sau.
Bạn cũng cần quy tắc dự phòng. Đây là lưới an toàn cho bất cứ thứ gì không được bao phủ bởi hàng cụ thể. Quy tắc mặc định có thể gửi yêu cầu không khớp tới một quản lý vận hành hoặc hàng đợi rà soát admin. Nếu không có, yêu cầu có thể bị kẹt mà không có đường đi.
Nếu xây trong AppMaster, các bảng này có thể chỉnh sửa bằng giao diện, nên thay đổi chính sách diễn ra ở dữ liệu thay vì các nhánh luồng cứng.
Bắt đầu từ quyết định, không phải bảng. Ghi rõ các câu hỏi luồng cần trả lời. Một mua sắm trên $5,000 có cần quản lý duyệt không? Tài chính có xem mọi thứ từ Sales không? Yêu cầu từ vùng này đi theo đường khác không?
Khi những lựa chọn đó rõ ràng, điều hướng theo ngưỡng trở nên dễ vì bạn đang lưu chính sách thay vì đoán logic sau này.
Một thiết lập đơn thường gồm năm bước.
Đầu tiên, tạo một bảng quy tắc phê duyệt với các trường ảnh hưởng tới định tuyến. Các cột phổ biến gồm amount_min, amount_max, department, region, approver_role, priority và active_status.
Thứ hai, quyết định trường nào có thể để trống. Một department hoặc region trống có thể nghĩa là 'quy tắc này áp dụng cho tất cả' khi không có khớp cụ thể hơn.
Thứ ba, thêm quy tắc từ cụ thể nhất tới chung nhất. Quy tắc 'Sales + Europe + trên 10,000' nên được kiểm trước quy tắc rộng như 'bất kỳ phòng ban + bất kỳ vùng + trên 10,000.'
Thứ tư, kiểm thử với ví dụ thực trước khi ra mắt. Dùng các trường hợp biên như đúng $5,000, dữ liệu phòng ban thiếu, hoặc vùng không có quy tắc tùy chỉnh.
Thứ năm, giới hạn người có quyền chỉnh sửa bảng. Thay đổi chính sách nên dễ nhưng không ai cũng có thể làm.
Đây là ví dụ đơn giản. Một yêu cầu $12,000 từ HR ở Bắc Mỹ có thể khớp quy tắc 'HR trên $10,000' trước, gửi tới Giám đốc HR. Nếu không có quy tắc HR, hệ thống rơi về quy tắc rộng hơn như 'bất kỳ phòng ban trên $10,000' và gửi tới tài chính.
Thứ tự quan trọng hơn nhiều đội nghĩ. Nếu quy tắc chung đứng trước quy tắc cụ thể, yêu cầu sẽ tới người sai và mọi người mất niềm tin vào hệ thống.
Trước khi ra mắt, chỉ định một người chịu trách nhiệm thay đổi quy tắc, giữ tài liệu ngắn gọn về chính sách và kiểm thử lại sau mỗi cập nhật. Thay đổi nhỏ về định tuyến có thể gây hậu quả lớn.
Hãy tưởng tượng một công ty dùng một mẫu yêu cầu mua cho mọi đội. Mỗi yêu cầu bao gồm số tiền, phòng ban và vùng. Hệ thống kiểm giá trị đó với bảng quy tắc và chọn người phê duyệt.
Giả sử công ty có hai phòng ban, Marketing và IT. Cả hai có thể gửi yêu cầu $4,000, nhưng đường phê duyệt không nhất thiết giống nhau.
| Department | Region | Amount range | Approver |
|---|---|---|---|
| Marketing | US | $0 to $5,000 | Marketing Manager |
| Marketing | US | $5,001+ | Finance Director |
| IT | US | $0 to $3,000 | IT Manager |
| IT | US | $3,001+ | CTO |
| Marketing | EU | $0 to $5,000 | Regional Marketing Lead |
So sánh hai yêu cầu cùng mức tiền. Yêu cầu Marketing $4,000 ở US đi tới Marketing Manager. Yêu cầu IT $4,000 ở US bỏ qua IT Manager và đi tới CTO, vì IT có ngưỡng thấp hơn.
Vùng cũng thay đổi kết quả. Một yêu cầu Marketing $2,500 ở US đi tới Marketing Manager, nhưng cùng mức ở EU đi tới Regional Marketing Lead. Mẫu đơn giữ nguyên. Chỉ quy tắc khớp thay đổi.
Đó là giá trị thực sự của bảng quy tắc. Chính sách sống trong dữ liệu, không nằm trong logic luồng.
Nếu công ty cập nhật chính sách tháng sau, bạn không cần xây lại quy trình. Nếu IT quyết định yêu cầu trên $2,000 giờ phải tới CTO, bạn chỉ sửa một hàng:
Mọi thứ khác tiếp tục hoạt động. Yêu cầu mới theo chính sách mới ngay lập tức trong khi cấu trúc app không thay đổi.
Phần khó nhất của điều hướng theo ngưỡng thường không phải ý tưởng cốt lõi. Là các trường hợp méo mó xuất hiện sau này, khi chính sách thay đổi và không ai nhớ vì sao yêu cầu đến sai người.
Một sai lầm phổ biến là có các quy tắc chồng chéo mà không có ưu tiên rõ ràng. Bạn có thể có quy tắc gửi mọi yêu cầu Marketing trên $3,000 tới trưởng phòng, và một quy tắc khác gửi mọi yêu cầu trên $5,000 tới Tài chính. Một yêu cầu Marketing $6,000 khớp cả hai, nên hệ thống cần một người thắng rõ ràng. Đặt ưu tiên đó trong bảng quy tắc, không phải trong logic ẩn của luồng.
Sai lầm khác là mã hóa tên người thay vì vai trò hoặc nhóm. Tên thay đổi. Đội thay đổi. Ai đó nghỉ phép hoặc chuyển phòng. Nếu quy tắc ghi 'gửi cho Maria Lopez' bạn sẽ sửa nó mỗi khi có thay đổi nhân sự. An toàn hơn khi định tuyến tới vai trò như Regional Finance Manager hoặc Sales Director, sau đó ánh xạ vai trò đó tới người hiện tại.
Bỏ qua đường dự phòng gây ra lỗi lặng lẽ. Sớm muộn gì cũng có yêu cầu không khớp quy tắc vì số tiền lạ, phòng ban mới hoặc trường để trống. Khi đó, luồng vẫn nên làm điều an toàn, như gửi tới hàng đợi mặc định hoặc đội admin.
Ngoại lệ vùng là điểm yếu khác. Một chính sách phù hợp ở một quốc gia có thể không phù hợp ở quốc gia khác vì giới hạn chi, luật thuế hoặc yêu cầu báo cáo. Nếu bạn chỉ thử ở một vùng, có thể bỏ sót trường hợp EU, US hoặc APAC cần đường đi khác.
Quy tắc theo thời gian cũng dễ bị lãng quên. Nếu bạn tạo quy tắc tạm cho cuối quý, đóng băng ngân sách hoặc dự án đặc biệt, hãy đảm bảo nó có ngày bắt đầu và kết thúc. Quy tắc hết hạn nên tự dừng. Nếu không, ngoại lệ cũ vẫn tồn tại và gửi yêu cầu sai đường.
Trước khi bật điều hướng theo ngưỡng, xem xét từ góc nhìn người dùng thực. Mỗi yêu cầu nên đến đúng người phê duyệt mà không ai phải đoán lý do.
Giữ kiểm tra cuối đơn giản.
Đảm bảo mỗi yêu cầu bình thường có một khớp rõ ràng. Nếu hai quy tắc cùng áp dụng, người dùng sẽ nhận kết quả không nhất quán.
Chắc chắn có đường dự phòng. Phòng ban thiếu, vùng mới hoặc số tiền bất thường vẫn phải đi tới chỗ an toàn.
Xác nhận đội có thể cập nhật chính sách mà không cần lập trình viên. Nếu Finance hoặc Operations cần thay giới hạn, ngày hoặc người phê duyệt, họ nên chỉnh bản ghi trong bảng thay vì gửi yêu cầu sửa mã.
Kiểm thử ngày, không chỉ giá trị. Chính sách hôm qua và chính sách bắt đầu tháng sau đều phải hành xử như mong đợi khi ngày hiệu lực được bật.
Viết logic định tuyến trên một trang bằng ngôn ngữ đơn giản. Nếu một quản lý không thể giải thích rõ ràng, có lẽ hệ thống quá phức tạp.
Một bài kiểm tra hữu ích là tạo năm yêu cầu mẫu bao phủ trường hợp bình thường, biên và chính sách lỗi thời. Nếu đội có thể dự đoán kết quả trước khi chạy, thiết lập có lẽ sẵn sàng. Nếu không, hãy đơn giản hóa.
Bắt đầu nhỏ. Chọn một luồng phê duyệt đang gây chậm hoặc nhầm lẫn nhiều nhất hiện nay, như yêu cầu mua vượt mức hoặc chi phí theo phòng ban. Xây cái đó trước, kiểm thử với trường hợp thực và rồi thêm loại quy tắc khác.
Cách làm này giúp mô hình định tuyến dễ được tin tưởng. Mọi người thấy quy tắc hoạt động, chỗ xuất hiện ngoại lệ và cần thay đổi gì trước khi mở rộng.
Lần ra mắt đầu tiên nên trả lời bốn câu hỏi cơ bản:
Điểm cuối cùng rất quan trọng. Nếu không ai sở hữu việc cập nhật chính sách, luồng sẽ dần lệch khỏi cách doanh nghiệp thực sự vận hành. Giao cho một người hoặc một nhóm nhỏ chịu trách nhiệm rà soát thay đổi quy tắc, phê duyệt chỉnh sửa và giữ ghi chú ngắn về lý do thay đổi.
Cũng nên đặt lịch rà soát. Nếu chính sách thay đổi thường xuyên, rà soát hàng tháng. Nếu ổn định, quý một lần là đủ. Một buổi rà soát ngắn có thể phát hiện ngưỡng lỗi thời, phòng ban thiếu hoặc ngoại lệ vùng trước khi gây chậm.
Giữ việc rà soát thực tế. Đặt câu hỏi đơn giản: phê duyệt có đến đúng người không, có đội nào thay đổi cấu trúc không, giới hạn hiện tại còn phù hợp với chính sách tài chính không, và có quá nhiều ghi đè thủ công không?
Nếu muốn xây bằng giao diện, AppMaster là lựa chọn phù hợp để tạo bảng quy tắc, quy trình định tuyến và màn hình admin cho nhân viên không chuyên cập nhật chính sách. Vì AppMaster thiết kế cho ứng dụng no-code đầy đủ, nó vận hành tốt khi bạn muốn đội doanh nghiệp quản lý thay đổi phê duyệt trực tiếp thay vì gửi mọi cập nhật về cho lập trình viên.
Khi một luồng hoạt động tốt, tái sử dụng cùng mẫu đó cho quy trình tiếp theo. Các bước nhỏ và rõ ràng thường hiệu quả hơn một lần xây dựng lớn.
Điều hướng theo ngưỡng là gì?Có nghĩa là ứng dụng chọn đường phê duyệt dựa trên dữ liệu quy tắc thay vì các nhánh cố định trong luồng. Ví dụ: số tiền, phòng ban hoặc vùng có thể quyết định ai phê duyệt một yêu cầu, và bạn có thể thay đổi những giá trị đó trong một bảng mà không phải xây lại toàn bộ quy trình.
Tại sao quy tắc phê duyệt gắn cứng lại là vấn đề?Quy tắc gắn cứng hoạt động lúc ban đầu, nhưng mỗi lần thay đổi chính sách lại biến thành công việc phát triển, kiểm thử và phát hành. Một bảng quy tắc nhanh hơn vì luồng công việc giữ nguyên còn các giá trị chính sách thay đổi trong dữ liệu.
Tôi nên đặt gì trong bảng quy tắc phê duyệt?Bắt đầu với các trường thực sự ảnh hưởng tới việc định tuyến, như số tiền tối thiểu, số tiền tối đa, loại tiền, phòng ban, vùng, loại yêu cầu, vai trò người phê duyệt, độ ưu tiên và trạng thái hoạt động. Nếu dùng chính sách tạm thời, thêm cả ngày bắt đầu và kết thúc.
Tôi nên lưu tên người phê duyệt hay vai trò người phê duyệt?Nên lưu vai trò thay vì tên cá nhân. Nếu bạn định tuyến tới một vai trò như Finance Director hay Department Manager, khi nhân sự thay đổi bạn chỉ cập nhật ánh xạ vai trò-một người hiện tại một lần thay vì sửa nhiều quy tắc.
Làm sao để xử lý khi quy tắc phê duyệt chồng chéo?Dùng một trường ưu tiên rõ ràng và định nghĩa số nào thắng. Hệ thống nên kiểm tra quy tắc cụ thể nhất trước, vì vậy một quy tắc hẹp như EU + Finance + trên 10,000 nên ưu tiên hơn quy tắc chung cho tất cả phòng ban trên 10,000.
Nếu không có quy tắc nào khớp với yêu cầu thì sao?Thêm một quy tắc dự phòng. Nếu yêu cầu thiếu dữ liệu hoặc không khớp bất kỳ hàng nào, nó vẫn nên đi tới một hàng đợi an toàn, đội admin hoặc người phê duyệt mặc định thay vì bị kẹt.
Đội không chuyên về kỹ thuật có tự cập nhật quy tắc phê duyệt được không?Có, nếu hệ thống được xây đúng. Trong AppMaster, bạn có thể lưu quy tắc trong bảng và để quy trình đọc chúng ở thời gian chạy, nên nhân viên được ủy quyền có thể cập nhật dữ liệu chính sách qua giao diện quản trị mà không chạm vào mã.
Tại sao nên thêm ngày bắt đầu và kết thúc cho quy tắc?Ngày hiệu lực cho phép bạn lên lịch thay đổi và tự động loại bỏ ngoại lệ tạm thời. Chúng hữu ích cho quy tắc cuối quý, đóng băng ngân sách hoặc thay đổi chính sách bắt đầu từ tháng sau nhưng không ảnh hưởng tới yêu cầu hiện tại.
Làm sao để kiểm thử điều hướng theo ngưỡng trước khi ra mắt?Kiểm thử các trường hợp thực tế trước khi ra mắt, đặc biệt là các trường hợp biên. Kiểm tra giá trị ngưỡng chính xác, trường để trống, phòng ban mới, khác biệt vùng và chính sách đã hết hạn để đảm bảo mỗi yêu cầu có một đường đi rõ ràng.
Cách tốt nhất để bắt đầu sử dụng phương pháp này là gì?Bắt đầu với một luồng phê duyệt đang gây chậm trễ nhất, ví dụ yêu cầu mua hàng vượt mức hay yêu cầu chi phí theo phòng ban. Giữ phiên bản đầu nhỏ, chứng minh quy tắc hoạt động rồi áp dụng mẫu đó cho quy trình khác.
10 thg 3, 2026
6 phút
08 thg 3, 20268 phút
07 thg 3, 202610 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
