Cơ chế kiểm soát

Trang này hướng dẫn cách đặt controls (cơ chế kiểm soát) vào đúng lớp trong hệ thống để giảm lỗi vận hành và tránh logic rải rác. Ba “đòn bẩy” control thường dùng trong Cleeksy:

• Roles/Permissions: ai được làm gì
• Workflow: khi nào được làm gì (theo bước/trạng thái)
• Validation/Protection: điều kiện đúng của dữ liệu (đúng–đủ–hợp lệ)

​

Mục tiêu

• Chọn đúng loại control cho từng yêu cầu (policy/rule)
• Giảm rủi ro “bẻ cong workflow để kiểm tra dữ liệu” hoặc “dùng permission như business logic”
• Thiết kế app dễ hiểu, dễ mở rộng, dễ audit

Liên quan:

• Ranh giới App
• Ownership & chia sẻ dữ liệu (Data ownership & sharing)

​

Ba lớp control: dùng khi nào?

​

1) Roles/Permissions — “Ai được làm gì?”

Dùng khi yêu cầu liên quan đến:

• quyền truy cập (xem/tạo/sửa/xoá)
• ai được chỉnh sửa field nào
• ai được thực hiện hành động nhạy cảm (approve, publish, export…)

Ví dụ

• Chỉ Procurement được sửa field “PO Number”
• Chỉ Admin được thay đổi cấu hình app
• Requester chỉ được xem các request của chính mình (access scope)

Tham khảo:

• Mô hình phân quyền (Permissions model)
• Quyền & truy cập (Permissions & access)

​

2) Workflow — “Khi nào được làm gì?”

Dùng khi yêu cầu liên quan đến:

• trạng thái công việc và chuyển bước (Draft → Pending → Approved/Rejected…)
• ai được chuyển trạng thái ở từng bước
• kiểm soát luồng “đầu-cuối” và audit theo bước

Ví dụ

• Chỉ Approver mới chuyển “Pending Approval” → “Approved/Rejected”
• Không cho phép “Close” khi chưa “Approved”
• Khi chuyển trạng thái sang “Approved”, hệ thống kích hoạt bước tiếp theo

Tham khảo: Thiết kế quy trình (Process Builder)

​

3) Validation/Protection — “Dữ liệu phải đúng như thế nào?”

Dùng khi yêu cầu liên quan đến:

• bắt buộc nhập (required)
• ràng buộc giá trị (range, format)
• tính nhất quán giữa các field (cross-field rules)
• khoá/sinh tự động (autonumber, formula, system fields…)

Ví dụ

• Không cho gửi request nếu thiếu “Estimated Cost”
• “Need-by date” phải >= hôm nay
• Nếu “Purchase type” = “Capex” thì “Budget code” là bắt buộc

​

Decision guide: chọn đúng control trong 30 giây

​

Pattern áp dụng thường gặp

​

Pattern A — “Chỉ đúng vai trò mới sửa được một field”

• Dùng field-level permissions trong role tuỳ chỉnh
• Kết hợp access scope nếu cần giới hạn theo owner/assignee

Ví dụ: Procurement sửa “Supplier” và “PO Number”, Requester không sửa được.

​

Pattern B — “Chỉ được gửi khi dữ liệu đủ”

• Dùng validation (required/rules)
• Nếu “gửi” là một bước trong workflow: chặn transition khi điều kiện không thoả

Ví dụ: Draft → Pending Approval chỉ thực hiện khi đã có Estimated Cost.

​

Pattern C — “Chỉ Approver được duyệt, và chỉ khi đang Pending”

• Workflow đảm bảo trạng thái
• Roles đảm bảo đúng người

Ví dụ: Action “Approve/Reject” chỉ hiện cho Approver khi record ở Pending Approval.

​

Pattern D — “Không cho phép sửa sau khi đã Approved”

• Workflow: khi record ở Approved thì giới hạn action/transition
• Permissions: khoá sửa field (hoặc chuyển role/scope theo trạng thái nếu thiết kế như vậy)

​

Anti-patterns cần tránh

​

1) Dùng permission thay cho workflow

• Dấu hiệu: “muốn chặn thao tác theo trạng thái” nhưng lại tạo nhiều role phức tạp
• Hậu quả: khó hiểu, khó mở rộng, dễ sai khi thêm trạng thái mới

​

2) Nhét validation vào workflow

• Dấu hiệu: tạo nhiều nhánh workflow chỉ để kiểm tra thiếu field
• Hậu quả: workflow trở thành “mê cung”, khó audit

​

3) Không rõ ownership dữ liệu

• Dấu hiệu: nhiều vai trò cùng sửa cùng field, không ai chịu trách nhiệm khi sai
• Hậu quả: dữ liệu mâu thuẫn, quy trình “đứt gãy”

Xem thêm: Ownership & chia sẻ dữ liệu (Data ownership & sharing)

​

Ví dụ áp dụng: Purchase Request

Một cấu hình control tối thiểu (gợi ý):

• Roles
• Requester: tạo/sửa request khi Draft, xem tiến độ
• Approver: duyệt/từ chối khi Pending Approval
• Procurement: cập nhật xử lý mua sắm (trong app Procurement)
• Workflow
• Draft → Pending Approval → Approved/Rejected → Closed
• Validation
• Required: title, purchase type, estimated cost
• Cross-field: nếu capex thì budget code required
• Date rule: need-by date không nhỏ hơn hôm nay

​

Bước tiếp theo

• Cách đo và cải tiến: Vòng lặp cải tiến (Improve loop)
• Tổ chức delivery theo vòng lặp: Inner loop: delivery cycle (chu kỳ triển khai)
• Cấu hình workflow: Thiết kế quy trình (Process Builder)