> ## Documentation Index
> Fetch the complete documentation index at: https://learn.cleeksy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cơ chế kiểm soát

> Chọn workflow, validation và roles cho đúng loại 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](/foundations/app-boundaries)
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/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)](/reference/permissions-model-public)
* [Quyền & truy cập (Permissions & access)](/troubleshooting/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)](/build-apps/workflows/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

| Câu hỏi                               | Control ưu tiên                            | Ghi chú                                 |
| ------------------------------------- | ------------------------------------------ | --------------------------------------- |
| “Ai được xem/sửa/duyệt?”              | Roles/Permissions                          | Có thể kết hợp field-level edit         |
| “Ở trạng thái nào được làm?”          | Workflow                                   | Quy tắc theo bước/trạng thái            |
| “Thiếu dữ liệu/giá trị không hợp lệ?” | Validation/Protection                      | Chặn thao tác hoặc hiển thị lỗi         |
| “Vừa cần đúng người *và* đúng bước?”  | Roles + Workflow                           | Workflow điều phối, role giới hạn người |
| “Policy phụ thuộc vào nhiều field?”   | Validation + Workflow (nếu liên quan bước) | Tránh nhét vào permission               |

<Note>
  Quy tắc thường đi theo thứ tự: **đúng người → đúng bước → đúng dữ liệu**. Nếu đảo ngược, hệ thống dễ rối và khó giải thích.
</Note>

## 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)](/foundations/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)](/foundations/improve-loop)
* Tổ chức delivery theo vòng lặp: [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)
* Cấu hình workflow: [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)