# Tạo báo cáo (Create reports)
Source: https://learn.cleeksy.com/build-apps/analytics-hub/create-reports
Tạo report với metric, filter và tham số cơ bản.
Trang này mô tả cách tạo report trong Analytics Hub theo hướng thực dụng: bắt đầu từ câu hỏi vận hành, chọn đúng nguồn dữ liệu, rồi thiết kế filter/parameter để người xem dùng được ngay.
Liên quan:
* [Tổng quan phân tích dữ liệu](/build-apps/analytics-hub/overview)
* [Bộ lọc & toán tử (Filters & operators)](/reference/filters-operators)
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
***
## 1) Quy trình tạo report (report building steps)
### Bước 1 — Xác định câu hỏi cần trả lời
Ví dụ:
* “Có bao nhiêu Purchase Request đang Pending approval?”
* “Bao nhiêu request bị quá hạn theo tuần?”
* “Cycle time trung bình từ Submitted → Approved là bao lâu?”
Câu hỏi tốt thường có:
* **đối tượng** (entity/dataset)
* **thước đo** (đếm, tổng, trung bình, tỷ lệ)
* **phạm vi** (thời gian, nhóm, trạng thái)
### Bước 2 — Chọn nguồn dữ liệu
* Single-app: chọn Entity trong app
* Cross-app: dùng dữ liệu đã được chia sẻ qua publish/consume và Data source phù hợp
Thực hành tốt:
* Chốt “source of truth (nguồn dữ liệu chuẩn)” trước khi làm report
* Chỉ dùng field đã được chuẩn hoá (status/date/owner…)
### Bước 3 — Chọn loại report/biểu đồ
Nguyên tắc chọn nhanh:
* **Đếm theo trạng thái** → bar/stacked bar hoặc bảng tổng hợp
* **Xu hướng theo thời gian** → line hoặc bar theo tuần/tháng
* **So sánh theo nhóm** (team/owner/category) → bar
* **Danh sách cần xử lý** → table (kèm sort/filter)
### Bước 4 — Định nghĩa thước đo (metrics)
Các thước đo thường dùng:
* Count (số lượng record)
* Sum (tổng chi phí)
* Average/Median (trung bình) cho cycle time
* Ratio (tỷ lệ) như % approved hoặc % overdue
Gợi ý: đặt tên metric rõ ràng và thống nhất (ví dụ: “Overdue count”, “Avg cycle time (days)”).
### Bước 5 — Thêm filter mặc định
Filter mặc định giúp report “ra số” đúng mục tiêu:
* Chỉ lấy status cần báo cáo (Pending/Approved…)
* Giới hạn thời gian (30 ngày gần nhất)
* Loại trừ record đã đóng nếu không cần
### Bước 6 — Kiểm tra dữ liệu và chia sẻ thử
* So sánh với view vận hành trong app (Grid/Kanban) để tránh sai lệch
* Chia sẻ cho một nhóm nhỏ để nhận phản hồi về filter/hiển thị
***
## 2) Filter & parameter (cơ bản)
### Filter (bộ lọc)
Filter là điều kiện cố định hoặc do người xem chọn để giới hạn dữ liệu.
Ví dụ filter phổ biến:
* Status = Pending approval
* Created date trong 30 ngày
* Department = Finance
### Parameter (tham số)
Parameter là filter “mở” để người xem thay đổi theo ngữ cảnh.
Ví dụ:
* Chọn khoảng thời gian (tuần/tháng)
* Chọn Department/Team
* Chọn Owner/Assignee
Thực hành tốt với parameter:
* Giới hạn số parameter (1–3) để tránh rối
* Có giá trị mặc định hợp lý (default)
* Đặt nhãn rõ ràng (ví dụ: “Khoảng thời gian”, “Phòng ban”)
***
## 3) Common patterns (mẫu report thường dùng)
### Pattern A — Operational dashboard (tổng quan vận hành)
* KPI tiles: tổng pending, overdue, approved tuần này
* Trend: số request theo tuần
* Breakdown: theo category/department
### Pattern B — Work queue (danh sách cần xử lý)
* Table các record “chờ xử lý”
* Sort theo due date
* Filter theo assignee/team
### Pattern C — Bottleneck finder (tìm điểm nghẽn)
* Cycle time theo bước (nếu có timestamp theo trạng thái)
* Top reasons của reject (nếu có field reason)
* So sánh giữa team/department
### Pattern D — Compliance/SLA (tuân thủ)
* % quá hạn theo tuần
* Median time to approve
* Danh sách case vượt SLA để follow-up
***
## 4) Guardrails để report ổn định theo thời gian
* Tránh phụ thuộc field “không chuẩn” (text tự do) cho filter quan trọng
* Chuẩn hoá status và ngày mốc (submittedAt/approvedAt/completedAt…)
* Khi thay đổi data model/workflow, rà soát lại report liên quan
Liên quan: [Rà soát & vận hành (App review)](/build-apps/app-review)
***
## Bước tiếp theo
* Chia sẻ đúng người, đúng phạm vi: [Chia sẻ & phân quyền (Sharing & permissions)](/build-apps/analytics-hub/sharing-permissions)
# Tổng quan phân tích dữ liệu
Source: https://learn.cleeksy.com/build-apps/analytics-hub/overview
Tổng quan phân tích dữ liệu và nguồn dữ liệu cho báo cáo.
Analytics Hub là nơi tạo **báo cáo (report)** và theo dõi **chỉ số (metrics/KPI)** dựa trên dữ liệu vận hành trong các app của Cleeksy DOP.
Mục tiêu của Analytics Hub:
* Biến dữ liệu vận hành (records) thành góc nhìn quản trị: tiến độ, tồn đọng, hiệu suất, tuân thủ
* Chuẩn hoá cách chia sẻ báo cáo theo vai trò và phạm vi dữ liệu
* Tạo “vòng phản hồi” để cải tiến quy trình và app theo thời gian
Liên quan:
* [Vận hành số (Digital Operations)](/foundations/digital-operations)
* [Vòng lặp cải tiến (Improve loop)](/foundations/improve-loop)
***
## 1) Analytics Hub dùng để làm gì?
### Theo dõi vận hành
* Số lượng yêu cầu theo trạng thái (Submitted/Approved/Rejected/Done…)
* Thời gian xử lý trung bình, quá hạn, bottleneck theo bước
* Khối lượng công việc theo nhóm/người phụ trách
### Báo cáo quản trị
* Xu hướng theo tuần/tháng/quý
* So sánh giữa phòng ban/nhóm/nhánh (nếu có phân loại)
* Tỷ lệ tuân thủ SLA hoặc chính sách nội bộ
### Hỗ trợ quyết định cải tiến
* Xác định bước nào gây tắc nghẽn
* Xác định nguyên nhân phổ biến của việc reject
* Đề xuất thay đổi form/field/workflow để giảm lỗi đầu vào
***
## 2) Dữ liệu trong Analytics Hub đến từ đâu?
Analytics Hub đọc dữ liệu từ các **Data source (cổng dữ liệu)** đã được cấu hình cho mục tiêu phân tích. Tuỳ bài toán, nguồn dữ liệu có thể là:
### A) Dữ liệu trong một app (single-app)
* Entity và records trong cùng app
* Phù hợp với báo cáo vận hành nội bộ của app đó (ví dụ: Purchase Request)
### B) Dữ liệu giữa nhiều app (cross-app)
Khi cần báo cáo end-to-end (ví dụ: Purchase Request → Procurement), dữ liệu thường đi qua cơ chế chia sẻ:
* [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
* [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
* Data source loại *Connected app* (kết nối ứng dụng) để chia sẻ/nhận dữ liệu giữa các app
Gợi ý thực hành:
* Chốt **source of truth (nguồn dữ liệu chuẩn)** cho từng phần dữ liệu
* Publish “đủ dùng” cho mục tiêu báo cáo, tránh publish quá rộng
Liên quan: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
### C) Dữ liệu từ bên ngoài (external)
Khi app nhận dữ liệu từ hệ thống ngoài qua:
* Webhook portal
* API portal
Dữ liệu vẫn được ghi vào Entity trước, sau đó mới được dùng cho báo cáo.
Liên quan:
* [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
* [API portal (cổng API)](/build-apps/integrations/api-portal)
***
## 3) Mô hình chia sẻ (sharing model)
Báo cáo trong Analytics Hub thường cần 2 lớp kiểm soát:
### Lớp 1 — Phạm vi dữ liệu (data scope)
* Dữ liệu nào được phép xem (theo filter/dataset đã publish hoặc theo quyền trong app)
* Tránh “xem toàn bộ” khi không cần thiết
### Lớp 2 — Quyền người dùng (user permissions)
* Ai được xem báo cáo (role-based access)
* Ai được chỉnh sửa định nghĩa báo cáo (thường giới hạn cho builder/owner)
Thực hành tốt:
* Tách report theo nhu cầu: report cho team vận hành vs report cho quản trị
* Đặt tên report rõ ràng và thống nhất (dễ tìm, dễ tái sử dụng)
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
***
## 4) Bắt đầu nhanh (định hướng cấu hình)
Một quy trình tối thiểu để tạo báo cáo vận hành:
1. Xác định câu hỏi cần trả lời (ví dụ: “bao nhiêu request quá hạn trong tuần này?”)
2. Chốt nguồn dữ liệu (app nào là nguồn, dataset nào cần publish nếu cross-app)
3. Chuẩn hoá field để phân tích:
* Status rõ ràng
* Date/Datetime nhất quán (createdAt, approvedAt, completedAt…)
* Owner/Assignee nếu cần phân bổ trách nhiệm
4. Tạo report theo nhóm chỉ số:
* Volume (khối lượng)
* Cycle time (thời gian xử lý)
* SLA/Overdue (quá hạn)
5. Chia sẻ report theo role và kiểm tra phạm vi dữ liệu
***
## 5) Anti-patterns thường gặp
* Publish dữ liệu quá rộng chỉ để làm báo cáo → tăng rủi ro lộ dữ liệu
* Không chốt source of truth → số liệu lệch giữa các app
***
## Bước tiếp theo
* Thiết kế vòng cải tiến: [Vòng lặp cải tiến (Improve loop)](/foundations/improve-loop)
* Chia sẻ dữ liệu giữa app: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
# Chia sẻ & phân quyền (Sharing & permissions)
Source: https://learn.cleeksy.com/build-apps/analytics-hub/sharing-permissions
Chia sẻ report và quản lý quyền xem/chỉnh sửa.
Trang này mô tả mô hình chia sẻ report trong Analytics Hub theo hướng thực dụng: **ai được xem gì**, **ai được chỉnh sửa gì**, và cách publish report để đội vận hành sử dụng ổn định.
Liên quan:
* [Tổng quan phân tích dữ liệu](/build-apps/analytics-hub/overview)
* [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
***
## 1) Nguyên tắc “ai thấy gì” (who can see what)
Khi một report hiển thị dữ liệu, quyền truy cập thường bị chi phối bởi 2 lớp:
### Lớp 1 — Phạm vi dữ liệu (data scope)
* Dataset/nguồn dữ liệu nào được phép dùng
* Filter nào đang áp dụng (mặc định hoặc theo parameter)
### Lớp 2 — Quyền người dùng (user permissions)
* Role trong workspace/app quyết định người dùng có thể xem những gì
* Quyền xem report không nên vượt phạm vi dữ liệu mà người dùng được phép thấy
Thực hành tốt:
* Report cho “toàn công ty” chỉ nên dùng dữ liệu đã được publish theo phạm vi phù hợp
* Report cho team vận hành nên giới hạn theo team/department và ownership
***
## 2) Quyền chỉnh sửa (edit) vs quyền xem (view)
### View (xem)
Dành cho người dùng cần đọc số liệu và hành động theo số liệu.
### Edit (chỉnh sửa định nghĩa report)
Nên giới hạn cho:
* App owner/builder
* Analytics owner (nếu có vai trò riêng)
* Nhóm quản trị vận hành
Lý do: thay đổi report có thể ảnh hưởng cách hiểu số liệu và quyết định vận hành.
***
## 3) Publishing patterns (mẫu publish báo cáo)
### Pattern A — Team dashboard
* Publish report cho một nhóm/role cụ thể
* Dùng parameter để người xem tự chọn khoảng thời gian hoặc assignee
Phù hợp: work queue, pending/overdue theo team.
### Pattern B — Executive snapshot
* Publish một report “tóm tắt” với số liệu đã được chuẩn hoá
* Hạn chế parameter, ưu tiên số liệu ổn định
Phù hợp: KPI theo tháng/quý.
### Pattern C — Shared source, different views
* Một dataset được publish để làm “nguồn chung”
* Tạo nhiều report khác nhau cho các nhóm khác nhau (mỗi report có filter riêng)
Phù hợp: cùng một quy trình nhưng nhiều phòng ban quan tâm các góc nhìn khác nhau.
### Pattern D — Release báo cáo theo phiên bản
* Khi thay đổi data model/workflow, tạo report phiên bản mới trước
* Chuyển người dùng sang report mới sau khi kiểm tra
Phù hợp: hệ thống đã vận hành, cần tránh “đổi số liệu đột ngột”.
***
## 4) Guardrails khi chia sẻ (để không lộ dữ liệu)
* Không publish dataset quá rộng chỉ để “tiện làm report”
* Tránh đưa field nhạy cảm vào report nếu không bắt buộc
* Kiểm tra role/permission trước khi publish report cho phạm vi lớn
* Rà soát định kỳ: report nào còn dùng, report nào cần thu hồi
Liên quan:
* [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
* [Bảo mật (Security)](/build-apps/integrations/security-tokens)
***
## Bước tiếp theo
* Tạo report theo các mẫu thực dụng: [Tạo báo cáo (Create reports)](/build-apps/analytics-hub/create-reports)
# Cơ bản về App
Source: https://learn.cleeksy.com/build-apps/app-basics
Hiểu cấu trúc của một app trên Cleeksy DOP.
Trang này mô tả các khái niệm và thao tác nền tảng của **App** trên Cleeksy DOP. Nội dung tập trung vào “cách app hoạt động như một work system” và các thiết lập cần có để app vận hành ổn định.
Quickstart thực hành theo ví dụ Purchase Request: [App đầu tiên](/get-started/first-app)
## Mục tiêu
* Xác định vai trò của **App** trong mô hình vận hành số (Digital Operations)
* Nắm cấu trúc của một app: **data + UI + workflow + roles + controls + connections**
* Hiểu các lựa chọn **bảo mật** và **quyền truy cập** ở cấp app
* Thực hiện các thao tác quản trị cơ bản: tạo, chỉnh sửa, mời thành viên, di chuyển, xoá/khôi phục
## App là gì trong Cleeksy?
Trong Cleeksy, một **App** thường được thiết kế như một **work system** có thể triển khai độc lập:
* **Data**: entities → fields → records
* **UI**: views + record layout
* **Process**: workflow / approvals / automation
* **People**: roles & permissions
* **Controls**: ràng buộc, bảo vệ dữ liệu, chính sách vận hành
* **Connect**: publish/consume, Data Connection (dựa trên connected app đã consume), webhook/API (khi cần)
Tham khảo thêm:
* [Tổng quan: Cleeksy DOP là gì?](/get-started/overview)
* [Vận hành số (Digital Operations)](/foundations/digital-operations)
## Tạo một App
### Điều kiện tiên quyết
* Quyền **Admin Space** (chỉ Admin Space có thể tạo app)
* Có Space để triển khai app
### Thông tin cần nhập khi tạo app
* **Tên ứng dụng**: tối đa 255 ký tự, **không trùng** trong cùng Space
* **Chế độ bảo mật**: chọn 1 trong 2 chế độ (xem phần “Bảo mật”)
* **Biểu tượng (icon)**: tuỳ chọn (chọn từ danh sách có sẵn)
Tạo app trong Space, điền tên và chọn chế độ bảo mật.
Sau khi tạo, hệ thống khởi tạo cấu hình để app có thể sử dụng ngay:
* 3 view mặc định: **Bản ghi**, **Kanban**, **Tài liệu** (view **Bản ghi** được kích hoạt mặc định)
* Trường thông tin hệ thống (system fields) và trường ID bản ghi làm thông tin hiển thị mặc định
* Giao diện chi tiết bản ghi (record detail) dạng 1 cột theo cấu hình mặc định
Thiết kế entity/field, tạo view và workflow theo scenario nghiệp vụ.
* Data modeling: [Thực thể dữ liệu (Entity)](/build-apps/data-modeling/entities), [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
* UI: [Tổng quan giao diện](/build-apps/ui-views/views-overview)
* Process: [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
## Bảo mật (Security mode)
App có 2 chế độ bảo mật:
### Riêng tư (Private)
* Chỉ người dùng/nhóm người dùng **được mời** mới truy cập được
* **Admin Space** có thể chủ động tham gia với vai trò Admin
### Công khai (Public)
* Tất cả thành viên trong Space có thể truy cập (mặc định ở mức bình luận)
* Có thể chủ động tham gia để trở thành Admin (tuỳ theo thiết lập và quyền)
Chế độ bảo mật ảnh hưởng đến “cách người dùng tiếp cận app”, nhưng quyền thao tác cụ thể vẫn được kiểm soát bởi Roles/Permissions.
## Quyền truy cập (Access) và vai trò (Roles)
### Vai trò hệ thống (System roles)
Các vai trò thường dùng trong app:
* **Quản trị viên (Admin)**: toàn quyền quản lý và cấu hình app
* **Người chỉnh sửa (Editor)**: xem, chỉnh sửa và xoá bản ghi (theo quyền)
* **Người bình luận (Commenter)**: chỉ xem và bình luận
* **Vai trò tuỳ chỉnh (Custom role)**: cấu hình quyền theo nhu cầu
### Phạm vi truy cập (Access scope)
Mỗi thành viên có thể được gán một phạm vi truy cập:
* **Toàn quyền**: truy cập toàn bộ dữ liệu trong app
* **Giới hạn**: chỉ truy cập các bản ghi do người dùng phụ trách
Nếu dùng phạm vi “Giới hạn”, cần xác định rõ cơ chế “người phụ trách” trong mô hình dữ liệu và workflow (ai là owner/assignee của record).
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)
## Quản lý thành viên (App access)
Thành viên có thể truy cập app theo 2 cách:
1. **Qua lời mời**
* Admin mời user hoặc user group vào app và gán role/scope
* Hệ thống gửi thông báo mời (email/inbox), quyền được áp dụng khi truy cập
2. **Chủ động tham gia**
* **Admin Space** có thể truy cập tất cả app (công khai và riêng tư)
* **Thành viên Space** chỉ chủ động truy cập app **công khai**
Nếu một user được mời vào app/project/data hub nhưng chưa thuộc Space, hệ thống có thể tự động thêm user vào Space với vai trò “Khách”.
## Vai trò tuỳ chỉnh (Custom role)
Vai trò tuỳ chỉnh hỗ trợ “đúng người — đúng quyền — đúng bước” cho các quy trình vận hành.
### Cách tạo vai trò tuỳ chỉnh (mô tả khái niệm)
* Chọn vai trò kế thừa (Admin hoặc Editor) làm nền
* Cấu hình quyền ở cấp bản ghi (ví dụ: có cho phép xoá bản ghi hay không)
* Cấu hình quyền ở cấp trường (field-level edit permissions): chọn trường nào được phép chỉnh sửa
### Quy tắc vận hành thường gặp
* Một vai trò tuỳ chỉnh có thể gán cho nhiều user hoặc nhóm user trong cùng app
* UI tự điều chỉnh theo quyền (ẩn nút xoá, khoá trường không cho sửa, hiển thị tooltip)
* Một số field không thể nhập liệu (rollup/lookup/formula/autonumber/system fields…) không xuất hiện trong danh sách cấp quyền chỉnh sửa
* Khi có field mới, mặc định **không cho phép chỉnh sửa** trong các vai trò tuỳ chỉnh (cho đến khi cấu hình)
## Thao tác quản trị cơ bản của App
Sau khi tạo app, các thao tác quản trị thường dùng gồm:
* Chỉnh sửa **tên / mô tả / biểu tượng**
* Thay đổi **chế độ bảo mật**
* Quản lý quyền truy cập (mời, đổi role/scope, xoá quyền)
* **Sao chép đường dẫn** app
* **Xoá app** (chuyển vào Thùng rác — xoá tạm thời, có thể khôi phục)
* **Di chuyển app** sang Space khác (nếu trùng tên, hệ thống có thể thêm chỉ số để phân biệt)
## Liên kết liên quan
* Thực hành: [App đầu tiên](/get-started/first-app)
* Data modeling: [Thực thể dữ liệu (Entity)](/build-apps/data-modeling/entities), [Bản ghi (Record)](/build-apps/data-modeling/records), [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
* UI: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view), [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
* Process: [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder), [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
* Permissions: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
# Rà soát & vận hành
Source: https://learn.cleeksy.com/build-apps/app-review
Rà soát app trước khi phát hành và khi vận hành.
Trang này tổng hợp checklist thực dụng để **rà soát và vận hành** app trên Cleeksy.
***
## 1) Checklist dữ liệu (Data)
* [ ] Entity và các field bắt buộc đã đủ (title, status, dates, owner/assignee)
* [ ] Field tính toán/hiển thị đã đúng:
* [Công thức (Formula)](/build-apps/data-modeling/formula)
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* [ ] Nếu cross-app: publish/consume đã tạo **connected app (kết nối ứng dụng)**, và Data Connection/Lookup/Rollup đã trỏ đúng (đúng nguồn/đúng quyền)
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
***
## 2) Checklist quy trình (Workflow)
* [ ] Trạng thái tối thiểu (3–5) và ý nghĩa rõ
* [ ] Checkpoint chuyển bước có điều kiện đo được (đủ field, đúng ngưỡng…)
* [ ] Có đường xử lý “không thành công” (reject/rework) nếu bài toán cần
* [ ] Nếu có duyệt: approver xác định được và có lý do khi reject
Liên quan:
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
* [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
***
## 3) Checklist phân quyền (Access)
* [ ] Requester chỉ sửa được ở trạng thái phù hợp (ví dụ Draft)
* [ ] Approver chỉ duyệt được ở trạng thái phù hợp (ví dụ Pending approval)
* [ ] Team thực thi chỉ thao tác khi đã bàn giao (Approved)
* [ ] Người xem chỉ có quyền đọc khi cần
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
***
## 4) Checklist giao diện (UI)
* [ ] Có Grid view “xương sống” cho từng role (Của tôi / Chờ duyệt / Quá hạn)
* [ ] Record layout tập trung đúng thông tin để ra quyết định
* [ ] Kanban/Gantt/Dashboard chỉ thêm khi có nhu cầu vận hành rõ
Liên quan: [Tổng quan giao diện](/build-apps/ui-views/views-overview)
***
## 5) Kịch bản kiểm thử (Test scenarios)
* [ ] Tạo mới → submit → approve → close
* [ ] Tạo mới → submit → reject (có lý do)
* [ ] Người không có quyền thử thao tác (bị chặn đúng)
* [ ] Dữ liệu thiếu bắt buộc (bị chặn đúng)
* [ ] Cross-app: publish/consume + liên kết record + hiển thị lookup (nếu có)
***
## 6) Theo dõi và cải tiến
* [ ] Đo ít nhưng đúng: số đơn, thời gian chờ duyệt, tỷ lệ reject, số đơn quá hạn
* [ ] Đưa insight vào backlog cải tiến theo Improve loop
Liên quan: [Vòng lặp cải tiến (Improve loop)](/foundations/improve-loop)
# Đánh số tự động (Auto number)
Source: https://learn.cleeksy.com/build-apps/data-modeling/auto-number
Tạo mã tự tăng bằng Auto number.
Auto number là Field dùng để **tự sinh mã** cho record theo quy tắc nhất quán (ví dụ `PR-000123`). Đây là cách phổ biến để tạo “mã tham chiếu” (reference) dễ tìm kiếm và audit.
## Dùng khi nào?
* Cần mã duy nhất để nhận diện record (PR/PO/Ticket…)
* Cần tham chiếu trong email, tài liệu, báo cáo
* Cần làm “primary display” dễ đọc (kết hợp với Title)
## Thực hành tốt
* Chọn **prefix** theo nghiệp vụ: `PR-`, `PO-`, `REQ-`
* Dùng độ dài số phù hợp (ví dụ 6 chữ số) để tránh đổi mẫu sớm
* Không cho người dùng sửa mã (để giữ tính audit)
* Nếu cần hiển thị đẹp: tạo Formula “Display title” = Auto number + Title
Liên quan: [Công thức (Formula)](/build-apps/data-modeling/formula)
## Lưu ý vận hành
* Auto number thường được sinh khi record được tạo
* Nếu xoá record, không nên kỳ vọng số sẽ “liền mạch” (tuỳ cơ chế hệ thống)
* Nếu cần nhiều chuỗi số theo loại nghiệp vụ: cân nhắc tách Entity hoặc thêm rule cấu hình (tuỳ thiết kế)
## Ví dụ: Purchase Request
* Field `PR Code`: Auto number với prefix `PR-`
* Field `Title`: Text
* Field `Display`: Formula = `PR Code + " — " + Title`
Kết quả: Grid view dễ đọc và tìm kiếm nhanh.
## Bước tiếp theo
* Thiết kế field cốt lõi: [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
* Tạo tiêu đề hiển thị: [Công thức (Formula)](/build-apps/data-modeling/formula)
# Mã vạch / QR (Barcode / QR)
Source: https://learn.cleeksy.com/build-apps/data-modeling/barcode-qr
Lưu và quét mã Barcode/QR trong dữ liệu.
Barcode/QR là Field dùng để lưu hoặc hiển thị giá trị **mã vạch / QR** phục vụ nhận diện nhanh bằng thiết bị quét. Field này thường dùng trong các app quản lý tài sản, kho, giao nhận, check-in, hoặc quản lý hồ sơ vật lý.
## Dùng khi nào?
* Cần **định danh** record ngoài đời thực (asset, kiện hàng, thẻ ra vào…)
* Cần thao tác nhanh bằng quét mã thay vì tìm kiếm thủ công
* Cần in nhãn (label) hoặc hiển thị mã trên màn hình để quét
## Thiết kế dữ liệu gợi ý
### 1) Mã do hệ thống tạo
* Tạo **Auto number** làm mã tham chiếu (ví dụ `ASSET-000123`)
* Dùng Barcode/QR để hiển thị dạng mã quét từ mã tham chiếu đó (tuỳ cơ chế hiển thị)
Liên quan: [Đánh số tự động (Auto number)](/build-apps/data-modeling/auto-number)
### 2) Mã do bên ngoài cung cấp
* Lưu giá trị mã quét được vào Barcode/QR hoặc Text (tuỳ loại field)
* Dùng validation để đảm bảo mã không bị trùng (nếu có ràng buộc nghiệp vụ)
## Pattern thường dùng
### Pattern A — “Asset tag”
* Entity: Asset
* Fields: Asset code (Auto number), Barcode/QR, Owner (User/People), Location
### Pattern B — “Scan-to-open”
* Quét mã → mở đúng record để xử lý (check-in/check-out, bảo trì, giao nhận)
## Lưu ý vận hành
* Chốt quy tắc “mã là duy nhất” và cách cấp mã (tự sinh hay nhập)
* Với quy trình nhạy cảm (giao nhận/kiểm kê), cần controls rõ:
* ai được đổi mã
* khi nào được đổi (theo trạng thái workflow)
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
## Bước tiếp theo
* Chuẩn hoá mã tham chiếu: [Đánh số tự động (Auto number)](/build-apps/data-modeling/auto-number)
* Theo dõi nơi chốn: [Vị trí (Location)](/build-apps/data-modeling/location)
# Kết nối dữ liệu một chiều (Data Connection one-way)
Source: https://learn.cleeksy.com/build-apps/data-modeling/data-connection-one-way
Liên kết dữ liệu một chiều bằng Data Connection.
Data Connection one-way là **một Field** dùng để liên kết record theo **một hướng**. Mục tiêu chính là **tham chiếu/hiển thị** hoặc **bàn giao (handoff)** dữ liệu, giúp giảm coupling và giữ rõ ownership.
## Dùng khi nào?
* Cần tham chiếu dữ liệu từ Entity khác để hiển thị hoặc lọc/nhóm
* Cần bàn giao công việc giữa hai bước/nhóm (từ Request → Procurement)
* Cần “kéo” một record nguồn vào app hiện tại để làm việc tiếp (read-mostly)
## Data Connection one-way hoạt động như thế nào?
* Data Connection là **Field** trên một Entity (Entity A)
* Field này liên kết tới record của một Entity khác (Entity B) theo một hướng:
* A **tham chiếu** tới B
* A có thể hiển thị/tra cứu (Lookup) thông tin của B
Data Connection one-way không có nghĩa “không thể cập nhật gì”, mà là **thiết kế vận hành** ưu tiên một hướng ownership để tránh sửa chéo. Quyền sửa dữ liệu nguồn vẫn do app/role sở hữu quyết định.
## Trong cùng App vs giữa các App (quan trọng)
### 1) Trong cùng App
Data Connection có thể trỏ trực tiếp tới **Entity trong cùng app** (không cần publish/consume).
Tình huống dùng phổ biến: liên kết Supplier, liên kết Department, liên kết Master data nội bộ.
### 2) Giữa các App
Với liên kết **cross-app**, Data Connection (một chiều) sẽ làm việc thông qua **Connected app (kết nối ứng dụng)** đã được provider chia sẻ.
Thực hành chuẩn:
1. Provider app cấu hình chia sẻ (publish) và/hoặc mở kênh nhận submission
2. Ở consumer app, khi cấu hình Data Connection field, chọn Connected app tương ứng (hệ thống sẽ yêu cầu xác nhận quyền truy cập nếu chưa kết nối)
Liên quan:
* [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
* [Kết nối ứng dụng (Connected app)](/build-apps/integrations/connected-app)
## Cách cấu hình (khung thao tác)
1. Xác định record nguồn cần tham chiếu (thuộc Entity/App nào)
2. Nếu cross-app: chốt publish/consume trước (đúng phạm vi field)
3. Tạo Field loại **Data Connection (one-way)** trên Entity đích
4. Thiết kế View để người dùng chọn record liên kết
5. (Tuỳ nhu cầu) tạo **Lookup** để hiển thị các field quan trọng từ record nguồn
Liên quan: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
## Ví dụ 1: Trong cùng App (Purchase Request ↔ Supplier)
* Entity `Purchase Request`
* Entity `Supplier`
* Field `Supplier` trên Purchase Request: Data Connection one-way → Supplier
* Lookup `Supplier name`, `Supplier code` để hiển thị
Kết quả: chọn Supplier một lần, thông tin hiển thị nhất quán.
## Ví dụ 2: Giữa các App (Purchase Request → Procurement)
Data Connection thiết lập **liên kết tới record** trong connected app. Nếu cần tham chiếu các field để hiển thị/lọc/nhóm, dùng thêm **Lookup (tham chiếu)**. Với liên kết giữa app, publish/consume tạo connected app (kết nối ứng dụng) cho Data Connection, Lookup và Rollup.
* App Purchase Request publish “Approved Requests”
* App Procurement kết nối Connected app theo dữ liệu đã được chia sẻ
* Entity `Procurement Task` có field `Request`: Data Connection one-way → Connected app đã kết nối
* Lookup kéo `Request title`, `Estimated cost`, `Requester`…
Kết quả: Procurement làm việc trên app riêng nhưng vẫn bám đúng dữ liệu chuẩn.
## Lưu ý thiết kế
* Ưu tiên publish/consume + one-way để giữ ownership rõ
* Data Connection là cơ chế **liên kết dữ liệu** (link databases) giữa Entity/App và **không** nhân bản (clone) dữ liệu. Lệch dữ liệu thường xảy ra khi tạo field trùng thông tin hoặc nhập lại thủ công thay vì tham chiếu qua liên kết.
* Chỉ kéo các field cần thiết bằng Lookup (đủ dùng, không kéo tràn)
## Khắc phục sự cố
### Không thấy connected app để chọn (cross-app)
* App nguồn chưa publish
* App hiện tại chưa consume
* Chưa được cấp quyền truy cập connected app
### Liên kết được nhưng Lookup trống
* Chưa cấu hình Lookup đúng field nguồn
* Field nguồn không được publish (cross-app)
* Quyền xem record/field nguồn không đủ
## Bước tiếp theo
* Tìm hiểu liên kết hai chiều (khi cần): [Kết nối dữ liệu hai chiều (Data Connection two-way)](/build-apps/data-modeling/data-connection-two-way)
* Kéo dữ liệu hiển thị: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* Quy tắc ownership: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
# Kết nối dữ liệu hai chiều (Data Connection two-way)
Source: https://learn.cleeksy.com/build-apps/data-modeling/data-connection-two-way
Liên kết dữ liệu hai chiều bằng Data Connection.
Data Connection two-way là Field liên kết record cho phép **tương tác hai phía**. Data Connection chỉ tạo **liên kết** (không nhân bản dữ liệu), vì vậy cần ownership và controls rõ để tránh sửa chéo. Đây là lựa chọn có rủi ro cao hơn one-way vì dễ tạo coupling và mâu thuẫn dữ liệu nếu ownership không rõ.
## Khi nào cần two-way?
Chỉ nên dùng khi có lý do nghiệp vụ rõ ràng, ví dụ:
* Hai phía cần cập nhật **một số field** của cùng một “cặp record” và cần phản chiếu qua lại
* Có quy tắc ownership theo **phân vùng field** (field ownership) và kiểm soát được xung đột
Nếu mục tiêu chỉ là hiển thị/bàn giao công việc → ưu tiên [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way).
## Điều kiện bắt buộc trước khi dùng two-way
1. Chốt **app nguồn** cho mỗi nhóm dữ liệu (source of truth / nguồn dữ liệu chuẩn)
2. Chốt **field ownership**: field nào do phía nào chịu trách nhiệm
3. Chốt quy tắc “ai cập nhật khi nào” (theo trạng thái/workflow)
4. Thiết kế controls: Roles/Permissions + Workflow + Validation
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
## Trong cùng App vs giữa các App
### 1) Trong cùng App
* Two-way liên kết giữa các Entity nội bộ (tuỳ cấu hình).
### 2) Giữa các App
Giống one-way, cross-app vẫn yêu cầu publish/consume trước để kết nối qua Connected app (kết nối ứng dụng). Two-way chỉ nên dùng khi đã có quy tắc đồng bộ và trách nhiệm rõ.
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
## Pattern an toàn khi bắt buộc dùng two-way
### Pattern A — “Phân vùng field theo ownership”
* Phía A chỉ cập nhật các field thuộc A
* Phía B chỉ cập nhật các field thuộc B
* Các field chung được khóa hoặc chỉ cập nhật bởi một phía
### Pattern B — “Cập nhật theo trạng thái”
* Khi record ở trạng thái X, chỉ phía A được cập nhật
* Khi chuyển sang trạng thái Y, quyền cập nhật chuyển sang phía B
## Anti-patterns cần tránh
* “Ai cũng sửa được mọi field”
* Two-way dùng cho mọi liên kết “cho tiện”
* Không có quy tắc xử lý khi dữ liệu xung đột
* Không có audit/ownership rõ
## Ví dụ tham khảo: Purchase Request ↔ Procurement (cần cân nhắc)
Một lựa chọn an toàn hơn là:
* Purchase Request publish (Approved Requests)
* Procurement publish trạng thái xử lý (read-only cho requester)
Chỉ cân nhắc two-way khi:
* Có các field mà Procurement cần cập nhật ngược lại trên record Request
* Đã chốt field ownership và rule đồng bộ rõ
## Checklist trước khi bật two-way
* [ ] Ownership và field ownership đã chốt
* [ ] Workflow checkpoints đã rõ (khi nào phía nào cập nhật)
* [ ] Permissions đã cấu hình để tránh sửa chéo
* [ ] Có kế hoạch xử lý lỗi/khôi phục khi dữ liệu sai
## Bước tiếp theo
* Kéo dữ liệu hiển thị: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* Quy tắc chia sẻ dữ liệu: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
# Thực thể dữ liệu (Entity)
Source: https://learn.cleeksy.com/build-apps/data-modeling/entities
Tạo entity và thiết kế cấu trúc dữ liệu trong app.
Entity là đơn vị trung tâm của **mô hình dữ liệu (data model)** trong Cleeksy. Mỗi app thường bắt đầu từ việc xác định các Entity chính, sau đó bổ sung **Field** và tạo **Record** trong quá trình vận hành.
## Entity là gì?
**Entity** tương đương “bảng dữ liệu” trong hệ thống. Entity chứa:
* **Fields**: các thuộc tính (cột) của dữ liệu
* **Records**: các bản ghi (dòng) được tạo và cập nhật khi công việc chạy
Liên quan:
* [Bản ghi (Record)](/build-apps/data-modeling/records)
* [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
## Khi nào cần tạo một Entity?
Một Entity nên được tạo khi tồn tại một “đối tượng nghiệp vụ” có vòng đời rõ ràng, ví dụ:
* Purchase Request (yêu cầu mua)
* Purchase Order (PO)
* Supplier (nhà cung cấp)
* Approval task (nhiệm vụ phê duyệt)
### Gợi ý nhận diện Entity từ scenario
Trong scenario, các **danh từ nghiệp vụ** (nouns) thường là ứng viên cho Entity.
Ví dụ trong Purchase Request: “yêu cầu mua”, “người yêu cầu”, “người phê duyệt”, “nhà cung cấp”, “PO”.
## Quy tắc thiết kế Entity (thực dụng)
### 1) Một Entity = một ownership rõ ràng
Entity nên thuộc về một app/đơn vị chịu trách nhiệm (source of truth). Nếu ownership không rõ, rủi ro dữ liệu mâu thuẫn tăng nhanh.
Tham khảo: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
### 2) Giữ Entity “gọn” cho value slice đầu tiên
Ở vòng đầu, Entity chỉ cần đủ dữ liệu để chạy end-to-end. Các trường “nice-to-have” đưa vào backlog.
Tham khảo: [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
### 3) Tránh trộn nhiều khái niệm vào một Entity
Nếu một Entity có quá nhiều field thuộc nhiều chủ đề khác nhau, nên cân nhắc tách:
* theo ownership
* theo workflow khác nhau
* theo nhóm người dùng khác nhau
Tham khảo: [Ranh giới App](/foundations/app-boundaries)
## Tạo Entity trên Cleeksy (khái niệm & thao tác)
### Thông tin tối thiểu khi tạo Entity
* **Tên Entity**: ngắn, rõ nghĩa, danh từ số ít (khuyến nghị)
* **Mô tả**: 1–2 câu mô tả “Entity này dùng để làm gì”
* **Field hiển thị** (primary display): field dùng để hiển thị record trong liên kết
Một số field hệ thống (system fields) có thể được tạo mặc định để phục vụ audit và vận hành (ví dụ: người tạo, thời gian tạo…).
### Sau khi tạo Entity nên làm gì?
1. Tạo các **Field tối thiểu** để tạo record và chạy workflow
2. Tạo **View** để nhập liệu và theo dõi
3. Nếu có quy trình: thiết kế **Workflow** dựa trên các trạng thái của record
Liên quan:
* [Tổng quan giao diện](/build-apps/ui-views/views-overview)
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
## Cấu trúc dữ liệu và liên kết (Sub-entity & Data Connection)
Trong Cleeksy, **Entity luôn nằm trong một App**. Thay vì mô hình “relationship” kiểu cơ sở dữ liệu quan hệ, Cleeksy dùng hai cơ chế chính để biểu diễn liên hệ dữ liệu:
* **Sub-entity** (bảng con) để biểu diễn dữ liệu phân cấp (parent → nhiều dòng con) trong *một* Entity
* **Data Connection** (Field liên kết) để kết nối record giữa các Entity trong cùng App hoặc giữa các App
### 1) Sub-entity (bảng con) cho dữ liệu phân cấp
Dùng Sub-entity khi một đối tượng có **nhiều dòng con thuộc về chính nó**, ví dụ:
* Purchase Request có nhiều dòng hàng (items)
* Order có nhiều Order Items
* Phiếu giao việc có nhiều checklist items
**Đặc điểm**
* Sub-entity là **một Field** trong Entity cha (thường ở dạng “data table”)
* Các dòng con tồn tại trong ngữ cảnh của record cha → ownership rõ ràng, dễ vận hành
**Khi không nên dùng Sub-entity**
* Dòng con cần workflow riêng độc lập
* Dòng con cần được chia sẻ/được tham chiếu từ nhiều “cha” khác nhau
Trong trường hợp này, nên tách thành Entity riêng và liên kết bằng Data Connection.
### 2) Data Connection (Field) để liên kết giữa Entity/App
**Data Connection** là một Field trong Entity dùng để **liên kết record** với record ở Entity khác:
* **Trong cùng App**: kết nối giữa các Entity nội bộ để tham chiếu dữ liệu
* **Giữa các App**: Data Connection **chỉ** có thể trỏ tới dữ liệu mà App hiện tại đã **consume** (từ một App khác đã publish dữ liệu trước đó).
Khi kết nối **giữa các App**, publish/consume là bước bắt buộc để tạo **connected app (kết nối ứng dụng)** cho App tiêu thụ. Data Connection là Field dùng để liên kết record tới connected app đó (không thay thế publish/consume).
**One-way vs two-way**
* **One-way** phù hợp khi cần tham chiếu/hiển thị (reference, read-mostly) và muốn giảm coupling
* **Two-way** chỉ nên dùng khi ownership được định nghĩa rõ (field nào do bên nào chịu trách nhiệm) và có lý do nghiệp vụ thực sự
Xem triển khai:
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
* [Kết nối dữ liệu hai chiều (Data Connection two-way)](/build-apps/data-modeling/data-connection-two-way)
* [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
### 3) Patterns mô hình hoá thường dùng
* **Parent + line items**: ưu tiên Sub-entity (bảng con) trong Entity cha
Ví dụ: `Purchase Request` có field `Items` (Sub-entity)
* **Transaction → master/reference**: dùng Data Connection one-way để tham chiếu
Ví dụ: `Purchase Request` tham chiếu `Supplier` hoặc `Cost Center`
* **Nhu cầu tương đương “nhiều–nhiều”**: dùng Entity liên kết + Data Connection fields
Ví dụ: `Supplier Category Link` có 2 field Data Connection: `Supplier` và `Category`
Cách này giúp giữ ownership rõ ràng và tránh sửa chéo dữ liệu
## Ví dụ: Purchase Request (vòng đầu) và mở rộng Procurement
### Vòng đầu: 1 app Purchase Request
Entity tối thiểu:
* `Purchase Request`
* title, description, estimated cost, requester, status
* (tuỳ chọn) `Request Item` nếu cần nhiều dòng hàng
### Mở rộng: thêm app Procurement
Khi mở rộng sang Procurement, thường tách ownership:
* App Purchase Request: ownership yêu cầu và phê duyệt
* App Procurement: ownership xử lý mua sắm (PO, supplier, delivery status)
Kết nối dữ liệu:
* Procurement consume/pull thông tin request đã approved
* Purchase Request hiển thị tiến độ xử lý từ Procurement (read-only)
## Lỗi thường gặp khi thiết kế Entity
* **Tạo Entity theo màn hình** thay vì theo đối tượng dữ liệu (dẫn đến dữ liệu trùng và khó mở rộng)
* **Field quá nhiều ngay từ đầu** (đặc biệt là các field ít dùng)
* **Không chốt field hiển thị** (khi liên kết record sẽ khó đọc)
* **Thiếu ownership rõ ràng** (nhiều app cùng sửa một dữ liệu)
## Bước tiếp theo
* Thiết kế Field: [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
* Tạo và vận hành Record: [Bản ghi (Record)](/build-apps/data-modeling/records)
* Thiết kế View: [Tổng quan giao diện](/build-apps/ui-views/views-overview)
# Kiểu trường dữ liệu (Field types)
Source: https://learn.cleeksy.com/build-apps/data-modeling/field-types
Chọn field type phù hợp và quy tắc sử dụng.
Trang này là trang tổng hợp (canonical) về **Field types** trong Cleeksy. Nội dung tập trung vào:
* Nhận diện **nhóm Field** và khi nào nên dùng
* Các **Field cốt lõi** thường gặp khi xây app nghiệp vụ
* Mẹo cấu hình để dữ liệu “đúng–đủ–dễ dùng” và hỗ trợ Workflow/Views
Liên quan:
* [Thực thể dữ liệu (Entity)](/build-apps/data-modeling/entities)
* [Bản ghi (Record)](/build-apps/data-modeling/records)
***
## Nhóm Field trong Cleeksy
### 1) Core fields (Field nhập liệu)
Dùng để người dùng nhập dữ liệu nghiệp vụ hằng ngày.
* Text / Long text
* Number / Currency / Percent
* Date / Datetime
* Single select / Multi select / Status
* User/People
* Attachment
* Auto number
* Sub-dataset (child table)
Các Field này phù hợp cho vòng đầu của hầu hết app.
### 2) Computed fields (Field tính toán/thu thập)
Dùng để tổng hợp, suy ra hoặc kéo dữ liệu theo logic có sẵn.
* [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* [Công thức (Formula)](/build-apps/data-modeling/formula)
### 3) Connection fields (Field liên kết dữ liệu)
Dùng để liên kết record theo quan hệ trong cùng app hoặc giữa các app.
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
* [Kết nối dữ liệu hai chiều (Data Connection two-way)](/build-apps/data-modeling/data-connection-two-way)
Trong Cleeksy, **publish/consume** là cơ chế tạo **connected app (kết nối ứng dụng)** khi chia sẻ dữ liệu giữa các app. Connected app này được dùng cho **Data Connection** (liên kết record), **Lookup** (tham chiếu field) và **Rollup** (tổng hợp).
***
## Chọn Field đúng nhanh (quy tắc thực dụng)
* Cần nhập mô tả, ghi chú, nội dung dài → **Long text**
* Cần tính toán, lọc, tổng hợp theo số → **Number/Currency/Percent**
* Cần theo dõi deadline, SLA, ngày hiệu lực → **Date/Datetime**
* Cần chuẩn hoá lựa chọn (tránh gõ tự do) → **Single select**
* Cần gán người chịu trách nhiệm/đối tượng thao tác → **User/People**
* Cần đính kèm chứng từ, ảnh, tài liệu → **Attachment**
* Cần theo dõi “trạng thái quy trình” → **Status** (hoặc Single select nếu muốn linh hoạt hơn)
***
## Danh mục Field cốt lõi
* [Đánh số tự động (Auto number)](/build-apps/data-modeling/auto-number)
* [Bảng con (Child table)](/build-apps/data-modeling/sub-dataset-child-table)
* [Text / Long text](#text--long-text)
* [Number / Currency / Percent](#number--currency--percent)
* [Date / Datetime](#date--datetime)
* [Single select / Multi select / Status](#single-select--multi-select--status)
* [User/People](#userpeople)
* [Attachment](#attachment)
***
## Text / Long text
**Dùng khi:** nhập tên, tiêu đề, mã tham chiếu, mô tả, ghi chú.
### Text
* Phù hợp: tên ngắn, mã, tiêu đề
* Nên dùng khi dữ liệu cần hiển thị gọn ở Grid view hoặc làm “primary display”
### Long text
* Phù hợp: mô tả chi tiết, lý do, ghi chú, biên bản
* Nên dùng khi dữ liệu có thể nhiều dòng
### Thực hành tốt
* Quy ước đặt tên field rõ: `Title`, `Description`, `Note`
* Nếu cần tìm kiếm/lọc theo mã → dùng Text thay vì Long text
* Tránh dùng Long text cho dữ liệu có cấu trúc (ví dụ danh sách item) — cân nhắc **Sub-entity (bảng con)**
***
## Number / Currency / Percent
**Dùng khi:** số lượng, đơn giá, chi phí, tỷ lệ hoàn thành, KPI.
### Number
* Phù hợp: số lượng, điểm, chỉ số
* Lợi ích: lọc, sắp xếp, tính toán, rollup dễ dàng
### Currency
* Phù hợp: chi phí dự kiến, tổng tiền, ngân sách
* Thực hành tốt:
* thống nhất đơn vị tiền tệ theo app
* hiển thị định dạng dễ đọc
### Percent
* Phù hợp: tỷ lệ hoàn thành, mức chiết khấu, SLA %
* Thực hành tốt: quy định rõ “0–1” hay “0–100” theo cách hiển thị của hệ thống (tránh nhập sai)
### Validation gợi ý
* Không cho âm nếu không hợp lý (ví dụ số lượng)
* Cần giới hạn min/max nếu có quy định nghiệp vụ
***
## Date / Datetime
**Dùng khi:** deadline, ngày yêu cầu, ngày phê duyệt, mốc trạng thái, lịch hẹn.
### Date
* Phù hợp: chỉ cần ngày (không cần giờ)
* Ví dụ: Need-by date, ngày hiệu lực
### Datetime
* Phù hợp: cần chính xác tới giờ/phút
* Ví dụ: thời điểm submit/approve, SLA theo giờ
### Thực hành tốt
* Field tên rõ mục đích: `Requested date`, `Need-by date`, `Approved at`
* Nếu dùng cho SLA: ưu tiên Datetime, và dùng Formula/Rollup để tính chênh lệch nếu cần
***
## Single select / Multi select / Status
Nhóm Field lựa chọn giúp chuẩn hoá dữ liệu (tránh gõ tự do), đồng thời hỗ trợ lọc/nhóm trong View.
### Single select
**Dùng khi:** mỗi record chỉ chọn 1 giá trị.
* Ví dụ: Purchase type (Capex/Opex), Priority (Low/Medium/High)
### Multi select
**Dùng khi:** record có thể gắn nhiều nhãn.
* Ví dụ: Tags, bộ phận liên quan
### Status
**Dùng khi:** theo dõi trạng thái làm việc.
* Status thường đi kèm Workflow (nếu có quy trình)
* Ví dụ: Draft/Pending/Approved/Rejected/Closed
Nếu trạng thái được điều phối bằng Workflow, nên chốt quy tắc chuyển trạng thái ở Workflow và dùng Status để hiển thị/nhóm.
### Thực hành tốt
* Tránh tạo quá nhiều lựa chọn ngay từ đầu. Bắt đầu tối thiểu, mở rộng theo Improve loop.
* Đặt tên lựa chọn rõ và nhất quán (không trùng nghĩa)
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
***
## User/People
**Dùng khi:** gán người chịu trách nhiệm, người yêu cầu, người phê duyệt, người tham gia.
Ví dụ:
* Requester (người yêu cầu)
* Approver (người phê duyệt)
* Assignee (người xử lý)
### Thực hành tốt
* Dùng User/People thay vì Text để:
* lọc theo người, nhóm theo người
* kết hợp quyền truy cập (access scope) và Workflow
* Phân biệt rõ:
* “Owner/Assignee” (người chịu trách nhiệm)
* “Watcher/Participants” (người theo dõi/tham gia)
Liên quan:
* [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
* [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
***
## Attachment
**Dùng khi:** cần đính kèm hoá đơn, báo giá, ảnh, tài liệu.
### Thực hành tốt
* Quy định rõ “đính kèm để làm gì” (audit, chứng từ, tham khảo)
* Nếu cần kiểm soát: đặt rule ở workflow/permission (ai được thêm/xoá)
* Không dùng Attachment để thay thế dữ liệu có cấu trúc (ví dụ danh sách item)
***
***
## Field mở rộng (tuỳ nhu cầu)
Nhóm Field này thường dùng khi app đã chạy ổn định và bắt đầu mở rộng trải nghiệm vận hành.
* [Mã vạch / QR (Barcode / QR)](/build-apps/data-modeling/barcode-qr)
* [Vị trí (Location)](/build-apps/data-modeling/location)
* [Đánh giá (Rating)](/build-apps/data-modeling/rating)
## Checklist chọn Field cho vòng đầu (khuyến nghị)
* Mỗi Entity có 1–2 field dễ nhận diện (Title/Code)
* Có Status nếu có vòng đời xử lý
* Có Date/Datetime cho các mốc quan trọng (submit/need-by/approved)
* Có User/People cho vai trò chính (requester/approver/assignee)
* Có Currency/Number cho các chỉ số cần đo (estimated cost, quantity)
* Attachment
* Auto number
* Sub-dataset (child table) chỉ thêm khi thực sự cần chứng từ
***
## Bước tiếp theo
* Tạo Field theo nhu cầu UI: [Tổng quan giao diện](/build-apps/ui-views/views-overview)
* Đặt controls đúng chỗ: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
* Dùng computed fields: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
# Công thức (Formula)
Source: https://learn.cleeksy.com/build-apps/data-modeling/formula
Tính toán trường dữ liệu bằng Formula.
Formula (công thức) là computed field dùng để tính ra một giá trị dựa trên các field khác. Formula giúp chuẩn hoá logic tính toán và giảm thao tác thủ công.
## Dùng khi nào?
* Cần tính **thành tiền**, **số ngày trễ**, **điểm ưu tiên**, hoặc trạng thái phụ (derived status)
* Cần chuẩn hoá cách hiển thị từ nhiều field (ví dụ: tạo “Display title”)
* Cần tạo điều kiện hỗ trợ lọc/nhóm (ví dụ: `Overdue = true/false`)
## Thực hành tốt
* Giữ công thức **đơn giản** và dễ kiểm chứng
* Ưu tiên dùng:
* [Tra cứu (Lookup)](/build-apps/data-modeling/lookup) để kéo dữ liệu liên kết
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup) để tổng hợp nhiều record
rồi mới dùng Formula để “kết hợp” kết quả nếu cần
## Ví dụ phổ biến
### 1) Thành tiền
`Amount = Quantity × Unit Price`
### 2) Overdue (quá hạn)
`Overdue = (Today > Need-by date) AND (Status chưa Closed)`
### 3) Tiêu đề hiển thị
`Display = Code + " — " + Title`
Chi tiết cú pháp và các toán tử nên được tiêu chuẩn hoá theo Reference để tránh mỗi app một kiểu.
Liên quan: [Bộ lọc & toán tử (Filters & operators)](/reference/filters-operators)
## Lưu ý
* Formula là field **chỉ đọc**
* Nếu công thức khó hiểu, nên tách thành 2–3 formula nhỏ để dễ kiểm thử
* Tránh dùng formula để “giấu” logic nghiệp vụ quan trọng — logic chuyển bước nên đặt ở Workflow/Controls
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
## Bước tiếp theo
* Tra cứu dữ liệu liên kết: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* Tổng hợp từ bảng con: [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
# Vị trí (Location)
Source: https://learn.cleeksy.com/build-apps/data-modeling/location
Lưu vị trí (Location) trong dữ liệu.
Location là Field dùng để lưu **vị trí** liên quan tới record (điểm giao nhận, kho, văn phòng, công trường…). Field này hỗ trợ điều phối, phân công và theo dõi hiện trạng theo địa điểm.
## Dùng khi nào?
* Quản lý tài sản theo địa điểm (asset theo kho/tầng/phòng)
* Giao nhận/điều phối theo điểm đến (delivery, pickup)
* Báo cáo theo khu vực (site, branch, region)
## Thiết kế dữ liệu gợi ý
### 1) Location dạng danh mục chuẩn hoá
Nếu tổ chức có danh sách địa điểm cố định:
* Tạo Entity `Location` (danh mục)
* Liên kết bằng **Data Connection** để tránh nhập tự do
Liên quan: [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
### 2) Location dạng nhập tự do
Nếu vị trí thay đổi nhiều hoặc mang tính mô tả:
* Dùng Text/Long text (kèm quy ước nhập)
* Có thể thêm validation (format, bắt buộc)
Liên quan: [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
## Pattern thường dùng
### Pattern A — “Asset → Location”
* Asset có field Location (Data Connection) trỏ tới danh mục Location
* Dùng Lookup (tham chiếu) để hiển thị khu vực/địa chỉ (nếu cần)
Liên quan: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
### Pattern B — “Work order theo site”
* Work order có Location + Assignee
* View nhóm theo Location để điều phối
Liên quan: [Tổng quan giao diện](/build-apps/ui-views/views-overview)
## Lưu ý vận hành
* Tránh để người dùng nhập nhiều biến thể cùng một địa điểm (lệch dữ liệu)
* Nếu cần báo cáo theo địa điểm: ưu tiên danh mục chuẩn hoá (Entity Location + Data Connection)
* Nếu dùng giữa các app: publish/consume tạo **connected app (kết nối ứng dụng)** rồi mới liên kết/tham chiếu
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
## Bước tiếp theo
* Nhận diện nhanh bằng quét mã: [Mã vạch / QR (Barcode / QR)](/build-apps/data-modeling/barcode-qr)
# Tra cứu (Lookup)
Source: https://learn.cleeksy.com/build-apps/data-modeling/lookup
Tham chiếu dữ liệu từ nguồn liên kết bằng Lookup.
Lookup (tra cứu) là một **computed field** dùng để “kéo lên” (hiển thị) giá trị từ record liên kết. Lookup giúp tránh nhập trùng dữ liệu và giúp View/Workflow có đủ thông tin để xử lý.
## Dùng khi nào?
* Cần hiển thị thông tin từ record liên kết mà không muốn nhập lại
(ví dụ: hiển thị `Supplier name` trên Purchase Request)
* Cần dùng thông tin “tham chiếu” để lọc/nhóm trong View
(ví dụ: nhóm Purchase Request theo Department của Requester)
* Cần đưa một vài field từ record liên kết vào màn hình làm việc hằng ngày
## Lookup hoạt động như thế nào?
Lookup cần một “đường liên kết” tới record nguồn. Trong Cleeksy, đường liên kết thường là:
* **Data Connection field** (liên kết record theo quan hệ)
* Hoặc một **Sub-entity (bảng con)** nếu thiết kế dữ liệu theo cấu trúc phân cấp (tuỳ bài toán)
Lookup sau đó chọn **field nguồn** để hiển thị (text, number, date…).
Lookup là field **chỉ đọc**. Giá trị thay đổi khi record nguồn thay đổi; Lookup không phải nguồn dữ liệu chuẩn.
## Điều kiện tiên quyết (quan trọng)
### 1) Lookup trong cùng App
* Data Connection liên kết trực tiếp giữa các Entity trong app
* Lookup kéo dữ liệu từ Entity được liên kết
### 2) Lookup giữa các App
* App nguồn **publish** dữ liệu
* App hiện tại **consume** → tạo **connected app (kết nối ứng dụng)**
* Sau đó Data Connection mới có thể trỏ tới connected app đó, và Lookup mới kéo được field
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
## Cách cấu hình (khung thao tác)
1. Tạo **Data Connection field** (hoặc cấu trúc Sub-entity phù hợp)
2. Tạo field mới loại **Lookup**
3. Chọn:
* “Nguồn liên kết” (Data Connection/Sub-entity)
* “Field cần tra cứu” (field nguồn)
4. Kiểm tra hiển thị ở View và quyền truy cập (nếu cần)
## Ví dụ 1: Trong cùng App (Supplier trên Purchase Request)
* Entity: `Purchase Request`
* Entity: `Supplier`
* Field `Supplier` trên Purchase Request: **Data Connection** trỏ tới Supplier
* Field `Supplier name` trên Purchase Request: **Lookup** từ `Supplier → Name`
Kết quả: người dùng chỉ cần chọn Supplier, các thông tin liên quan hiển thị tự động.
## Ví dụ 2: Giữa các App (Purchase Request → Procurement)
Bối cảnh:
* App Purchase Request publish các request đã Approved
* App Procurement consume để tạo connected app “Approved Purchase Requests”
Thiết kế trong app Procurement:
* Field `Request`: Data Connection trỏ tới Connected app đã được kết nối
* Lookup `Request title`, `Estimated cost`, `Requester`… từ field `Request`
Kết quả: Procurement làm việc trên app của mình nhưng vẫn nhìn thấy thông tin chuẩn từ app nguồn.
## Lưu ý thiết kế và hiệu năng
* Ưu tiên Lookup cho **vài field quan trọng** phục vụ thao tác; tránh kéo “tất cả mọi thứ”
* Nếu cần tổng hợp trên nhiều record liên quan → cân nhắc [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* Nếu cần tính toán dựa trên nhiều field → cân nhắc [Công thức (Formula)](/build-apps/data-modeling/formula)
## Khắc phục sự cố
### Lookup trống dù đã liên kết
* Record chưa chọn liên kết (Data Connection đang rỗng)
* Field nguồn chưa được publish (đối với cross-app)
* App tiêu thụ chưa consume đúng connected app
* Quyền truy cập không đủ để xem record/field nguồn
### Lookup không đúng như kỳ vọng
* Đang tra cứu nhầm field nguồn
* Field nguồn thay đổi nhưng chưa được cập nhật theo quy tắc vận hành (ownership chưa rõ)
Tham khảo: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
## Bước tiếp theo
* Tổng hợp nhiều record: [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* Tính toán từ nhiều field: [Công thức (Formula)](/build-apps/data-modeling/formula)
* Liên kết dữ liệu: [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
# Đánh giá (Rating)
Source: https://learn.cleeksy.com/build-apps/data-modeling/rating
Thu thập đánh giá (Rating) trong dữ liệu.
Rating là Field dùng để ghi nhận **điểm đánh giá** (ví dụ 1–5 sao) cho một record. Rating thường dùng trong các app thu thập phản hồi (feedback), đánh giá chất lượng dịch vụ, hoặc chấm điểm nội bộ.
## Dùng khi nào?
* Thu thập mức độ hài lòng sau khi hoàn tất yêu cầu
* Chấm điểm chất lượng xử lý (service quality)
* Đánh giá nhà cung cấp, sản phẩm, hoặc quy trình
## Thiết kế dữ liệu gợi ý
### 1) Rating + Comment
* Rating (1–5)
* Comment (Long text) để giải thích điểm đánh giá
### 2) Rating theo tiêu chí (scorecard đơn giản)
Nếu cần nhiều tiêu chí:
* Dùng nhiều field Rating (Speed, Quality, Communication…)
* Dùng Formula/Rollup để tính điểm tổng (tuỳ thiết kế)
Liên quan:
* [Công thức (Formula)](/build-apps/data-modeling/formula)
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
## Pattern thường dùng
### Pattern A — “Feedback sau khi Closed”
* Workflow: chỉ cho phép nhập Rating khi record đã ở trạng thái Closed
* Permissions: chỉ requester hoặc người nhận dịch vụ được đánh giá
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
### Pattern B — “Đánh giá Supplier”
* Entity Supplier có field Rating tổng
* Các lần đánh giá lưu ở Sub-dataset hoặc Entity riêng, sau đó Rollup/Average để ra điểm tổng
Liên quan: [Bảng con (Child table)](/build-apps/data-modeling/sub-dataset-child-table)
## Lưu ý vận hành
* Chốt thang điểm (1–5 hay 1–10) và ý nghĩa từng mức
* Tránh dùng rating như “thước đo duy nhất”; kết hợp chỉ số vận hành (thời gian xử lý, số lần rework…)
Liên quan: [Vòng lặp cải tiến (Improve loop)](/foundations/improve-loop)
## Bước tiếp theo
* Tính điểm tổng: [Công thức (Formula)](/build-apps/data-modeling/formula)
* Tổng hợp nhiều lần đánh giá: [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
# Bản ghi (Record)
Source: https://learn.cleeksy.com/build-apps/data-modeling/records
Tạo, cập nhật và quản lý record trong entity.
Record là “đơn vị công việc” chạy xuyên suốt trong app: khi người dùng tạo một record, dữ liệu được lưu trong **Entity**, hiển thị qua **View**, và (nếu có) được điều phối qua **Workflow**.
## Record là gì?
* **Entity** là cấu trúc dữ liệu (giống “bảng”)
* **Record** là một bản ghi cụ thể (giống “dòng”) trong Entity
* **Field** là thuộc tính của record (giống “cột”)
Liên quan:
* [Thực thể dữ liệu (Entity)](/build-apps/data-modeling/entities)
* [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
## Khi nào record được tạo?
Record có thể được tạo theo nhiều cách (tuỳ cấu hình app):
* Tạo trực tiếp trong **Grid view** hoặc một View khác
* Tạo từ **Form / Record layout** (màn hình chi tiết)
* Tạo bởi **automation** (nếu có quy tắc tự động hoá)
* Được tạo/nhận từ tích hợp (API/Webhook/Portal) tuỳ thiết kế
## Vòng đời record trong một quy trình
Trong nhiều app, record đại diện cho một “case” hoặc “request” có vòng đời:
1. **Tạo** (Draft)
2. **Gửi / chuyển bước** (Pending…)
3. **Xử lý / phê duyệt** (Approved/Rejected/In progress…)
4. **Hoàn tất / đóng** (Closed/Completed)
Thiết kế vòng đời record thường cần:
* một field trạng thái (Status)
* một workflow điều phối theo trạng thái
Tham khảo: [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
## Thực hành tốt khi thiết kế record
### 1) Field hiển thị (primary display) phải “đọc được”
Khi record được liên kết ở nơi khác, field hiển thị giúp người dùng nhận diện đúng record.
Ví dụ: `PR-00123 — Mua laptop cho nhân viên mới`
### 2) Phân biệt “dữ liệu nhập” và “dữ liệu hệ thống”
* Dữ liệu nhập: do người dùng cung cấp (title, description, estimated cost…)
* Dữ liệu hệ thống: do hệ thống tính/ghi (created at, created by, computed fields…)
### 3) Tránh để nhiều vai trò cùng sửa cùng một field
Nếu nhiều vai trò cần tương tác, nên:
* tách field theo ownership (ai chịu trách nhiệm field nào)
* đặt controls bằng Roles/Permissions và Workflow
Tham khảo: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
### 4) Chuẩn hoá “điểm bắt đầu” của record
Ví dụ Purchase Request:
* Record được tạo ở Draft
* Chỉ khi đủ dữ liệu mới cho phép chuyển sang Pending Approval (validation + workflow)
## Record và liên kết dữ liệu giữa các app
Khi record cần tham chiếu dữ liệu từ app khác:
* Ưu tiên publish/consume khi cần chia sẻ có kiểm soát
* Dùng **Data Connection** khi cần liên kết record để tham chiếu. Nếu liên kết **giữa các App**, App tiêu thụ cần có connected app (kết nối ứng dụng) từ publish/consume trước.
Liên quan:
* [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
* [Kết nối dữ liệu hai chiều (Data Connection two-way)](/build-apps/data-modeling/data-connection-two-way)
## Ví dụ: Record Purchase Request
Một record Purchase Request thường có:
* title, purchase type, estimated cost
* requester, department
* status (Draft/Pending/Approved/Rejected/Closed)
* các mốc thời gian (created at, approved at…)
Record này:
* hiển thị trong Grid view cho thao tác hằng ngày
* có Record layout để nhập/chỉnh
* chạy workflow để phê duyệt và theo dõi tiến độ
Liên quan:
* [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
* [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
## Bước tiếp theo
* Thiết kế field phù hợp: [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
* Thiết kế UI: [Tổng quan giao diện](/build-apps/ui-views/views-overview)
* Thiết kế workflow: [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
# Tổng hợp (Rollup)
Source: https://learn.cleeksy.com/build-apps/data-modeling/rollup
Tổng hợp dữ liệu từ nguồn liên kết bằng Rollup.
Rollup (tổng hợp) là computed field dùng để **gộp** dữ liệu từ nhiều record liên quan thành một giá trị để theo dõi và ra quyết định.
## Dùng khi nào?
* Cần tính **tổng** từ bảng con (Sub-entity), ví dụ: tổng tiền của các dòng hàng
* Cần đếm số lượng record liên quan, ví dụ: số lần approve/rework, số item
* Cần theo dõi các chỉ số đơn giản theo cấu trúc dữ liệu hiện có
## Nguồn dữ liệu cho Rollup
Nếu tổng hợp dựa trên dữ liệu **giữa các app**, publish/consume là bước bắt buộc để tạo **connected app (kết nối ứng dụng)**. Rollup sẽ tổng hợp trên các record liên kết thông qua Data Connection tới connected app đó.
Rollup thường tổng hợp trên một “danh sách record” đến từ:
* **Sub-entity (bảng con)** (ví dụ Order Items trong Order)
* Hoặc **Data Connection** nếu Data Connection trả về nhiều record liên quan
Nếu cần kéo một giá trị từ *một* record liên kết → dùng [Tra cứu (Lookup)](/build-apps/data-modeling/lookup).
## Các kiểu tổng hợp thường gặp
* Sum (tổng)
* Count (đếm)
* Min/Max (nhỏ nhất/lớn nhất)
* Average (trung bình)
## Ví dụ: Tổng chi phí Purchase Request
* Entity: `Purchase Request`
* Field `Items`: Sub-entity chứa các dòng item
* Rollup `Total cost`: tổng `Item amount` của tất cả dòng item
## Lưu ý thiết kế
* Rollup nên dùng cho chỉ số quan trọng (ít nhưng đúng)
* Nếu công thức phức tạp (điều kiện, rẽ nhánh) → cân nhắc [Công thức (Formula)](/build-apps/data-modeling/formula)
## Bước tiếp theo
* Tra cứu từ record liên kết: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* Tính toán theo biểu thức: [Công thức (Formula)](/build-apps/data-modeling/formula)
# Bảng con (Child table)
Source: https://learn.cleeksy.com/build-apps/data-modeling/sub-dataset-child-table
Thiết kế bảng con để lưu dữ liệu dạng dòng chi tiết.
Sub-dataset (bảng con/child table) là một **Field** trong Entity, dùng để biểu diễn dữ liệu **phân cấp**: một record “cha” chứa nhiều record “con”.
Ví dụ phổ biến:
* Order có nhiều Order Items
* Purchase Request có nhiều Request Items
* Case có nhiều Activity/Comments
## Dùng khi nào?
* Dữ liệu con **luôn** thuộc về dữ liệu cha (cùng ownership, cùng vòng đời)
* Cần nhập và xem danh sách item ngay trong màn hình của record cha
* Cần tổng hợp nhanh (tổng tiền, số lượng) trên các item
## Khi nào không nên dùng?
* Dữ liệu con có ownership khác, hoặc có vòng đời độc lập
* Cần chia sẻ dữ liệu con cho nhiều app/đơn vị khác nhau
* Cần nhiều workflow riêng cho dữ liệu con
Trong các trường hợp này, cân nhắc tách ra Entity riêng và liên kết bằng [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way).
## Thiết kế tối thiểu
Với một Entity cha (ví dụ `Purchase Request`):
* Field `Items`: Sub-dataset
* Trong Sub-dataset, khai báo các cột/field cho item:
* Item name (Text)
* Quantity (Number)
* Unit price (Currency)
* Amount (Formula)
Sau đó:
* Rollup `Total cost` = Sum(Items.Amount)
Liên quan:
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* [Công thức (Formula)](/build-apps/data-modeling/formula)
## Thực hành tốt
* Giữ Sub-dataset “đủ dùng” cho vòng đầu (không tạo quá nhiều cột)
* Chuẩn hoá cách đặt tên: `Items`, `Line items`, `Activities`
* Tạo Rollup cho các chỉ số quan trọng (tổng tiền, số item)
* Đặt controls phù hợp: ai được thêm/sửa/xoá item (Roles/Workflow)
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
## Ví dụ: Purchase Request
* `Purchase Request` có Sub-dataset `Request Items`
* Người dùng nhập nhiều dòng hàng ngay trong record
* Hệ thống rollup tổng chi phí để phục vụ phê duyệt
## Bước tiếp theo
* Tổng hợp dữ liệu: [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* Liên kết dữ liệu giữa Entity/App: [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
# API portal (cổng API)
Source: https://learn.cleeksy.com/build-apps/integrations/api-portal
Cung cấp API để đọc/ghi dữ liệu có kiểm soát.
API portal (cổng API) là một loại **Data source** cho phép hệ thống ngoài **đọc dữ liệu ra** (pull) và/hoặc **ghi dữ liệu vào** (push) theo các endpoint được cấu hình.
Liên quan:
* [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
* [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
* [Bảo mật (Security)](/build-apps/integrations/security-tokens)
***
## Authentication/token (khái niệm cơ bản)
API thường cần token để xác thực và giới hạn quyền truy cập.
Khuyến nghị:
* Token theo môi trường (dev/test/prod)
* Xoay token định kỳ (rotation)
* Không hardcode token trong client public (frontend)
***
## Endpoint patterns (mẫu endpoint thường dùng)
### Read (GET)
* Lọc theo trạng thái/thời gian/owner
* Phân trang khi dữ liệu lớn
### Create (POST)
* Map payload vào field cho phép
* Trả về ID/mã record để theo dõi
### Update (PUT/PATCH)
* Cập nhật theo record ID hoặc External ID
* Chỉ mở field cần thiết, tránh cập nhật vượt ownership
### Upload (tệp đính kèm)
* Giới hạn loại file/dung lượng
* Chỉ định record đích rõ ràng
***
## Ví dụ
### Ví dụ 1 — Hệ thống ngoài tạo ticket vào app
* POST tạo record Ticket
* Workflow phân công người xử lý và gửi thông báo
### Ví dụ 2 — Hệ thống ngoài pull danh sách record theo filter
* GET trả về record theo trạng thái và thời gian
* Client lưu External ID để đối chiếu
***
## Error handling (xử lý lỗi)
* Chuẩn hoá lỗi: thiếu field, sai định dạng, không đủ quyền
* Retry có kiểm soát để tránh tạo trùng (dựa trên External ID hoặc idempotency key)
* Log requestId/correlationId để truy vết (nếu có)
***
## Guardrails
* Chỉ mở endpoint và field cần thiết
* Thiết lập filter để giới hạn phạm vi dữ liệu được đọc
* Tách token read-only và write
# Kết nối ứng dụng (Connected app)
Source: https://learn.cleeksy.com/build-apps/integrations/connected-app
Kết nối giữa các app bằng Data source loại Connected app.
Connected app (kết nối ứng dụng) là **một loại Data source** dùng để kết nối dữ liệu giữa các app trong Cleeksy DOP.
Connected app giải quyết hai nhu cầu chính:
* **Submit/push**: app A gửi dữ liệu sang app B (ví dụ: bàn giao yêu cầu đã duyệt sang app Procurement)
* **Pull/read**: app A đọc dữ liệu từ app B để hiển thị hoặc tổng hợp (tuỳ cấu hình cho phép)
***
## Khi nào cần Connected app?
* Có 2 app với trách nhiệm khác nhau và cần bàn giao dữ liệu qua lại
* Cần tách ownership (source of truth / nguồn dữ liệu chuẩn) theo từng app
* Cần kiểm soát quyền chia sẻ: app nào được gửi/đọc dữ liệu, phạm vi record nào được phép
***
## Cách hoạt động (mô hình publish/consume)
Connected app thường có 2 phần:
### 1) Provider app (app cung cấp)
* Chọn Entity và phạm vi dữ liệu cần chia sẻ
* Chọn hình thức chia sẻ:
* Cho phép **submit** (nhận dữ liệu từ app khác)
* Cho phép **pull** (cho app khác đọc dữ liệu)
* Thiết lập field được phép và điều kiện lọc (nếu có)
### 2) Consumer app (app sử dụng)
Khi cấu hình các field cần dùng dữ liệu từ app khác, hệ thống sẽ yêu cầu chọn một **Data source** (loại *Connected app*) đã được chia sẻ từ provider.
Điểm quan trọng:
* Không cần “tạo consumption riêng” trước rồi mới tạo field.
**Việc consume xảy ra trong lúc cấu hình** Data Connection / Lookup / Rollup (chọn Connected app và xác nhận quyền truy cập).
***
## Connected app dùng được ở đâu?
### A) Data Connection (một chiều): gửi hoặc liên kết
* Nếu mục tiêu là **submit/bàn giao** dữ liệu: dùng Data Connection (một chiều) để map field và đẩy record sang provider app (tuỳ cấu hình cho phép).
Liên quan: [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
### B) Lookup: tham chiếu để hiển thị
Khi provider cho phép pull, Lookup có thể tham chiếu các field cần hiển thị từ record liên quan.
Liên quan: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
### C) Rollup: tổng hợp
Tổng hợp số liệu từ dữ liệu đã liên kết/tham chiếu (khi provider cho phép pull).
Liên quan: [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
***
## Ví dụ: Purchase Request → Procurement (bàn giao để thực hiện mua sắm)
Mục tiêu: sau khi Purchase Request được duyệt, thông tin cần được **bàn giao** sang app Procurement để thực hiện mua sắm.
### Thiết lập đúng (đơn giản và thực dụng)
1. **Procurement (provider)** tạo Data source loại **Connected app** để **nhận submission**
* Chọn Entity đích (ví dụ: Procurement Task/PO Request)
* Chọn các field được phép nhận (item, số lượng, ngân sách, requester, deadline…)
2. **Purchase Request (consumer)** dùng **Data Connection (một chiều)** để submit
* Tạo field Data Connection (one-way) trỏ tới Connected app của Procurement
* Map các field cần gửi
* Kích hoạt theo workflow (ví dụ: khi Approved thì tạo/đẩy sang Procurement)
3. (Tuỳ chọn) Procurement publish trạng thái xử lý để Purchase Request pull hiển thị tiến độ
* Khi cần theo dõi, provider có thể cho phép pull để consumer dùng Lookup/Rollup hiển thị trạng thái.
***
## Guardrails (để không lệch dữ liệu)
* Chốt source of truth: Procurement là nơi quản lý dữ liệu mua sắm; Purchase Request không “nhập lại” các trường đã thuộc Procurement.
* Chỉ chia sẻ đủ dùng: giới hạn field và phạm vi record.
* Tránh coupling quá chặt: ưu tiên liên kết theo ID/record thay vì sao chép dữ liệu.
Liên quan: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
# Cổng dữ liệu (Data source)
Source: https://learn.cleeksy.com/build-apps/integrations/data-sources-overview
Tổng quan các loại Data source để nhận và chia sẻ dữ liệu.
Data source (cổng dữ liệu) là **cấu hình “điểm kết nối”** để một app có thể **nhận dữ liệu vào** hoặc **cung cấp dữ liệu ra** một cách có kiểm soát.
Trong Cleeksy DOP:
* **Entity trong app** là nơi lưu dữ liệu vận hành (source of truth / nguồn dữ liệu chuẩn).
* **Data source** là “cổng” giúp dữ liệu đi vào/đi ra khỏi app, hoặc kết nối giữa các app.
***
## 1) Data source dùng để làm gì?
* **Nhận dữ liệu vào** (submit/push): người dùng hoặc hệ thống khác gửi dữ liệu vào app.
* **Cung cấp dữ liệu ra** (pull/read): hệ thống khác lấy dữ liệu từ app theo phạm vi được phép.
* **Kết nối giữa các app**: gửi/bàn giao hoặc đọc dữ liệu giữa các app nội bộ.
***
## 2) Các loại Data source trong Cleeksy DOP
### Request portal (cổng nội bộ)
Biểu mẫu/luồng để người dùng nội bộ submit dữ liệu theo quyền truy cập được kiểm soát.
### Public portal (cổng công khai)
Biểu mẫu để người ngoài hệ thống submit dữ liệu (khách hàng/đối tác…), có kiểm soát field và truy cập.
### Connected app (kết nối ứng dụng)
Kết nối giữa các app trong Cleeksy DOP để:
* **submit** dữ liệu sang app khác
* và/hoặc **pull** dữ liệu từ app khác (tuỳ cấu hình)
Liên quan: [Kết nối ứng dụng (Connected app)](/build-apps/integrations/connected-app)
### Integration: Webhook & API (tích hợp)
* **Webhook**: hệ thống ngoài đẩy dữ liệu/sự kiện vào app theo thời gian thực.
* **API**: trao đổi có cấu trúc:
* GET: cung cấp dữ liệu ra
* POST/PUT: nhận dữ liệu vào
* Upload: nhận đính kèm theo cấu hình
Liên quan:
* [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
* [API portal (cổng API)](/build-apps/integrations/api-portal)
***
## 3) Quy tắc chọn đúng loại Data source (decision rules)
* Người dùng submit theo form nội bộ → Request portal
* Người ngoài submit → Public portal
* Kết nối giữa các app nội bộ:
* gửi/bàn giao hoặc đọc dữ liệu giữa app → Connected app
* Tích hợp hệ thống ngoài:
* event-driven / push → Webhook
* đồng bộ có cấu trúc → API
***
## 4) Ví dụ: Purchase Request → Procurement (bàn giao)
* Procurement tạo Data source loại **Connected app** để nhận submission.
* Purchase Request dùng **Data Connection (một chiều)** để submit dữ liệu sang Procurement khi Approved.
Liên quan: [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
# Cổng nội bộ (Internal portal)
Source: https://learn.cleeksy.com/build-apps/integrations/internal-portal
Tạo cổng nội bộ để người dùng gửi dữ liệu vào app.
Internal portal (cổng nội bộ) là một loại **Data source** dùng để người dùng nội bộ **submit dữ liệu vào app** theo một form đã được kiểm soát.
Internal portal phù hợp khi cần “đầu vào chuẩn” cho quy trình mà không yêu cầu mọi người phải mở toàn bộ app để tạo record trực tiếp.
Liên quan:
* [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
* [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
* [Thông báo & giao việc](/build-apps/notifications-tasks)
***
## 1) Internal submission patterns (mẫu nộp yêu cầu nội bộ)
### Pattern A — Request → Workflow
* Người dùng submit yêu cầu
* Record vào trạng thái “Submitted/Pending”
* Workflow phân công người xử lý, có thể kèm approvals
Dùng cho: Purchase request, IT ticket, HR request.
### Pattern B — Intake theo phòng ban/role
* Nhiều nhóm cùng submit vào một app
* Dữ liệu được gắn “Department/Team” để điều phối
Dùng cho: service desk, yêu cầu hỗ trợ vận hành.
### Pattern C — Chuẩn hoá đầu vào + giảm dữ liệu rác
* Form chỉ mở field cần thiết
* Có hướng dẫn ngay trên form (“nên gửi gì / không nên gửi gì”)
* Có rule tối thiểu để chặn thiếu dữ liệu
Dùng cho: các luồng có tần suất submit cao.
***
## 2) Form tạo record trong Entity đích
Mỗi lần submit sẽ:
* Tạo một record mới trong **Entity** được chọn
* Map dữ liệu vào các field cho phép
* Kích hoạt workflow/automation (nếu đã thiết kế)
Thực hành tốt:
* Chỉ đưa ra 5–10 field quan trọng để xử lý
* Các field hệ thống (status mặc định, created by/at…) nên set bằng workflow/automation
Liên quan: [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
***
## 3) Role gating (giới hạn ai được submit và ai được xem)
Internal portal cần chốt rõ 2 câu hỏi:
### Ai được submit?
* Theo nhóm/role nội bộ (tuỳ cấu hình workspace/app)
* Có thể mở rộng dần khi form đã ổn định
### Ai được xem record sau khi submit?
* Người submit có thể xem “Yêu cầu của tôi”
* Team xử lý xem “Chờ xử lý”
* Các role khác chỉ xem khi có nhu cầu nghiệp vụ
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
***
## 4) Kết hợp workflow và phân công
Internal portal thường đi với mô hình:
* Submit → Pending
* Workflow chuyển bước, phân công người phụ trách, và thông báo
Gợi ý thực hành:
* Tạo Grid view “Chờ xử lý” cho team xử lý
* Tạo view “Yêu cầu của tôi” cho người gửi theo dõi
Liên quan:
* [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
* [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
***
## 5) Guardrails vận hành
* Có mã/định danh rõ (Auto number) để tránh thất lạc
* Có rule chống trùng (tuỳ bài toán)
* Có hướng dẫn submit đúng chuẩn ngay trên form
* Có kênh phản hồi khi bị reject (lý do rõ ràng)
Liên quan:
* [Đánh số tự động (Auto number)](/build-apps/data-modeling/auto-number)
* [Rà soát & vận hành (App review)](/build-apps/app-review)
***
## Bước tiếp theo
* Nhận dữ liệu từ người ngoài: [Cổng công khai (Public portal)](/build-apps/integrations/public-portal)
* Tích hợp hệ thống ngoài: [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal), [API portal (cổng API)](/build-apps/integrations/api-portal)
* Kết nối giữa app: [Kết nối ứng dụng (Connected app)](/build-apps/integrations/connected-app)
# Cổng công khai (Public portal)
Source: https://learn.cleeksy.com/build-apps/integrations/public-portal
Tạo cổng công khai để thu thập dữ liệu từ bên ngoài.
Public portal (cổng công khai) là một loại **Data source** dùng để nhận dữ liệu từ bên ngoài tổ chức (khách hàng/đối tác/ứng viên…). Public portal tạo record vào Entity đích theo form đã cấu hình.
Liên quan:
* [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
* [Cổng nội bộ (Internal portal)](/build-apps/integrations/internal-portal)
* [Rà soát & vận hành (App review)](/build-apps/app-review)
***
## 1) Khi nào dùng Public portal?
* Thu thập yêu cầu/đăng ký từ khách hàng hoặc đối tác
* Onboarding nhà cung cấp (supplier onboarding)
* Thu thập phản hồi (feedback) hoặc báo lỗi (bug report)
* Nhận hồ sơ ứng viên (khi có quy trình xử lý)
Nếu người submit là nội bộ, ưu tiên [Cổng nội bộ (Internal portal)](/build-apps/integrations/internal-portal) để dễ quản trị quyền.
***
## 2) Public form patterns (mẫu form công khai)
### Pattern A — One-shot submission + xử lý nội bộ
Form công khai chỉ tạo record và đưa vào trạng thái “Pending review”.
Dùng cho: contact form, đăng ký dịch vụ, yêu cầu báo giá.
### Pattern B — Submission + theo dõi bằng mã
Sau khi submit, trả về mã (auto number) để người gửi tra cứu/trích dẫn khi cần hỗ trợ.
Dùng cho: support request, warranty claim.
### Pattern C — Submission + bước xác minh
Record đi vào bước “Verify” trước khi chuyển sang xử lý chính, nhằm lọc dữ liệu rác.
Dùng cho: supplier onboarding, lead intake.
***
## 3) Validation (chặn lỗi trước khi vào hệ thống)
Thực hành tốt:
* Bắt buộc field tối thiểu để có thể xử lý (tên, liên hệ, nội dung)
* Kiểm tra định dạng cơ bản (email/phone/date)
* Giới hạn độ dài text để tránh payload bất thường
* Với attachment: giới hạn loại file và dung lượng theo chính sách vận hành
Validation nên kết hợp:
* Validation ngay trên form (nếu có hỗ trợ)
* Workflow bước “Review/Verify” để kiểm tra nghiệp vụ
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
***
## 4) Giảm spam/lạm dụng (nguyên tắc an toàn khi công khai)
Public portal cần thiết kế để “nhận đúng thứ cần nhận” và hạn chế abuse:
### A) Giới hạn bề mặt
* Chỉ mở các field cần thiết
* Tránh thu thập dữ liệu nhạy cảm nếu không bắt buộc
* Hạn chế attachment khi không cần
### B) Đưa vào hàng chờ kiểm duyệt
* Record vào trạng thái “Pending review”
* Team nội bộ xác minh trước khi xử lý tiếp
### C) Chống trùng và làm sạch dữ liệu
* Dùng Auto number để định danh
* Dùng rule phát hiện trùng (email/phone + thời gian) nếu bài toán cần
* Có bước “Reject/Discard” rõ ràng để loại dữ liệu rác
### D) Đặt kỳ vọng cho người gửi
* Hướng dẫn rõ ngay trên form (nội dung hợp lệ, tài liệu cần kèm…)
* Thông báo thời gian phản hồi dự kiến
Khi cần lớp kiểm tra bổ sung từ hệ thống ngoài (token theo chiến dịch, kiểm tra danh sách chặn…), có thể kết hợp với [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal) hoặc [API portal (cổng API)](/build-apps/integrations/api-portal) để kiểm tra trước khi ghi nhận.
***
## 5) Kết hợp workflow để xử lý an toàn
Một luồng tối thiểu thường dùng:
* New submission → Pending review → Accepted/Rejected → Processing → Closed
Gợi ý:
* Tạo view “Pending review” cho người kiểm duyệt
* Log lý do reject để cải tiến form và giảm spam
Liên quan: [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
***
## Bước tiếp theo
* Nhận dữ liệu từ hệ thống ngoài: [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
* Tích hợp có cấu trúc: [API portal (cổng API)](/build-apps/integrations/api-portal)
* Intake nội bộ: [Cổng nội bộ (Internal portal)](/build-apps/integrations/internal-portal)
# Chia sẻ dữ liệu (Publish/Consume)
Source: https://learn.cleeksy.com/build-apps/integrations/publish-consume-overview
Chia sẻ dữ liệu giữa các app bằng publish/consume.
Publish/Consume là cơ chế chia sẻ dữ liệu **giữa các app** trong Cleeksy DOP theo mô hình **provider → consumer**:
* **Provider app** chọn dữ liệu cần chia sẻ (publish) dưới dạng một *dataset* (tập record + field cho phép + điều kiện lọc).
* **Consumer app** sử dụng dữ liệu đã publish khi cấu hình **Data source** loại *Connected app* và các field như **Data Connection / Lookup / Rollup**.
Mục tiêu của publish/consume là:
* Chốt **ownership** và **source of truth (nguồn dữ liệu chuẩn)** theo từng app
* Cho phép kết nối end-to-end mà vẫn kiểm soát quyền truy cập
* Giảm việc sao chép dữ liệu giữa các app
Liên quan:
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
* [Kết nối ứng dụng (Connected app)](/build-apps/integrations/connected-app)
***
## 1) Khi nào cần publish/consume?
Publish/consume phù hợp khi:
* Dữ liệu thuộc ownership của **một app khác** nhưng cần dùng trong app hiện tại
* Cần bàn giao công việc giữa các nhóm (ví dụ: Request → Procurement)
* Cần hiển thị hoặc tổng hợp dữ liệu từ app khác trong dashboard/report
Nếu dữ liệu nằm trong **cùng app**, thường không cần publish/consume; có thể liên kết nội bộ bằng Data Connection và dùng Lookup/Rollup theo thiết kế.
***
## 2) “Dataset” trong publish nghĩa là gì?
Dataset (tập dữ liệu publish) thường bao gồm:
* **Nguồn record**: từ một Entity hoặc một tập record theo filter
* **Field được phép chia sẻ**: chỉ publish các field đủ dùng
* **Điều kiện lọc**: giới hạn phạm vi record được chia sẻ (theo trạng thái, phòng ban, thời gian…)
* **Quyền truy cập**: ai/role nào ở consumer được dùng dataset này
Publish/consume không tạo “bảng dữ liệu mới”. Dữ liệu vẫn nằm trong Entity của provider app.
***
## 3) Cách publish (provider app)
Thiết lập publish nên theo thứ tự:
1. Chốt **ownership**: dataset này do provider chịu trách nhiệm cập nhật
2. Chọn **Entity** và phạm vi record cần chia sẻ (filter)
3. Chọn **field** được phép chia sẻ
4. Thiết lập quyền truy cập (ai/role nào được dùng)
5. Đặt tên dataset rõ ràng (ví dụ: “Approved Purchase Requests”)
Thực hành tốt:
* Publish “đủ dùng”: tránh publish quá rộng
* Đặt tiêu chí rõ: record nào được chia sẻ (ví dụ: Status = Approved)
***
## 4) Cách consume (consumer app)
Consumer app sử dụng dữ liệu đã publish thông qua **Data source** loại *Connected app*.
Điểm quan trọng:
* Không cần “làm một bước consume riêng” rồi mới tạo field.
* Trong thực tế, **consume xảy ra trong lúc cấu hình** Connected app hoặc khi cấu hình field cần dùng dữ liệu (Data Connection/Lookup/Rollup). Hệ thống sẽ yêu cầu chọn dataset đã publish và xác nhận quyền truy cập.
Sau khi kết nối xong, dataset đã publish trở thành dữ liệu “có thể chọn” trong:
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
* [Kết nối dữ liệu hai chiều (Data Connection two-way)](/build-apps/data-modeling/data-connection-two-way)
* [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
***
## 5) Tác động phân quyền (permission implications)
Publish/consume luôn chịu ràng buộc quyền từ **cả hai phía**:
### Quyền từ provider (giới hạn tối đa)
* Provider quyết định record nào và field nào được chia sẻ.
* Consumer không thể đọc/ghi vượt quá phạm vi provider đã publish.
### Quyền trong consumer (giới hạn theo vai trò người dùng)
* Trong consumer app, từng role vẫn chỉ thấy/được thao tác theo permissions nội bộ.
* Một dataset được consume chỉ nên “lộ” với các role thực sự cần dùng.
Thực hành tốt:
* Tách dataset theo mục tiêu nghiệp vụ (ví dụ: “Approved” vs “All”)
* Không publish field nhạy cảm nếu không cần
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
***
## 6) One-way vs two-way (hướng dẫn chọn)
Publish/consume là cơ chế chia sẻ dữ liệu; còn **hướng trao đổi** thường thể hiện qua **Data Connection**.
### One-way (một chiều)
Dùng khi cần **bàn giao/submit** dữ liệu và chốt ownership rõ:
* App A gửi dữ liệu sang App B để App B xử lý
* App B là source of truth cho phần dữ liệu mà B vận hành
Liên quan:
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
### Two-way (hai chiều)
Dùng khi cần **đồng bộ hai phía** và có lý do rõ ràng:
* Hai app cùng cần cập nhật và cùng cần thấy thay đổi
* Có guardrail để tránh xung đột và coupling quá chặt
Chỉ nên dùng khi:
* Trách nhiệm cập nhật đã được định nghĩa rất rõ
* Có quy tắc xử lý xung đột hoặc hạn chế phạm vi field đồng bộ
Liên quan: [Kết nối dữ liệu hai chiều (Data Connection two-way)](/build-apps/data-modeling/data-connection-two-way)
***
## 7) Ví dụ ngắn: Purchase Request → Procurement (bàn giao)
Mục tiêu: Purchase Request bàn giao yêu cầu đã duyệt sang Procurement để thực hiện mua sắm.
Thiết lập gợi ý:
1. Procurement publish/cho phép dataset và kênh nhận (Connected app) theo phạm vi cần thiết
2. Purchase Request dùng Data Connection (một chiều) để submit dữ liệu sang Procurement khi Approved
3. (Tuỳ chọn) Procurement publish trạng thái để Purchase Request tham chiếu tiến độ
***
## Checklist nhanh
* [ ] Provider chốt ownership và publish “đủ dùng”
* [ ] Consumer chỉ consume dataset cần thiết cho nghiệp vụ
* [ ] Permission được kiểm tra ở cả provider và consumer
* [ ] One-way ưu tiên cho bàn giao; two-way chỉ dùng khi có lý do rõ
# Bảo mật (Security)
Source: https://learn.cleeksy.com/build-apps/integrations/security-tokens
Nguyên tắc bảo mật khi dùng portal, webhook và API.
Trang này tổng hợp nguyên tắc bảo mật thực dụng khi cấu hình **Data source**.
Liên quan:
* [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
* [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
* [API portal (cổng API)](/build-apps/integrations/api-portal)
***
## Nên làm (do)
* Quản lý token/secret như mật khẩu: lưu an toàn, xoay định kỳ, tách theo môi trường.
* Giới hạn phạm vi dữ liệu: chỉ mở field/record cần thiết, đặt filter rõ ràng.
* Ghi log tối thiểu để truy vết: thời điểm, nguồn gọi, kết quả, mã yêu cầu (nếu có).
***
## Không nên làm (don’t)
* Không đưa token vào tài liệu công khai, ảnh chụp màn hình, hoặc đoạn chat.
* Không hardcode token trong frontend.
* Không mở endpoint/field “cho tiện”.
* Không dùng chung một token cho mọi hệ thống và mọi môi trường.
***
## Thực hành theo loại Data source
### Portal (Internal/Public)
* Form chỉ mở field cần thiết.
* Public portal nên có bước “Review/Verify” để lọc dữ liệu rác.
### Webhook
* Có idempotency (eventId) để tránh tạo trùng.
* Giới hạn field được phép ghi.
### API
* Token theo môi trường + rotation.
* Tách read-only vs write.
### Connected app
* Chốt ownership (source of truth).
* Chỉ chia sẻ “đủ dùng” theo dataset và quyền.
* One-way ưu tiên cho bàn giao; two-way chỉ dùng khi có lý do rõ.
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
***
## Khi cần mức bảo mật doanh nghiệp
Các chính sách hardening (SSO, SCIM, audit nâng cao, IP allowlist, quy trình key management…) nên được áp dụng theo ngữ cảnh doanh nghiệp.
# Webhook portal (cổng webhook)
Source: https://learn.cleeksy.com/build-apps/integrations/webhook-portal
Nhận dữ liệu từ hệ thống ngoài qua webhook.
Webhook portal (cổng webhook) là một loại **Data source** cho phép hệ thống ngoài **đẩy dữ liệu/sự kiện vào app** theo kiểu *event-driven*.
Webhook phù hợp khi cần nhận dữ liệu theo thời gian thực (ví dụ: đơn hàng, sự kiện thanh toán, ticket từ hệ thống khác).
Liên quan:
* [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
* [API portal (cổng API)](/build-apps/integrations/api-portal)
* [Bảo mật (Security)](/build-apps/integrations/security-tokens)
***
## Payload basics (cơ bản về payload)
Webhook thường gửi payload dạng JSON. Payload thực dụng nên có:
* **eventType** (loại sự kiện)
* **eventId** (mã sự kiện duy nhất) để chống tạo trùng
* **timestamp** (thời điểm)
* **data** (dữ liệu nghiệp vụ) để map vào Entity đích
Thực hành tốt:
* Giữ payload gọn, chỉ chứa dữ liệu cần thiết
* Nếu dữ liệu lớn, gửi “key” và để app gọi API pull bổ sung
***
## Mapping vào Entity (tạo/cập nhật record)
Khi cấu hình webhook:
* Chọn **Entity đích**
* Chọn **field được phép ghi**
* Xác định quy tắc: tạo mới hay cập nhật theo khoá (ví dụ: External ID)
Gợi ý:
* Có field “External ID” để liên kết với hệ thống ngoài
* Có field “Webhook Event ID” để log idempotency
***
## Error handling patterns (mẫu xử lý lỗi)
### Pattern 1 — Acknowledge nhanh, xử lý sau
Nhận webhook → ghi nhận tối thiểu → xử lý workflow/automation phía sau.
### Pattern 2 — Validate trước khi ghi
Kiểm tra field bắt buộc/định dạng. Nếu sai, đưa vào trạng thái “Invalid” để đội vận hành xử lý.
### Pattern 3 — Dead-letter view
Tạo view “Webhook errors” để theo dõi record lỗi và có checklist khắc phục (mapping/field/permission).
Liên quan: [Rà soát & vận hành (App review)](/build-apps/app-review)
***
## Idempotency (tránh tạo trùng)
Webhook thường bị retry. Cần idempotency bằng cách:
* Nhận **eventId** từ payload
* Lưu eventId vào Entity
* Nếu eventId đã tồn tại → bỏ qua hoặc cập nhật theo quy tắc
Thực hành tốt:
* Idempotency theo “eventId + eventType”
* Với cập nhật, ưu tiên cập nhật theo “External ID” của đối tượng nghiệp vụ (orderId, ticketId…)
***
## Guardrails (an toàn khi công khai)
* Không để webhook URL/token lộ ra ngoài
* Giới hạn field được phép ghi
* Có logging tối thiểu để truy vết (thời điểm, eventId, kết quả)
Liên quan: [Bảo mật (Security)](/build-apps/integrations/security-tokens)
***
## Bước tiếp theo
* Khi cần tích hợp có cấu trúc: [API portal (cổng API)](/build-apps/integrations/api-portal)
* Khi cần nối app nội bộ: [Kết nối ứng dụng (Connected app)](/build-apps/integrations/connected-app)
# Thông báo & giao việc
Source: https://learn.cleeksy.com/build-apps/notifications-tasks
Thông báo và giao việc trong Cleeksy DOP.
Notifications & tasks là cơ chế giúp người dùng nhận biết “việc cần làm” trong hệ thống. Trong Cleeksy DOP có hai lớp:
* **Built-in notifications**: hệ thống tự thông báo theo sự kiện vận hành (được thiết kế sẵn).
* **Configurable notifications**: cấu hình thêm bằng **Automation rules** (gửi thông báo/email theo điều kiện).
Mục tiêu không phải “gửi nhiều”, mà là **đúng người – đúng lúc – có chỗ để xử lý**.
Liên quan:
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
* [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
* [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules)
* [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
***
## 1) Built-in notifications trong Cleeksy DOP
Built-in notifications tập trung vào các sự kiện “có trách nhiệm” (accountability). Khi một người được giao trách nhiệm hoặc được đưa vào luồng xử lý, hệ thống sẽ tự gửi thông báo vào **Inbox**.
### A) Thông báo theo workflow step (bước quy trình)
Trong workflow, mỗi bước (step) thường có:
* **Person in charge** (người phụ trách): chịu trách nhiệm xử lý bước.
* **CC / For information** (người nhận thông tin): theo dõi, hỗ trợ, hoặc giám sát.
Khi workflow **enter step** (bản ghi đi vào bước):
* Người phụ trách nhận thông báo “có việc được giao”.
* Người CC nhận thông báo “có việc cần theo dõi” (tuỳ cấu hình).
### B) Nhắc việc theo hạn (due/overdue)
Khi một task sắp tới hạn hoặc quá hạn:
* Hệ thống gửi thông báo nhắc người phụ trách.
* Có thể mở rộng bằng automation để escalate (tuỳ chính sách).
Built-in notifications không thay thế UI. Mỗi thông báo tốt nên dẫn về một nơi xử lý rõ ràng: view “Chờ xử lý” hoặc record layout.
Liên quan: [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
***
## 2) Tasks trong workflow: “việc” gắn với step
Trong Cleeksy DOP, **task** thường được hiểu là “việc tại một step”:
* Có người phụ trách (assignee/person in charge)
* Có thời hạn (nếu quy trình cần)
* Có trạng thái xử lý (đang chờ/đang làm/hoàn tất theo bước)
Thiết kế workflow tốt thường làm rõ:
* Bước nào là “chờ xử lý” (có người chịu trách nhiệm)
* Bước nào chỉ là “thông tin” (CC)
***
## 3) Tasks trong Project: Kanban và quản lý công việc theo dự án
Ngoài app, Cleeksy DOP còn có **Project** để tổ chức công việc theo dự án:
* Project có **Kanban** để quản lý task theo cột trạng thái.
* Khi một người được assign vào task của Project, hệ thống cũng có thể thông báo vào Inbox.
Tình huống dùng phổ biến:
* Theo dõi việc triển khai (implementation tasks) khi xây app
* Theo dõi việc vận hành/cải tiến theo sprint (improvement tasks)
Workflow tasks và Project tasks phục vụ hai ngữ cảnh khác nhau:
Workflow task gắn với record/step trong app; Project task gắn với kế hoạch dự án.
***
## 4) Configurable notifications bằng Automation rules
Ngoài built-in, có thể dùng **Automation rules** để:
* Gửi thông báo khi record chuyển trạng thái (submit/approve/reject/close)
* Gửi email nhắc hạn theo lịch (daily digest, weekly digest)
* Gọi webhook/API để đẩy sự kiện ra hệ thống ngoài
Quy tắc thiết kế:
* Chỉ gửi theo **sự kiện quan trọng** (milestone), tránh gửi theo mọi thay đổi nhỏ.
* Thông báo phải trả lời được: “việc gì – ai làm – làm ở đâu”.
Liên quan: [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
***
## 5) Pattern phân công (assignment patterns)
### Pattern 1 — Assign theo field trên record
Record có field `Assignee` (User/People). Khi đổi step/trạng thái, automation hoặc workflow set người xử lý.
### Pattern 2 — Assign theo role/nhóm
Tạo backlog view cho một role (ví dụ “Procurement”) để mọi người “nhặt việc”.
### Pattern 3 — Approver theo người duyệt
Approver là field hoặc rule; người duyệt được thông báo khi bước duyệt bắt đầu.
### Pattern 4 — Escalation khi quá hạn
Nếu quá hạn, thêm thông báo cho quản lý hoặc chuyển người xử lý (cần guardrail rõ).
***
## 6) Tránh spam (guardrails)
* **Ưu tiên Inbox + backlog view** thay vì ping liên tục
* **Gộp thông báo theo nhịp** (digest) cho nhắc hạn
* **Một sự kiện → một thông báo có thể hành động**
* **Không làm lộ dữ liệu**: thông báo phải tuân thủ permissions
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
***
## Ví dụ: Purchase Request → Procurement
* Khi requester submit: built-in/automation thông báo tới Approver
* Khi approver approve/reject: thông báo lại cho requester
* Khi Approved và bàn giao sang App Procurement:
* App nguồn publish
* App Procurement kết nối **Connected app (kết nối ứng dụng)**
* Task procurement được assign theo role hoặc theo `Assignee`
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
***
## Checklist nhanh
* [ ] Có view “Chờ xử lý” cho từng vai trò
* [ ] Built-in notifications được hiểu rõ theo step/person in charge/CC
* [ ] Automation chỉ dùng cho sự kiện quan trọng và có guardrail chống spam
* [ ] Nhắc hạn theo digest nếu số lượng lớn
# Bảng điều khiển (Dashboard view)
Source: https://learn.cleeksy.com/build-apps/ui-views/dashboard-view
Tạo Dashboard view để tổng hợp chỉ số và trạng thái.
Dashboard là View dành cho tổng quan: khối lượng công việc, tiến độ, chất lượng và điểm nghẽn. Dashboard phù hợp cho quản lý, chủ quy trình và các stakeholder cần quan sát tình hình.
## Dùng khi nào?
* Cần theo dõi KPI vận hành (SLA, số đơn, tỷ lệ hoàn tất)
* Cần nhìn nhanh bottleneck (đơn chờ duyệt, đơn quá hạn)
* Cần “đo để cải tiến” theo Improve loop
Liên quan: [Vòng lặp cải tiến (Improve loop)](/foundations/improve-loop)
## Thiết kế Dashboard “đủ dùng”
* 3–7 chỉ số cốt lõi (ít nhưng đúng)
* Mỗi chỉ số phải dẫn tới hành động (ví dụ “Đơn quá hạn” → danh sách cần xử lý)
* Phân tách theo góc nhìn (theo phòng ban, theo người xử lý, theo trạng thái)
## Ví dụ: Purchase Request
* Tổng số đơn theo trạng thái
* Số đơn quá hạn theo phòng ban
* Thời gian xử lý trung bình (nếu có dữ liệu)
* Top lý do bị reject (nếu có field reason)
## Lưu ý
* Dashboard không thay thế Analytics Hub; dashboard ưu tiên “vận hành” còn Analytics Hub ưu tiên “phân tích”
* Tránh nhồi quá nhiều biểu đồ khiến mất định hướng
# Dạng sơ đồ (Gantt view)
Source: https://learn.cleeksy.com/build-apps/ui-views/gantt-view
Thiết lập Gantt view để theo dõi theo thời gian.
View Gantt hiển thị record theo sơ đồ Gantt (Gantt). View này phù hợp để quan sát kế hoạch, chồng chéo và tiến độ theo ngày/tuần/tháng.
## Dùng khi nào?
* Có công việc cần theo dõi theo lịch (start/end/due date)
* Cần quan sát tải công việc theo thời gian (theo người, theo nhóm)
* Cần nhìn nhanh các giai đoạn của một quy trình có lịch
## Điều kiện dữ liệu tối thiểu
* Có ít nhất một field ngày:
* `Start date` và `End date`, hoặc
* `Due date` (nếu chỉ theo deadline)
Nếu record đại diện cho task có nhiều dòng con, cân nhắc lưu task ở Entity riêng (thay vì Sub-dataset) để theo dõi Gantt rõ hơn.
Liên quan: [Bảng con (Child table)](/build-apps/data-modeling/sub-dataset-child-table)
## Cấu hình gợi ý
* Timeline range: tuần/tháng tuỳ bài toán
* Group theo:
* Assignee (người xử lý)
* Status (trạng thái)
* Location (vị trí) nếu vận hành theo địa điểm
* Filter: chỉ hiển thị các task “đang làm” hoặc “trong kỳ”
## Lưu ý thiết kế
* Gantt phù hợp khi dữ liệu thời gian **đủ chuẩn** (đúng định dạng, không bỏ trống)
* Nếu dùng cross-app:
* publish/consume tạo **connected app (kết nối ứng dụng)** trước
* sau đó Data Connection/Lookup dùng nguồn dữ liệu để hiển thị trên Gantt (tuỳ thiết kế)
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
## Ví dụ: Procurement plan
* Entity: `Procurement Task`
* Fields: Title, Status, Start date, Due date, Assignee
* View Gantt: group theo Assignee để xem tải theo tuần
## Bước tiếp theo
* Danh sách vận hành: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
* Điều phối theo trạng thái: [Dạng thẻ (Kanban view)](/build-apps/ui-views/kanban-view)
# Dạng bảng (Grid view)
Source: https://learn.cleeksy.com/build-apps/ui-views/grid-view
Thiết lập Grid view để quản lý dữ liệu dạng bảng.
View dạng bảng (Grid) là giao diện danh sách phổ biến nhất để theo dõi và xử lý record theo kiểu bảng (giống spreadsheet). Grid phù hợp cho thao tác hàng ngày: rà soát, lọc, nhóm, cập nhật và kiểm tra dữ liệu.
## Dùng khi nào?
* Cần làm việc với **danh sách record** (tạo mới, cập nhật, kiểm tra)
* Cần lọc theo trạng thái/điều kiện (ví dụ “Chờ duyệt”, “Quá hạn”)
* Cần nhóm theo người/đơn vị/nhãn (ví dụ “Theo phòng ban”)
* Cần thao tác theo danh sách thay vì timeline
## Các cấu hình quan trọng
### 1) Columns (cột hiển thị)
* Chỉ giữ các cột cần cho thao tác của vai trò đó
* Ghim (pin) cột định danh: mã, tên, trạng thái
### 2) Filter (lọc)
* Tạo view “Chờ duyệt”, “Của tôi”, “Quá hạn”
* Filter nên phản ánh mục tiêu vận hành, không chỉ để “xem cho đủ”
### 3) Group (nhóm)
* Nhóm theo Status để xem backlog theo trạng thái
* Nhóm theo Assignee/Owner để phân tải công việc
### 4) Sort (sắp xếp)
* Ưu tiên theo deadline/priority để xử lý đúng thứ tự
## Thực hành tốt
* Đặt tên View theo mục tiêu (“Chờ duyệt”, “Quá hạn”, “Của tôi”)
* Dùng 1–2 Grid view “xương sống” cho mỗi role, tránh tạo quá nhiều view trùng
* Nếu cần thông tin từ entity/app khác:
* Liên kết bằng Data Connection
* Hiển thị bằng Lookup (tham chiếu)
* Với liên kết giữa app: publish/consume tạo **connected app (kết nối ứng dụng)** trước
Liên quan: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
## Ví dụ: Purchase Request
* Grid “Chờ duyệt”: Filter Status = Pending
* Grid “Quá hạn”: Filter **Need-by date \< Today** AND **Status** chưa Closed
* Nhóm theo Department để xem tải theo phòng ban
## Khắc phục sự cố
* “Không thấy record cần xử lý” → kiểm tra Filter và quyền truy cập
* “Cột quá nhiều, khó dùng” → giảm cột và tạo Lookup cho vài field quan trọng
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
# Dạng thẻ (Kanban view)
Source: https://learn.cleeksy.com/build-apps/ui-views/kanban-view
Thiết lập Kanban view để theo dõi theo trạng thái.
View dạng Kanban hiển thị record dưới dạng thẻ (card) theo các cột trạng thái. Đây là cách trực quan để theo dõi tiến độ, giới hạn WIP và ưu tiên xử lý.
## Dùng khi nào?
* Quy trình có các trạng thái rõ (Draft → Pending → Approved/Rejected…)
* Cần quan sát backlog theo trạng thái và bottleneck
* Cần thao tác theo luồng công việc thay vì danh sách dài
## Điều kiện tiên quyết
* Entity có field Status (hoặc trạng thái do Workflow điều phối)
* Trạng thái được định nghĩa nhất quán (tránh quá nhiều cột)
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
## Cấu hình gợi ý
* Column mapping: mỗi cột = một trạng thái
* Card content: hiển thị 2–4 thông tin đủ quyết định (mã, tiêu đề, deadline, owner)
* Filter: tạo board riêng cho từng role (ví dụ “Của tôi”)
## Thực hành tốt
* Giới hạn số trạng thái “đang làm” để giảm phân tán
* Nếu chuyển trạng thái ảnh hưởng quyền/logic, nên điều phối bằng Workflow thay vì kéo thả tuỳ tiện
* Kết hợp Grid view để rà soát dữ liệu và Kanban để điều phối theo trạng thái
Liên quan: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
## Ví dụ: Purchase Request
* Cột: Draft / Pending / Approved / Rejected / Closed
* Board cho Approver: Filter “Pending”
* Board cho Requester: Filter “Của tôi”
## Khắc phục sự cố
* “Cột không đúng trạng thái” → kiểm tra mapping Status/Workflow
* “Không thấy thẻ” → kiểm tra filter và quyền truy cập
# Bố cục bản ghi (Record layout)
Source: https://learn.cleeksy.com/build-apps/ui-views/record-layout
Thiết kế Record layout để nhập và xem thông tin.
Record layout là màn hình chi tiết của một record: nơi nhập dữ liệu, xem thông tin, và thực hiện các thao tác như submit/approve/update.
## Dùng khi nào?
* Cần trải nghiệm nhập liệu rõ ràng (form)
* Cần thao tác theo quy trình (review/approve/reject)
* Cần trình bày dữ liệu theo nhóm logic (thông tin yêu cầu, chi phí, lịch sử…)
## Nguyên tắc thiết kế
### 1) Nhóm field theo mục tiêu thao tác
* Thông tin định danh (mã, tiêu đề, trạng thái)
* Thông tin nghiệp vụ chính (deadline, chi phí, loại yêu cầu)
* Thông tin người liên quan (requester, approver, assignee)
* Ghi chú / đính kèm (nếu có)
### 2) Giảm sai sót
* Đặt field quan trọng lên đầu
* Giảm field không cần thiết trong vòng đầu
* Dùng select/status thay cho text tự do khi cần chuẩn hoá
Liên quan: [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
### 3) Bám vào controls
* Field nào được sửa ở trạng thái nào?
* Ai được sửa?
* Chuyển bước ở đâu?
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
## Ví dụ: Purchase Request
Bố cục gợi ý:
* Header: PR Code, Title, Status
* Section “Yêu cầu”: loại mua sắm, need-by date, lý do
* Section “Chi phí”: estimated cost, currency
* Section “Dòng hàng”: Sub-dataset items (nếu có)
* Section “Phê duyệt”: approver, quyết định, ghi chú
* Section “Tài liệu”: attachment
## Khắc phục sự cố
* “Form quá dài” → tách thành nhóm, giảm field, cân nhắc Sub-dataset
* “Người dùng sửa sai chỗ” → siết role/permission và workflow checkpoints
# Tổng quan
Source: https://learn.cleeksy.com/build-apps/ui-views/views-overview
Hiểu các loại view và cách chọn view phù hợp.
Views là cách người dùng **nhìn thấy và thao tác dữ liệu** trong app. Mỗi View là một “cửa sổ làm việc” được cấu hình để:
* Hiển thị đúng tập record cần xử lý
* Đưa thao tác quan trọng lên tuyến đầu (lọc/nhóm/sắp xếp, tạo mới, xử lý)
* Phù hợp với vai trò (role) và kịch bản (scenario)
Trong Cleeksy, View thường gắn với một **Entity** (thực thể dữ liệu). Một Entity có thể có nhiều View để phục vụ các mục tiêu khác nhau (ví dụ: “Chờ duyệt”, “Quá hạn”, “Theo phòng ban”).
***
## Nguyên tắc thiết kế UI theo tư duy Cleeksy
### 1) UI bám vào Scenario và Role
Thiết kế UI bắt đầu từ câu hỏi: “Trong scenario này, vai trò nào cần làm gì — theo thứ tự nào?”. Sau đó mới quyết định cần View nào và mỗi View hiển thị gì.
### 2) Ít View nhưng đúng việc
UI dễ dùng thường có ít View hơn dự đoán ban đầu. Mỗi View nên có một mục tiêu rõ:
* “Xem và lọc danh sách”
* “Xử lý theo trạng thái”
* “Xem tổng quan và theo dõi chỉ số”
* “Làm việc chi tiết trên một record”
### 3) View không thay thế phân quyền
View có thể lọc/ẩn/hiện cột để phù hợp thao tác, nhưng **quyền truy cập** vẫn do Roles/Permissions quyết định.
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
***
## Các loại View thường dùng
### View dạng bảng (Grid)
Phù hợp để:
* Xem danh sách record dạng bảng (giống spreadsheet)
* Thao tác theo danh sách, rà soát dữ liệu
* Cấu hình Filter / Group / Sort / Columns
Liên quan: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
### View dạng Kanban
Phù hợp để:
* Theo dõi công việc theo các cột trạng thái
* Tập trung vào WIP (work-in-progress)
Kanban thường yêu cầu Entity có Status/Workflow để tạo các cột.
Liên quan: [Dạng thẻ (Kanban view)](/build-apps/ui-views/kanban-view)
### View Dashboard (bảng điều khiển)
Phù hợp để:
* Theo dõi tổng quan (volume, tiến độ, bottleneck)
* Cập nhật tình hình cho quản lý/stakeholder
* Gắn với Improve loop (đo và cải tiến)
Liên quan: [Bảng điều khiển (Dashboard view)](/build-apps/ui-views/dashboard-view)
### Bố cục bản ghi (Record layout)
Phù hợp để:
* Làm việc chi tiết trên một record (create / review / approve / update)
* Tổ chức field theo nhóm, nhấn mạnh thông tin quan trọng
* Giảm sai sót khi nhập liệu bằng bố cục rõ ràng
Liên quan: [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
### View Gantt (timeline)
Phù hợp để:
* Theo dõi kế hoạch theo thời gian (start/end/due date)
* Quan sát tiến độ theo tuyến thời gian cho các công việc có lịch
Liên quan: [Dạng sơ đồ (Gantt view)](/build-apps/ui-views/gantt-view)
***
## Cách chọn View nhanh
* Cần “danh sách + lọc + rà soát” → ưu tiên **View dạng bảng (Grid)**
* Cần “theo dõi theo trạng thái + ưu tiên xử lý” → cân nhắc **View dạng Kanban**
* Cần “tổng quan cho quản lý + đo lường” → thêm **View Dashboard**
* Cần “form nhập liệu + thao tác chi tiết + phê duyệt” → đầu tư **Bố cục bản ghi**
* Cần “kế hoạch theo thời gian” → cân nhắc **View Gantt**
***
## Ví dụ: Purchase Request → Procurement
### App Purchase Request
* View dạng bảng: “Chờ duyệt”, “Quá hạn”
* View dạng Kanban: theo dõi tiến độ duyệt (khi có Workflow/Status)
* Bố cục bản ghi: tổ chức theo nhóm thông tin và quy trình xử lý
### App Procurement (mở rộng)
* App Procurement **consume** → tạo **connected app (kết nối ứng dụng)** (từ publish/consume) “Approved Purchase Requests”
* Data Connection liên kết tới record Purchase Request trong connected app
* Lookup (tham chiếu) hiển thị các field cần thiết để làm việc (ví dụ: tiêu đề, chi phí, requester)
* View dạng bảng theo dõi các task mua sắm theo trạng thái và ưu tiên
Với liên kết giữa các app: publish/consume tạo **connected app (kết nối ứng dụng)** để Data Connection, Lookup và Rollup sử dụng.
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
***
## Thực hành tốt khi đặt tên và tổ chức View
* Tên View phản ánh mục tiêu: “Chờ duyệt”, “Của tôi”, “Quá hạn”, “Theo phòng ban”
* Tránh tạo nhiều View chỉ khác nhau nhẹ; ưu tiên dùng filter/group/sort trong cùng một View
* Ghim các cột định danh quan trọng (mã, tên) để dễ theo dõi
***
## Bước tiếp theo
* Thiết kế danh sách và bộ lọc: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
* Theo dõi theo trạng thái: [Dạng thẻ (Kanban view)](/build-apps/ui-views/kanban-view)
* Thiết kế màn hình chi tiết: [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
* Theo dõi tổng quan: [Bảng điều khiển (Dashboard view)](/build-apps/ui-views/dashboard-view)
* Theo dõi timeline: [Dạng sơ đồ (Gantt view)](/build-apps/ui-views/gantt-view)
# Phê duyệt (Approvals)
Source: https://learn.cleeksy.com/build-apps/workflows/approvals
Cấu hình bước phê duyệt và luồng quyết định.
Approvals là cơ chế phê duyệt trong quy trình: ghi nhận **quyết định** (approve/reject) theo checkpoint, đồng thời ràng buộc “ai được duyệt” và “khi nào được duyệt”.
Approvals thường đi cùng:
* **Process Builder** để điều phối trạng thái và checkpoint
* **Roles/Permissions** để kiểm soát quyền thao tác
* **Views & UI** để người duyệt thao tác nhanh và đúng
Liên quan:
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
* [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
* [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
***
## Dùng khi nào?
* Có điểm kiểm soát bắt buộc trước khi chuyển bước (ví dụ: duyệt chi phí)
* Cần audit: ai duyệt, duyệt lúc nào, duyệt với lý do gì
* Cần tách vai trò requester (tạo yêu cầu) và approver (phê duyệt)
Nếu chỉ cần rule tự động (ví dụ tự set trạng thái khi tạo record), có thể bắt đầu bằng [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules). Khi cần kiểm soát theo vai trò và quyết định, ưu tiên Approvals.
***
## Cấu phần tối thiểu của một bước phê duyệt
### 1) Ai là người duyệt (Approver)
Có thể chọn theo:
* Field `Approver` (User/People) trên record
* Rule theo phòng ban/role (tuỳ thiết kế phân quyền)
* Nhóm người duyệt theo cấp (tuỳ bài toán)
### 2) Khi nào được duyệt
* Chỉ cho phép duyệt ở trạng thái phù hợp (ví dụ Pending approval)
* Chỉ cho phép duyệt khi dữ liệu bắt buộc đã đủ (validation)
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
### 3) Quyết định và lý do
* Quyết định: Approved / Rejected
* Lý do/ghi chú: để tránh “reject không rõ vì sao”
* Thời điểm: Approved at / Rejected at
***
## Quy tắc thiết kế Approvals (decision rules)
### 1) Một bước duyệt = một mục tiêu kiểm soát
Ví dụ:
* Duyệt ngân sách
* Duyệt tuân thủ chính sách
* Duyệt đặt hàng
Tránh gộp nhiều mục tiêu vào một bước duyệt nếu sẽ làm người duyệt khó ra quyết định.
### 2) Phê duyệt dựa trên dữ liệu chuẩn
* Tổng chi phí nên được tính nhất quán (Number/Currency + Formula/Rollup)
* Đính kèm chứng từ nên rõ ràng (Attachment)
Liên quan:
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* [Công thức (Formula)](/build-apps/data-modeling/formula)
### 3) Chặn sửa dữ liệu sau khi duyệt (nếu cần)
Nếu sau khi approved mà requester vẫn sửa nội dung chính, quy trình sẽ “mất ý nghĩa”.
Giải pháp thường dùng:
* Khoá một số field ở trạng thái Approved/Closed
* Nếu cần chỉnh sửa, tạo cơ chế “rework” (đưa về trạng thái cần chỉnh sửa)
***
## Ví dụ: Purchase Request
### Trạng thái gợi ý
* Draft → Pending approval → Approved / Rejected → Closed
### Bước duyệt gợi ý
* Khi Pending approval:
* Approver xem: title, chi phí, need-by date, item list, chứng từ
* Approve → chuyển trạng thái Approved
* Reject → chuyển trạng thái Rejected + bắt buộc nhập lý do
### View hỗ trợ người duyệt
* Grid view “Chờ duyệt”: filter Status = Pending approval
* Record layout cho Approver: tập trung vào thông tin cần quyết định + nút hành động
Liên quan:
* [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
* [Dạng thẻ (Kanban view)](/build-apps/ui-views/kanban-view)
***
## Cross-app: bàn giao sau khi duyệt
Khi bước duyệt hoàn tất và cần bàn giao sang app khác (ví dụ Procurement):
* App nguồn publish các record đã Approved
* App đích kết nối **Connected app (kết nối ứng dụng)**
* App đích dùng Data Connection để liên kết record và dùng Lookup/Rollup để tham chiếu/tổng hợp
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
***
## Checklist triển khai nhanh
* [ ] Approver được xác định rõ (field hoặc rule)
* [ ] Chỉ duyệt được ở trạng thái phù hợp
* [ ] Có lý do khi reject (để cải tiến)
* [ ] View “Chờ duyệt” và record layout cho Approver đã tối ưu
# Luật tự động (Automation rules)
Source: https://learn.cleeksy.com/build-apps/workflows/automation-rules
Tự động hoá tác vụ bằng Automation rules.
Automation rules là cơ chế tự động hoá các thao tác lặp lại theo điều kiện. Mục tiêu là giảm thao tác tay và đảm bảo dữ liệu nhất quán khi app vận hành.
Automation phù hợp cho “luật nhỏ” và hoạt động nền. Khi quy trình có checkpoint phê duyệt/đổi trạng thái theo vai trò, ưu tiên [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder) và [Phê duyệt (Approvals)](/build-apps/workflows/approvals).
***
## Dùng khi nào?
* Tự set giá trị mặc định khi tạo record (Status = Draft, Created at…)
* Tự cập nhật field khi điều kiện thay đổi (ví dụ Overdue = true)
* Tự gửi thông báo khi tới hạn hoặc khi đổi trạng thái
* Tự tạo record liên quan (tuỳ bài toán)
* Tự đồng bộ field phục vụ View/Dashboard
***
## Khung tư duy Trigger → Condition → Action
### Trigger (kích hoạt)
* Khi record được tạo
* Khi field thay đổi
* Khi trạng thái chuyển bước (từ workflow)
### Condition (điều kiện)
* Status = Approved
* **Need-by date \< Today**
* Total cost > ngưỡng
### Action (hành động)
* Cập nhật field
* Tạo record
* Gửi thông báo
* Gọi webhook/API (khi tích hợp)
Liên quan: [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
***
## Quy tắc thiết kế Automation (decision rules)
### 1) Automation không thay thế quy trình
Automation giúp tự động hoá thao tác; “đường chạy” của quy trình vẫn nên được thiết kế bằng Process Builder nếu có nhiều bước và nhiều vai trò.
### 2) Tránh vòng lặp và side effects
* Tránh rule A cập nhật field X làm kích hoạt rule B cập nhật lại X
* Tách rule theo mục tiêu rõ ràng và kiểm thử bằng dữ liệu mẫu
### 3) Ưu tiên dùng field tính toán khi phù hợp
Nếu mục tiêu là “hiển thị/đo lường”, cân nhắc:
* [Công thức (Formula)](/build-apps/data-modeling/formula)
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
Automation nên dành cho hành động “gây thay đổi trạng thái/field” hoặc “tương tác bên ngoài”.
***
## Ví dụ nhanh
### Ví dụ 1 — Đánh dấu quá hạn
* Trigger: khi Need-by date hoặc Status thay đổi
* Condition: **Need-by date \< Today** AND **Status** chưa Closed
* Action: set field `Overdue` = true
### Ví dụ 2 — Tự set người xử lý
* Trigger: khi Status chuyển sang Approved
* Condition: loại yêu cầu = “Mua sắm”
* Action: set `Assignee` = người phụ trách procurement (tuỳ quy tắc tổ chức)
### Ví dụ 3 — Thông báo cho approver
* Trigger: khi record chuyển sang Pending approval
* Action: gửi thông báo tới Approver
***
## Checklist triển khai nhanh
* [ ] Trigger rõ ràng, tránh kích hoạt quá thường xuyên
* [ ] Condition có thể kiểm chứng bằng dữ liệu
* [ ] Action không tạo vòng lặp
* [ ] Kiểm thử với 5–10 record mẫu trước khi áp dụng rộng
# Thiết kế quy trình (Process Builder)
Source: https://learn.cleeksy.com/build-apps/workflows/process-builder
Thiết kế quy trình và trạng thái bằng Process Builder.
Process Builder là nơi thiết kế **quy trình xử lý** cho một Entity theo các bước (checkpoint) và trạng thái. Mục tiêu của Process Builder là biến một scenario vận hành thành “đường chạy” rõ ràng: ai làm gì, khi nào, và điều kiện nào được phép chuyển bước.
Liên quan:
* [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
* [Dạng thẻ (Kanban view)](/build-apps/ui-views/kanban-view)
***
## Dùng khi nào?
* Có vòng đời xử lý rõ (Draft → Pending → Approved/Rejected → Closed)
* Cần kiểm soát “ai được làm gì ở trạng thái nào”
* Cần checkpoint để đo lường và cải tiến (ví dụ: thời gian chờ duyệt, số lần rework)
Nếu chỉ cần luật tự động đơn giản (ví dụ tự set field khi tạo record) có thể bắt đầu bằng **Automation rules**. Khi quy trình có nhiều bước/phân quyền, ưu tiên Process Builder.
Liên quan: [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules)
***
## Process Builder gồm những gì?
### 1) Trạng thái (Status)
Trạng thái giúp nhìn nhanh tiến độ và hỗ trợ View (Grid/Kanban) nhóm theo bước xử lý.
### 2) Bước xử lý (checkpoint)
Checkpoint là mốc kiểm soát trong quy trình: tại mỗi mốc thường có:
* điều kiện vào bước
* thao tác được phép
* người chịu trách nhiệm
* điều kiện chuyển bước tiếp theo
### 3) Quy tắc chuyển bước
Quy tắc chuyển bước giúp tránh “nhảy bước” hoặc xử lý sai thứ tự.
***
## Quy tắc thiết kế quy trình (design rules)
### 1) Bắt đầu tối thiểu (minimal viable process)
* 3–5 trạng thái cho vòng đầu thường đủ: Draft / Pending / Approved / Rejected / Closed
* Chỉ thêm trạng thái khi có nhu cầu vận hành thật (Improve loop)
### 2) Chốt ownership theo trạng thái
* Ở trạng thái Draft: requester chỉnh sửa
* Ở trạng thái Pending: approver quyết định
* Ở trạng thái Approved: chuyển sang team thực thi (ví dụ Procurement)
Liên quan: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
### 3) Điều kiện chuyển bước phải đo được
Ví dụ:
* Chỉ cho submit khi các field bắt buộc đã đủ
* Chỉ cho approve khi tổng chi phí **≤** ngưỡng hoặc có đủ chứng từ (Attachment)
***
## Ví dụ: Quy trình Purchase Request
### Trạng thái gợi ý
* Draft: tạo và chỉnh sửa yêu cầu
* Pending approval: chờ duyệt
* Approved: được duyệt (bàn giao cho Procurement)
* Rejected: bị từ chối
* Closed: hoàn tất
### Checkpoint gợi ý
* Submit: Draft → Pending approval
* Approve: Pending approval → Approved
* Reject: Pending approval → Rejected
* Close: Approved → Closed
Khi cần bàn giao sang app khác (Procurement), publish/consume tạo **connected app (kết nối ứng dụng)** để app thực thi liên kết bằng Data Connection và tham chiếu bằng Lookup.
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
***
## Thực hành tốt
* Tên trạng thái dùng động từ/ý nghĩa rõ (“Chờ duyệt”, “Đã duyệt”, “Đã đóng”)
* Mỗi checkpoint nên gắn với một hành động rõ ràng (submit/approve/reject/close)
* Kết hợp View:
* Grid view để rà soát theo danh sách
* Kanban view để điều phối theo trạng thái
Liên quan: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
***
## Bước tiếp theo
* Thiết lập phê duyệt: [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
* Tự động hoá bước nhỏ: [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules)
# Ranh giới ứng dụng
Source: https://learn.cleeksy.com/foundations/app-boundaries
Quy tắc tách ứng dụng (app) và giữ cùng app theo ranh giới vận hành.
Trang này cung cấp các quy tắc thực dụng để quyết định **ranh giới app**: giữ trong một app hay tách thành nhiều app và kết nối với nhau.
## Mục tiêu
* Giảm rủi ro **mega-app** (quá lớn, khó thay đổi, khó vận hành)
* Làm rõ **ownership** (ai chịu trách nhiệm dữ liệu và quy trình)
* Thiết kế ranh giới giúp mở rộng theo thời gian mà không “đập đi làm lại”
Liên quan:
* [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
## App boundary là gì?
**App boundary** là ranh giới thiết kế để xác định:
* App này **sở hữu** dữ liệu nào (source of truth)
* App này **chịu trách nhiệm** quy trình nào
* Người dùng nào sử dụng app này như “màn hình làm việc chính”
* App khác sẽ **consume** dữ liệu như thế nào (khi cần)
## Quy tắc tách/ghép app (decision rules)
### 1) Tách theo ownership dữ liệu (nguồn dữ liệu)
**Nên tách** khi:
* Có nhiều bộ phận cùng “sở hữu” một tập dữ liệu và không thống nhất được nguồn
* Một tập dữ liệu cần quản trị chặt (chuẩn hoá, audit, quyền sửa) trong khi phần còn lại linh hoạt
**Nên giữ** khi:
* Một nhóm chịu trách nhiệm rõ ràng cho dữ liệu và quy trình, vòng đời record nằm trong cùng nhóm
### 2) Tách theo nhịp thay đổi (change cadence)
**Nên tách** khi:
* Một phần thay đổi thường xuyên (UI/luồng thao tác), phần còn lại ổn định (master/reference)
* Tốc độ thay đổi khác nhau gây “kẹt” release nếu nằm chung
### 3) Tách theo độ phức tạp workflow
**Nên tách** khi:
* Workflow có quá nhiều nhánh/ngoại lệ khác nhau theo phòng ban
* Một workflow đang cố gắng “ôm” nhiều quy trình khác nhau (mỗi bộ phận một kiểu)
**Nên giữ** khi:
* Có một luồng chính rõ ràng, số trạng thái và nhánh còn kiểm soát được
### 4) Tách theo đối tượng người dùng và UI
**Nên tách** khi:
* Hai nhóm người dùng có cách làm việc khác nhau hoàn toàn (màn hình, thao tác, ngôn ngữ nghiệp vụ)
* Một nhóm chỉ cần “theo dõi”, nhóm khác cần “xử lý” với công cụ khác
### 5) Tách theo biên giới rủi ro và kiểm soát (policy boundary)
**Nên tách** khi:
* Một phần cần kiểm soát nghiêm (duyệt, phân quyền trường, tuân thủ), phần khác mang tính cộng tác nhẹ
* Chính sách truy cập khác nhau đến mức “một app” trở nên khó cấu hình
Tham khảo: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
## Cây quyết định nhanh
Nếu không rõ ownership dữ liệu hoặc quy trình: cân nhắc tách theo đơn vị chịu trách nhiệm.
Nếu số nhánh và ngoại lệ tăng nhanh: tách theo luồng/nhóm người dùng.
Nếu UI/nhu cầu thao tác khác biệt lớn: tách app (hoặc tách experience).
Ưu tiên thiết kế một app “nguồn” publish và app khác consume để giảm coupling.
## Cách kết nối sau khi tách app (nguyên tắc tối thiểu)
* Chỉ định rõ “app nguồn” và dữ liệu được publish
* App còn lại consume theo nhu cầu thao tác (không sao chép tuỳ tiện)
* Hạn chế two-way nếu chưa có quy tắc đồng bộ rõ ràng
Xem chi tiết: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
## Ví dụ nhanh: Purchase Request và Procurement
Một cách tách phổ biến:
* **App A: Purchase Request**
Sở hữu dữ liệu yêu cầu mua (tạo, phê duyệt, trạng thái yêu cầu)
* **App B: Procurement**
Sở hữu dữ liệu xử lý mua sắm (nhà cung cấp, PO, trạng thái đặt hàng/nhận hàng)
Kết nối:
* App Procurement consume thông tin yêu cầu đã phê duyệt
* App Purchase Request consume trạng thái xử lý (read-only) để người yêu cầu theo dõi
## Dấu hiệu ranh giới đang sai
* Một app có quá nhiều entity “không liên quan” đến nhau
* Workflow thay đổi một phần kéo theo sửa nhiều chỗ khác
* Permissions trở nên rối và khó giải thích
* Không ai dám chỉnh vì sợ “vỡ” hệ thống
Khi gặp các dấu hiệu này, nên quay lại:
* SMALL để thu hẹp phạm vi
* Ownership để tách nguồn dữ liệu
* Controls để giảm logic phân tán
## Bước tiếp theo
* Quyết định chia sẻ dữ liệu: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
* Đặt controls đúng chỗ: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
* Tổ chức delivery theo vòng lặp: [SDD là gì](/sdd/overview)
# Cơ chế kiểm soát
Source: https://learn.cleeksy.com/foundations/controls-in-system
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 |
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.
## 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)
# Quản lý & chia sẻ dữ liệu
Source: https://learn.cleeksy.com/foundations/data-ownership-sharing
Quy tắc xác định nguồn dữ liệu chuẩn và chia sẻ dữ liệu giữa các app.
Trang này hướng dẫn cách thiết kế **ownership dữ liệu** và **chia sẻ dữ liệu** giữa các app để vận hành đầu-cuối mà vẫn tránh coupling và tránh “đồng bộ hỗn loạn”.
## Mục tiêu
* Xác định rõ **app nguồn (source of truth)** cho từng loại dữ liệu
* Chọn cách chia sẻ phù hợp: **publish/consume** hoặc **Data Connection**
* Biết khi nào dùng **one-way** và khi nào (hiếm) cần **two-way**
* Tránh các lỗi phổ biến: vòng lặp đồng bộ, dữ liệu mâu thuẫn, trách nhiệm không rõ
Liên quan:
* [Ranh giới App](/foundations/app-boundaries)
* [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
## Ownership dữ liệu là gì?
**Ownership** trả lời câu hỏi: *“Ai chịu trách nhiệm tính đúng, đủ, và vòng đời của dữ liệu này?”*
Trong hệ thống nhiều app, ownership thường được gắn với:
* một **đơn vị chịu trách nhiệm** (Procurement, Finance, HR…)
* một **app nguồn** (nơi dữ liệu được tạo/cập nhật chính)
* các **app tiêu thụ** (chỉ đọc hoặc cập nhật phần được uỷ quyền)
Ownership rõ ràng giúp đơn giản hoá phân quyền, giảm tranh chấp dữ liệu và giảm chi phí thay đổi.
## Nguyên tắc Source of truth (nguồn dữ liệu chuẩn)
Mỗi loại dữ liệu nên có **một** nguồn chính:
* Dữ liệu “yêu cầu” → thường thuộc app nơi yêu cầu được tạo và theo dõi
* Dữ liệu “xử lý nghiệp vụ chuyên môn” → thường thuộc app của bộ phận xử lý (ví dụ Procurement xử lý PO)
* Dữ liệu “danh mục chuẩn” → thường thuộc app master/reference (nếu có)
Nếu một dữ liệu có “nhiều nguồn”, hệ thống thường gặp:
* phiên bản không nhất quán (conflicting truth)
* khó audit (không biết ai đổi)
* khó thiết kế workflow và permissions
## Cách chia sẻ dữ liệu giữa các app
### 1) Publish / Consume (khuyến nghị mặc định)
Cơ chế chia sẻ theo hướng:
* App nguồn **publish** dữ liệu (một tập field/record được phép chia sẻ)
* App khác **consume** dữ liệu để sử dụng trong UI/workflow của mình
**Ưu điểm**
* Làm rõ ownership (ai publish là nguồn)
* Giảm coupling (consumer không cần “chạm” vào toàn bộ mô hình dữ liệu nguồn)
* Dễ kiểm soát quyền và phạm vi chia sẻ
**Khi nên dùng**
* Kết nối giữa các app theo kiểu handoff (bàn giao)
* Các app có ownership khác nhau
* Cần chia sẻ đọc (read-mostly) hoặc chia sẻ có kiểm soát
Xem triển khai: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
### 2) Data Connection fields (liên kết dữ liệu)
Liên kết record giữa entity/app để tham chiếu dữ liệu.
**Ưu điểm**
* Thao tác liên kết trực tiếp theo record
* Phù hợp cho các quan hệ dữ liệu rõ ràng
**Rủi ro**
* Dễ tạo coupling nếu dùng không kiểm soát
* Dễ “đẩy” người dùng sang app khác để sửa dữ liệu nguồn
Xem triển khai:
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
* [Kết nối dữ liệu hai chiều (Data Connection two-way)](/build-apps/data-modeling/data-connection-two-way)
## One-way vs Two-way: quy tắc quyết định
### One-way (khuyến nghị)
**Một chiều** nghĩa là:
* dữ liệu chảy theo một hướng: nguồn → tiêu thụ
* consumer không sửa dữ liệu nguồn (hoặc chỉ sửa phần được uỷ quyền thông qua cơ chế rõ ràng)
**Khi phù hợp**
* Hầu hết trường hợp handoff giữa bộ phận
* Trạng thái/thuộc tính thuộc ownership của app nguồn
* Mục tiêu là “xem để làm việc tiếp” hoặc “xem để theo dõi”
### Two-way (chỉ dùng khi cần, có điều kiện)
**Hai chiều** nghĩa là:
* cả hai phía có thể cập nhật một phần dữ liệu và cần phản chiếu lẫn nhau
**Chỉ nên dùng khi**
* ownership được định nghĩa theo “phân vùng field” (field ownership rõ)
* quy tắc đồng bộ và xử lý xung đột đã rõ
* có lý do nghiệp vụ thực sự (không chỉ vì tiện)
**Dấu hiệu không nên dùng two-way**
* “Ai cũng có thể sửa mọi thứ”
* “Cứ đồng bộ cho chắc”
* “Chưa rõ ai chịu trách nhiệm khi dữ liệu sai”
Two-way làm tăng chi phí vận hành và rủi ro dữ liệu mâu thuẫn. Nếu chưa chắc, nên bắt đầu bằng one-way.
## Thiết kế chia sẻ dữ liệu theo từng câu hỏi
1. **Dữ liệu thuộc về ai?** (đơn vị chịu trách nhiệm)
2. **Nguồn được tạo/cập nhật ở đâu?** (app nguồn)
3. **App khác cần dùng dữ liệu để làm gì?** (chỉ đọc, tham chiếu, hay cập nhật phần được uỷ quyền)
4. **Chỉ số và audit cần theo dõi gì?** (ai đổi, đổi khi nào, theo bước nào)
5. **Độ nhạy dữ liệu và policy truy cập** (ai được xem/sửa)
## Ví dụ: Purchase Request và Procurement
### Mô hình ownership đề xuất
* **App Purchase Request** (nguồn): sở hữu dữ liệu yêu cầu (mục đích, mô tả, chi phí dự kiến, trạng thái phê duyệt)
* **App Procurement** (nguồn): sở hữu dữ liệu xử lý mua sắm (PO, nhà cung cấp, trạng thái đặt hàng/nhận hàng)
### Chia sẻ theo publish/consume (đề xuất)
* Purchase Request **publish** các yêu cầu đã được phê duyệt (các field cần cho procurement)
* Procurement **consume** để tạo/điều phối công việc mua sắm
* Procurement **publish** trạng thái xử lý (read-only cho requester theo dõi)
* Purchase Request **consume** để hiển thị tiến độ cho người yêu cầu
Kết quả:
* ownership rõ, mỗi app tập trung đúng “phần việc”
* dữ liệu không bị sửa chéo
* UI của mỗi nhóm người dùng đơn giản hơn
## Anti-patterns cần tránh
* **Nhập lại dữ liệu** giữa các app thay vì kết nối qua publish/consume + connected app (kết nối ứng dụng) (dẫn đến lệch dữ liệu)
* **Two-way mặc định** cho mọi liên kết
* **Không có app nguồn**: nhiều app cùng sửa cùng record
* **Chia sẻ quá rộng**: publish “tất cả mọi thứ” thay vì publish đủ dùng
* **Không có policy**: ai cũng xem/sửa dữ liệu nhạy cảm
## Bước tiếp theo
* Ra quyết định controls: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
* Áp dụng trong delivery loop: [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)
* Cấu hình tính năng: [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
# Vận hành số
Source: https://learn.cleeksy.com/foundations/digital-operations
Hiểu vận hành số (Digital Operations) và cách áp dụng trong Cleeksy DOP.
Tài liệu này cung cấp mô hình tư duy tối thiểu để thiết kế và xây dựng ứng dụng trên Cleeksy theo định hướng **Digital Operations**.
Bắt đầu thực hành xây app đầu tiên: [App đầu tiên](/get-started/first-app)
## Mục tiêu
Sau khi đọc xong, có thể:
* Phân biệt **value stream**, **value slice**, và **work system**
* Hiểu “App trên Cleeksy” tương ứng với một **work system** (dữ liệu + quy trình + con người + UI + kiểm soát)
* Biết nguyên tắc kết nối nhiều app để vận hành đầu-cuối mà không rơi vào **mega-app**
* Xác định “bước tiếp theo” khi thiết kế một hệ thống vận hành số
## Khái niệm cốt lõi
### Value stream
**Value stream** là chuỗi công việc đầu-cuối tạo ra kết quả cho tổ chức (ví dụ: mua sắm nội bộ, onboarding nhân sự, xử lý sự cố).
### Value slice
**Value slice** là một phần nhỏ của value stream nhưng:
* có điểm bắt đầu/kết thúc rõ ràng,
* tạo ra kết quả có thể đo lường,
* có thể triển khai và cải tiến theo vòng lặp.
Theo SDD, một value slice khi triển khai có thể gồm **một hoặc nhiều app** (tuỳ mức độ tách ranh giới và ownership).
### Work system (hệ thống công việc)
Một **work system** là hệ thống vận hành thực tế gồm:
* **Dữ liệu** (các thực thể và trạng thái)
* **Quy trình** (các bước, điều kiện, phê duyệt)
* **Con người** (vai trò, trách nhiệm)
* **UI** (cách thao tác và theo dõi)
* **Kiểm soát** (chính sách, phân quyền, ràng buộc)
Trên Cleeksy, một **App** thường được thiết kế như một **work system** có thể triển khai độc lập.
## Mô hình “App như work system” trên Cleeksy
Một app tiêu chuẩn trên Cleeksy thường gồm:
* **Data**: Entities → Fields → Records
* **UI**: Views + Record layout
* **Process**: Process builder + Approvals + Automation (tuỳ nhu cầu)
* **People**: Roles & Permissions
* **Controls**: validation/protection/permission boundaries
* **Connect**: publish/consume, Data Connection (dựa trên connected app đã consume), hoặc tích hợp webhook/API
Xem tổng quan: [Tổng quan: Cleeksy DOP là gì?](/get-started/overview)
## Nguyên tắc thiết kế để tránh mega-app
### 1) Bắt đầu từ bài toán vận hành, không bắt đầu từ danh sách tính năng
* Xác định công việc cần chạy đầu-cuối (scenario), vai trò tham gia, và kết quả “xong việc” là gì.
* Chỉ cấu hình các thành phần cần thiết để scenario chạy được.
Gợi ý: [Cơ bản về Scenario](/foundations/scenario-basics)
### 2) Ranh giới app dựa trên ownership và thay đổi
* App nên có “chủ sở hữu” rõ ràng (đơn vị chịu trách nhiệm dữ liệu và quy trình).
* Khi có nhiều ownership hoặc nhịp thay đổi khác nhau, cân nhắc tách app và kết nối.
Gợi ý: [Ranh giới App](/foundations/app-boundaries)
### 3) Kết nối app bằng publish/consume trước
* Ưu tiên **publish/consume** để giảm phụ thuộc chặt và làm rõ dữ liệu “nguồn”.
* Two-way chỉ dùng khi quy tắc đồng bộ và ownership đã rõ.
Gợi ý: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing) và [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
## Bước tiếp theo (thực hành theo thứ tự)
Thực hành: [App đầu tiên](/get-started/first-app)
Bắt đầu với: [Chọn Value Slice theo SMALL](/foundations/value-slices-small) và [Ranh giới App](/foundations/app-boundaries)
Xem: [SDD là gì](/sdd/overview) và [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)
## Thảo luận & nhận hỗ trợ
* Cộng đồng builder: [Community](https://community.cleeksy.com)
# Vòng lặp cải tiến
Source: https://learn.cleeksy.com/foundations/improve-loop
Thiết lập vòng cải tiến tối thiểu để app tốt dần theo thời gian.
Vòng lặp cải tiến (Improve loop) giúp app **không dừng lại ở “xây xong”** mà tiếp tục tốt dần khi vận hành: ít lỗi hơn, nhanh hơn, phù hợp hơn với cách làm việc thực tế.
Improve loop **không phải** một hoạt động “toàn diện” hay nặng về tài liệu. Ở mức tối thiểu, chỉ cần: **đo — phát hiện — ưu tiên — chỉnh — xác nhận**.
***
## Khi nào cần Improve loop
* App đã được đưa vào dùng và bắt đầu phát sinh **trường hợp ngoại lệ** (exceptions)
* Thời gian xử lý (cycle time) hoặc tỉ lệ quá hạn tăng
* Người dùng phản hồi “khó dùng”, “thiếu bước”, “phải làm thủ công”
* Thay đổi chính sách/quy trình khiến workflow hiện tại không còn phù hợp
***
## Improve loop tối thiểu (khuyến nghị)
1. **Quan sát (Observe)**\
Thu tín hiệu từ dữ liệu vận hành và phản hồi người dùng.
2. **Xác định vấn đề (Diagnose)**\
Chốt vấn đề theo “triệu chứng → nguyên nhân → tác động”.
3. **Ưu tiên (Prioritize)**\
Chọn 1–3 cải tiến có thể làm ngay, tác động rõ, rủi ro thấp.
4. **Triển khai thay đổi (Change)**\
Thực hiện theo cách nhỏ và an toàn (increment).
5. **Xác nhận & đưa vào dùng (Verify & Adopt)**\
Kiểm tra lại chỉ số và hướng dẫn người dùng cách dùng mới.
> **SDD**: Improve loop thường tạo đầu vào cho **Outer loop** (ưu tiên backlog) và được thực hiện trong **Inner loop** (delivery cycle).
***
## Nên đo gì (tối thiểu)
### 1) Hiệu quả quy trình
* **Cycle time**: thời gian từ tạo → hoàn tất
* **Tỉ lệ quá hạn**: số record quá hạn / tổng record
* **Tắc nghẽn theo bước**: bước nào có nhiều record “đứng lại” nhất
### 2) Chất lượng & độ ổn định
* Tỉ lệ bị trả về / bị từ chối
* Số lần phải sửa lại dữ liệu (rework)
* Lỗi tích hợp (Webhook/API) theo tuần (nếu có)
### 3) Mức độ áp dụng (adoption)
* Số người dùng hoạt động (active users)
* Số record tạo/hoàn tất theo tuần
* Tỉ lệ xử lý trong hệ thống vs ngoài hệ thống (nếu quan sát được)
***
## Thu tín hiệu ở đâu trong Cleeksy DOP
* **Workflow & Status**: theo dõi tắc nghẽn, quá hạn, điểm nghẽn theo bước
* **Thông báo & giao việc**: số lượng task tồn, task quá hạn
* **Portal / API / Webhook**: tỉ lệ submit lỗi, lỗi xác thực, lỗi payload (nếu dùng)
* **Analytics Hub**: tạo report theo bước, theo thời gian, theo nhóm người dùng
***
## Checklist triển khai cải tiến (nhanh)
* [ ] Chọn 1 vấn đề ưu tiên có thể đo được
* [ ] Xác định thay đổi cần làm (workflow, view, field, rule, data source…)
* [ ] Kiểm thử tối thiểu với 3–5 record đại diện (happy path + 1–2 exceptions)
* [ ] Cập nhật hướng dẫn ngắn cho người dùng (1 trang hoặc 1 đoạn)
* [ ] Theo dõi lại chỉ số sau 1–2 tuần để xác nhận hiệu quả
# Giới thiệu
Source: https://learn.cleeksy.com/foundations/index
Tập hợp các “decision cards” giúp đưa ra quyết định thiết kế nhanh và nhất quán.
Các trang trong Foundations **không nhằm thay thế thực hành**. Chúng được thiết kế để dùng “đúng lúc” khi phạm vi bắt đầu lớn, khi ranh giới app chưa rõ, hoặc khi cần kết nối dữ liệu giữa nhiều app.
## Khi nào nên đọc Foundations?
* Cần chọn phạm vi triển khai đủ nhỏ để ship sớm (tránh mega-app)
* Cần viết scenario rõ ràng để chuyển thành cấu hình app
* Cần quyết định tách/ghép app và ranh giới ownership
* Cần quyết định cách chia sẻ dữ liệu (publish/consume, one-way/two-way)
* Cần quyết định đặt policy ở đâu (workflow vs validation vs roles)
* Cần thiết lập vòng lặp cải tiến tối thiểu
## Cách sử dụng (khuyến nghị)
Bắt đầu với: [Vận hành số](/foundations/digital-operations)
Bắt đầu với: [Quản lý công việc](/foundations/work-system)
Bắt đầu với: [Chọn Value slice theo SMALL](/foundations/value-slices-small)
Xem: [Cơ bản về Scenario](/foundations/scenario-basics)
Xem: [Ranh giới ứng dụng](/foundations/app-boundaries) và [Quản lý & chia sẻ dữ liệu)](/foundations/data-ownership-sharing)
Xem: [Kiểm soát trong hệ thống](/foundations/controls-in-system)
Xem: [Vòng lặp cải tiến](/foundations/improve-loop)
Foundations tập trung vào “cách ra quyết định”. Cách tổ chức planning + delivery theo vòng lặp được mô tả trong: [SDD là gì](/sdd/overview).
# Cơ bản về Scenario
Source: https://learn.cleeksy.com/foundations/scenario-basics
Cách viết user scenario đủ rõ để thiết kế và kiểm thử.
Trang này cung cấp chuẩn tối thiểu để viết **scenario** phục vụ thiết kế và triển khai hệ thống vận hành số. Scenario tốt giúp giảm hiểu nhầm, giảm scope creep và giúp cấu hình app nhất quán.
Scenario là đầu vào quan trọng cho **Design** trong vòng lặp Scenario-Driven (SDD) và cũng là nền tảng để chọn phạm vi theo SMALL.
## Mục tiêu
* Chuẩn hoá định dạng scenario để dùng chung giữa nghiệp vụ và người cấu hình app
* Xác định “đủ rõ để build” (quality bar) trước khi bắt đầu cấu hình
* Tránh các lỗi phổ biến: mô tả mơ hồ, trộn giải pháp vào yêu cầu, scope phình to
Liên quan:
* [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
* [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)
## Scenario là gì?
Một **scenario** mô tả một luồng công việc cụ thể theo góc nhìn người dùng (actor), từ lúc kích hoạt (trigger) đến kết quả (outcome). Scenario tập trung vào:
* **Ai** thực hiện (actor/role)
* **Vì sao** bắt đầu (trigger)
* **Các bước chính** cần xảy ra (main steps)
* **Ngoại lệ quan trọng** (exceptions)
* **Kết quả mong muốn** (outcome + success criteria)
Scenario không phải tài liệu “kể chuyện”. Scenario là mô tả có cấu trúc để chuyển thành dữ liệu, UI và workflow.
## Định dạng scenario tối thiểu
Khuyến nghị dùng format sau cho mỗi scenario:
### 1) Tên scenario
Ngắn gọn và hành động rõ: “Tạo yêu cầu mua”, “Phê duyệt yêu cầu mua”, “Procurement cập nhật trạng thái mua sắm”.
### 2) Actor và mục tiêu
* **Actor**: vai trò thực hiện (Requester/Approver/Procurement…)
* **Mục tiêu**: kết quả mà actor cần đạt
### 3) Trigger và điều kiện trước
* **Trigger**: sự kiện bắt đầu (nhân viên cần mua hàng)
* **Preconditions**: điều kiện cần có (đã đăng nhập, có quyền tạo yêu cầu…)
### 4) Luồng chính (Main flow)
Danh sách bước theo thứ tự, mỗi bước nên có:
* hành động của actor
* hệ thống phản hồi/ghi nhận gì
* trạng thái thay đổi (nếu có)
### 5) Ngoại lệ quan trọng (Exceptions)
Chỉ giữ 1–3 ngoại lệ “đáng tiền” cho vòng đầu, ví dụ:
* thiếu thông tin bắt buộc
* bị từ chối phê duyệt
* vượt ngưỡng chi phí cần escalations (nếu có)
### 6) Outcome và tiêu chí thành công
* **Outcome**: trạng thái kết thúc (Approved/Rejected/Closed…)
* **Success criteria**: cách biết scenario hoàn thành (ví dụ: trạng thái cập nhật, người liên quan được thông báo, log/audit có đủ)
## Ví dụ scenario (Purchase Request)
### Scenario: Gửi Purchase Request để xin phê duyệt
* **Actor**: Requester
* **Mục tiêu**: tạo yêu cầu mua và gửi để phê duyệt
* **Trigger**: phát sinh nhu cầu mua hàng
* **Preconditions**: có quyền tạo Purchase Request
**Main flow**
1. Requester tạo bản ghi Purchase Request (nhập tiêu đề, mô tả, loại mua, chi phí dự kiến)
2. Hệ thống lưu bản ghi ở trạng thái Draft
3. Requester gửi yêu cầu → chuyển trạng thái Pending Approval
4. Hệ thống thông báo cho Approver
**Exceptions**
* Nếu thiếu thông tin bắt buộc → hệ thống chặn gửi và hiển thị lỗi
* Nếu Requester không có quyền gửi → hệ thống ẩn hành động hoặc chặn thao tác
**Outcome**
* Yêu cầu ở trạng thái Pending Approval và Approver nhận được thông báo
Ví dụ trên cố ý giữ “tối thiểu chạy được”. Các biến thể ít gặp nên đưa vào backlog thay vì đưa vào vòng đầu.
## Quality bar: “Đủ rõ để build”
Một scenario được coi là **ready** khi:
* Actor và trigger rõ ràng (không mơ hồ)
* Có danh sách bước chính có thứ tự
* Có outcome cụ thể và có thể kiểm chứng
* Vai trò liên quan đã được nêu (ít nhất vai trò chính)
* Có tối đa 1–3 ngoại lệ quan trọng cho vòng đầu
* Có dữ liệu tối thiểu cần thu thập (các trường bắt buộc đã biết)
Nếu outcome không đo/kiểm chứng được (“xử lý nhanh”, “trơn tru”), scenario chưa sẵn sàng. Cần chuyển thành tiêu chí cụ thể (thời gian, trạng thái, thông báo, SLA…).
## Từ scenario sang cấu hình Cleeksy (mapping tối thiểu)
Scenario tốt giúp xác định nhanh các cấu phần:
* **Danh từ nghiệp vụ** → Entities/Fields (Purchase Request, Supplier, Item…)
* **Bước công việc / trạng thái** → Workflow states & transitions
* **Actor** → Roles/Permissions
* **Điều kiện / policy** → validation/protection/role gates
* **Kết quả cần theo dõi** → dashboard/metrics (khi cần)
Tham khảo:
* [Cơ bản về App](/build-apps/app-basics)
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
* [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
## Lỗi phổ biến và cách tránh
### 1) Trộn giải pháp vào yêu cầu
* Sai: “Cần có Kanban và dashboard”
* Đúng: “Cần theo dõi trạng thái theo cột và có tổng số yêu cầu theo trạng thái”
### 2) Mô tả chung chung
* Sai: “Procurement xử lý mua hàng”
* Đúng: “Procurement cập nhật trạng thái In Procurement → Completed và ghi số PO (nếu có)”
### 3) Quá nhiều ngoại lệ ở vòng đầu
* Dấu hiệu: workflow có quá nhiều nhánh và điều kiện ngay từ đầu
* Cách xử lý: đưa ngoại lệ ít gặp vào backlog, chỉ giữ ngoại lệ quan trọng
### 4) Không xác định “xong việc” là gì
* Dấu hiệu: không có trạng thái kết thúc hoặc không có tiêu chí kiểm chứng
* Cách xử lý: thêm outcome + success criteria
## Bước tiếp theo
* Chọn phạm vi theo SMALL: [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
* Quyết định ranh giới app: [Ranh giới App](/foundations/app-boundaries)
* Tổ chức delivery theo SDD: [SDD là gì](/sdd/overview)
# Value slice theo SMALL
Source: https://learn.cleeksy.com/foundations/value-slices-small
Quy tắc chọn value slice nhỏ, rõ ranh giới và đo được.
Trang này cung cấp hướng dẫn thực dụng để chọn **value slice** theo tiêu chí **SMALL**. Mục tiêu là giúp thiết kế phạm vi triển khai đủ nhỏ để hoàn thành nhanh, nhưng vẫn đủ “đầu-cuối” để tạo ra kết quả đo lường được.
## Value slice là gì?
**Value slice** là một phần nhỏ của một **value stream** (công việc đầu-cuối), có:
* điểm bắt đầu và kết thúc rõ ràng,
* kết quả đo lường được,
* có thể triển khai theo vòng lặp cải tiến.
Theo Scenario-Driven (SDD), khi triển khai thực tế, một value slice có thể bao gồm **một hoặc nhiều app** tuỳ theo ranh giới ownership và cách tổ chức dữ liệu/quy trình.
Tham khảo: [Vận hành số (Digital Operations)](/foundations/digital-operations)
## Vì sao cần SMALL?
Trong no-code, rủi ro phổ biến là tạo **mega-app**: một app cố gắng bao phủ toàn bộ quy trình và mọi biến thể. Kết quả thường gặp:
* cấu hình phức tạp, khó thay đổi,
* quy trình chồng chéo, không rõ ownership,
* khó đào tạo và khó mở rộng,
* “chạy được” nhưng không đo được hiệu quả.
SMALL là bộ tiêu chí để giảm rủi ro đó và tăng tốc “đưa vào vận hành”.
## Tiêu chí SMALL
### S — Small scope (Phạm vi nhỏ)
* Phạm vi đủ nhỏ để có thể triển khai trong thời gian ngắn
* Tránh bao phủ quá nhiều bộ phận và quá nhiều ngoại lệ ngay từ đầu
### M — Measurable outcome (Kết quả đo được)
* Có chỉ số rõ ràng (thời gian xử lý, % đúng hạn, số lượng tồn, chi phí…)
* Có “định nghĩa xong việc” (done) theo kết quả, không chỉ theo hoạt động
### A — Actionable workflow (Luồng hành động rõ ràng)
* Có các bước/trạng thái phản ánh công việc thực tế
* Mỗi bước gắn với một vai trò chịu trách nhiệm
### L — Limited roles & handoffs (Ít vai trò & bàn giao)
* Số vai trò tối thiểu để chạy được end-to-end
* Chỉ giữ các handoff cần thiết nhất (để giảm độ phức tạp)
### L — Launchable & learnable (Triển khai được và học được)
* Có thể “đưa vào dùng” với hướng dẫn ngắn
* Có cơ chế thu phản hồi và cải tiến (Inner loop/Outer loop)
## Cách chọn một value slice theo SMALL
Ví dụ: giảm thời gian phê duyệt, giảm tồn đọng, tăng tỷ lệ xử lý đúng hạn.
Mỗi scenario cần có actor, trigger, các bước chính và outcome.
Tham khảo: [Cơ bản về Scenario](/foundations/scenario-basics)
Loại bỏ các biến thể ít gặp ở vòng đầu. Chỉ giữ đường chạy chính (happy path) và 1–2 ngoại lệ quan trọng.
Nếu ownership không rõ hoặc nhịp thay đổi khác nhau, cân nhắc tách app và kết nối dữ liệu.
Tham khảo: [Ranh giới App](/foundations/app-boundaries), [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
Xác định 2–3 KPI cho value slice và cách thu phản hồi sau khi vận hành.
Tham khảo: [Vòng lặp cải tiến (Improve loop)](/foundations/improve-loop)
## Ví dụ nhanh (Purchase Request)
Trong ví dụ **Purchase Request Handling**, một value slice có thể được xác định theo cách sau:
* **Outcome đo được:** % yêu cầu được xử lý đúng hạn, thời gian phê duyệt trung bình
* **Luồng tối thiểu:** tạo yêu cầu → phê duyệt → cập nhật xử lý → đóng
* **Vai trò tối thiểu:** Requester / Approver / Procurement
Thực hành xây app đầu tiên theo ví dụ này: [App đầu tiên](/get-started/first-app)
## Dấu hiệu phạm vi đang “không còn SMALL”
* Có quá nhiều trạng thái và nhánh (workflow “mê cung”)
* Có quá nhiều vai trò tham gia ngay từ vòng đầu
* Phải xử lý quá nhiều ngoại lệ và policy trước khi chạy thử
* Không xác định được 2–3 chỉ số để đo hiệu quả
* Cần tích hợp nhiều hệ thống ngay lập tức
Khi gặp các dấu hiệu này, nên:
* chia nhỏ scenario,
* tách theo ranh giới ownership,
* đưa phần phức tạp sang vòng lặp sau.
## Liên kết liên quan
* [Tổng quan: Cleeksy DOP là gì?](/get-started/overview)
* [Cơ bản về Scenario](/foundations/scenario-basics)
* [Ranh giới App](/foundations/app-boundaries)
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
* [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
* [SDD là gì](/sdd/overview)
# Hệ thống công việc
Source: https://learn.cleeksy.com/foundations/work-system
Nơi công việc được tổ chức thực hiện một cách liền mạch.
Hệ thống công việc (Work System) là **đơn vị vận hành cụ thể** của một phần chuỗi giá trị (value stream), nơi dòng chảy công việc thực sự diễn ra mỗi ngày.
Một Work System được cấu thành từ:
* **Con người (People)** tham gia trực tiếp vào công việc
* **Quy trình (Processes)**, các bước xử lý và quy tắc nghiệp vụ
* **Dữ liệu (Data / Information)** và các đối tượng kinh doanh
* **Công nghệ & hệ thống (Technology / Systems)** dùng để thực thi công việc
***
## Ví dụ theo chuỗi giá trị Order-to-Cash
Trong chuỗi giá trị **Order-to-Cash**, có thể tồn tại nhiều Work Systems:
* **Order Intake Work System** – tiếp nhận và ghi nhận đơn hàng
* **Order Fulfilment Work System** – chuẩn bị và giao hàng
* **Billing & Collections Work System** – lập hoá đơn và thu tiền
Mỗi Work System cần trả lời rõ các câu hỏi:
* **Ai đang tham gia?** (các vai trò cụ thể)
* **Làm gì?** (các bước xử lý, quy tắc, ngoại lệ)
* **Xử lý dữ liệu nào?** (đơn hàng, khách hàng, hoá đơn, sự kiện…)
* **Sử dụng hệ thống nào?** (DOP, ERP, CRM, tích hợp, bot, …)
***
## Hệ thống công việc tích hợp (Integrated Work System))
Integrated Work System là **tập hợp các Work Systems** khi chúng chia sẻ dữ liệu, phối hợp vai trò và tích hợp theo value stream để tạo thành một hệ thống vận hành số **đầu–cuối**, **liền mạch** và **có thể đo lường**.
***
## Liên hệ với Cleeksy DOP
Trong Cleeksy DOP, một ứng dụng (app) thường được thiết kế để hiện thực hoá **một Work System** (hoặc một phần rõ ràng của Work System). Khi nhiều app được kết nối để chạy đầu–cuối theo value stream, chúng tạo nên một **Integrated Work System**.
* Khi cần đặt ranh giới triển khai: xem [Ranh giới ứng dụng](/foundations/app-boundaries)
* Khi cần xác định nguồn dữ liệu chuẩn và cơ chế chia sẻ: xem [Ownership & chia sẻ dữ liệu](/foundations/data-ownership-sharing)
* Khi lập kế hoạch theo kịch bản: xem [Outer loop: scenario backlog (lập kế hoạch theo kịch bản)](/sdd/outer-loop-scenario-backlog)
# App đầu tiên
Source: https://learn.cleeksy.com/get-started/first-app
Thực hành xây app đầu tiên theo từng bước.
Bài thực hành này hướng dẫn xây **app đầu tiên** có thể chạy được đầu-cuối theo tư duy Cleeksy: bắt đầu từ **một bài toán nghiệp vụ cụ thể**, sau đó cấu hình **App → Entity → Fields → Form → View → Workflow → Roles**.
Tài liệu ví dụ “Purchase Request Handling” mô tả yêu cầu nghiệp vụ, luồng xử lý và các field đề xuất.
## Mục tiêu học tập
Hoàn thành bài thực hành này sẽ có một app với:
* 1 entity **Purchase Request** và các field chính
* UI tối thiểu: **Grid view** + **Record layout**
* Workflow phản ánh luồng: tạo yêu cầu → phê duyệt → xử lý mua sắm → hoàn tất/đóng
* Phân quyền theo vai trò và kiểm thử end-to-end
Theo SDD, một **value slice** khi triển khai có thể gồm **một hoặc nhiều app**. Quickstart này tập trung vào việc hoàn thành **một app đầu tiên** trong phạm vi bài toán Purchase Request.
## Kịch bản nghiệp vụ (Purchase Request)
**Mục tiêu nghiệp vụ:** Cho phép nhân viên gửi yêu cầu mua sắm (laptop, phụ kiện, phần mềm, vật tư…), đi qua phê duyệt của Trưởng nhóm/Trưởng phòng trước khi chuyển sang bộ phận Procurement xử lý. Trạng thái cần được cập nhật và thông báo theo từng bước.
**Luồng chính (tối thiểu):**
1. Nhân viên tạo Purchase Request
2. Trưởng nhóm/Trưởng phòng review và Approve/Reject
3. Nếu Approve → chuyển sang Procurement xử lý
4. Nếu Reject → đóng request
5. Người yêu cầu theo dõi trạng thái
6. Procurement hoàn tất → cập nhật trạng thái nhận hàng
## Điều kiện tiên quyết
* Có quyền tạo App trong Space
* Có thể tạo và gán vai trò (Requester/Approver/Procurement)
***
## Thiết kế dữ liệu tối thiểu
### Entity: Purchase Request
Các field đề xuất (có thể điều chỉnh theo tổ chức):
| Field (EN) | Nhãn (VI) | Kiểu dữ liệu | Bắt buộc | Ghi chú |
| --------------- | --------------- | ----------------- | -------- | ------------------------------------------------------------------------------ |
| Request No | Số yêu cầu | Auto number | Tự sinh | Hệ thống sinh |
| Title | Tiêu đề | Text (short) | Có | Mô tả ngắn |
| Requester | Người yêu cầu | People/User | Có | Người gửi |
| Department | Phòng ban | Choice/Text | Có | Phục vụ routing |
| Category | Loại mua | Choice | Có | Laptop, Software… |
| Description | Mô tả chi tiết | Long text | Có | Lý do |
| Estimated Cost | Chi phí dự kiến | Number/Currency | Không | |
| Status | Trạng thái | Choice | Có | Draft, Pending Approval, Approved, Rejected, In Procurement, Completed, Closed |
| Approver | Người phê duyệt | People/User | Hệ thống | Trưởng nhóm/phòng |
| Procurement PIC | Người xử lý mua | People/User | Hệ thống | |
| Created on | Ngày tạo | DateTime (System) | Tự sinh | |
***
## Các bước thực hiện
Tạo app mới: Purchase Request Handling.
Mục tiêu: tạo “work system container” để cấu hình dữ liệu + UI + workflow + vai trò.
Tạo entity: Purchase Request, sau đó thêm các field theo bảng “Thiết kế dữ liệu tối thiểu”.
✅ Kết quả: có thể tạo record “Purchase Request” với thông tin và trạng thái ban đầu.
Xem thêm: [Thực thể dữ liệu (Entity)](/build-apps/data-modeling/entities) và [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types).
Tạo **Grid view** cho entity Purchase Request.
Cột gợi ý:
* Request No, Title, Requester, Department, Category, Estimated Cost, Status, Created on
Cấu hình tối thiểu:
* Sort theo Created on (mới nhất trước)
* Filter theo Status (tuỳ nhóm sử dụng)
Xem chi tiết: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view).
Thiết kế **Record layout** theo nhóm thông tin:
* Thông tin yêu cầu (Request No, Title, Description, Category, Estimated Cost)
* Thông tin tổ chức (Requester, Department, Created on)
* Thông tin xử lý (Status, Approver, Procurement PIC)
Mục tiêu: giảm lỗi nhập liệu, ưu tiên các trường quan trọng ở phần đầu.
Xem chi tiết: [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout).
Thiết kế workflow theo các trạng thái đề xuất:
* Draft → Pending Approval → Approved → In Procurement → Completed → Closed
* Nhánh từ chối: Pending Approval → Rejected → Closed
Nguyên tắc:
* Mỗi chuyển trạng thái gắn với một hành động rõ ràng và một vai trò chịu trách nhiệm.
* Trạng thái phải thể hiện vị trí công việc trong luồng.
Xem chi tiết: [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder) và [Phê duyệt (Approvals)](/build-apps/workflows/approvals).
Tối thiểu 3 vai trò:
* Requester: tạo/sửa khi Draft, gửi duyệt (Pending Approval), theo dõi trạng thái
* Approver: xem và Approve/Reject khi Pending Approval
* Procurement: cập nhật trạng thái In Procurement → Completed
✅ Kết quả: đúng người, đúng bước, đúng quyền.
Xem tổng quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
Và xử lý lỗi quyền: [Quyền & truy cập (Permissions & access)](/troubleshooting/permissions-access).
Thực hiện kiểm thử theo 3 vai trò:
1. Requester tạo record ở Draft
2. Requester chuyển sang Pending Approval
3. Approver Approve hoặc Reject
4. Nếu Approved: Procurement chuyển sang In Procurement → Completed
5. Đóng vòng: Closed (khi đã hoàn tất hoặc bị từ chối)
Khi phát hiện vấn đề:
* Không thấy dữ liệu/không thao tác được → kiểm tra Permissions
* Không chuyển được trạng thái → kiểm tra workflow/điều kiện
* Form khó sử dụng → chỉnh record layout
Xem: [quy trình & tự động hoá (Workflows & automation)](/troubleshooting/workflows-automation) và [giao diện (Views & UI)](/troubleshooting/views-ui).
***
## Phạm vi của quickstart này
Quickstart này chỉ bao gồm phần tối thiểu để app “chạy được”:
* Grid view cơ bản, record layout cơ bản, workflow cơ bản, phân quyền cơ bản.
Các nội dung nâng cao (Kanban, dashboard, automation nâng cao, publish/consume, API/webhook, Analytics Hub) sẽ được giới thiệu ở các trang tính năng tương ứng.
## Bước tiếp theo
* Quyết định “tách app hay giữ một app”: [Ranh giới App](/foundations/app-boundaries)
* Kết nối app bằng publish/consume: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
* Scenario-Driven (SDD) —: [SDD là gì](/sdd/overview)
* Thảo luận: [community.cleeksy.com](https:\[Community]\(//community\).cleeksy.com)
# Thuật ngữ
Source: https://learn.cleeksy.com/get-started/glossary
Tra cứu thuật ngữ (glossary) quan trọng trong Cleeksy DOP.
Glossary này thống nhất thuật ngữ sử dụng trong Learn (public). Các định nghĩa được viết ngắn gọn, ưu tiên khả năng áp dụng khi thiết kế và xây dựng hệ thống vận hành số.
## 1) Khái niệm nền tảng của Digital Operations
### Digital Operations
**Digital Operations** là việc thiết kế có chủ đích, số hoá và cải tiến liên tục công việc hằng ngày để vận hành các **value stream**—nơi con người, quy trình, dữ liệu và công nghệ kết hợp dưới lớp kiểm soát gồm **vai trò, chính sách và chỉ số**.
Tham khảo: [Vận hành số (Digital Operations)](/foundations/digital-operations)
### Value stream
Dòng chảy công việc đầu-cuối từ *trigger → outcome* tạo ra giá trị cho tổ chức (ví dụ: Order-to-Cash, Hire-to-Retire, Incident-to-Resolution).
### Value slice
Một phần nhỏ của value stream, có điểm bắt đầu/kết thúc rõ ràng, tạo ra kết quả đo lường được và có thể triển khai theo vòng lặp.
Lưu ý: theo Scenario-Driven (SDD), một value slice khi triển khai có thể gồm **một hoặc nhiều app**.
### Work system (hệ thống công việc)
Tổ hợp được thiết kế có chủ đích gồm **People + Process + Data + Technology** để chạy lặp lại một phần của value stream và cải tiến theo thời gian.
Trên Cleeksy, một **App** thường được thiết kế như một work system có thể triển khai độc lập.
Tham khảo: [Tổng quan: Cleeksy DOP là gì?](/get-started/overview)
### Roles (vai trò)
Vai trò xác định **ai làm gì**, với quyền hạn và trách nhiệm rõ ràng trong work system và qua các handoff.
Tham khảo: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
### Policies (chính sách)
Các quy tắc kiểm soát cách công việc được thực hiện: cách ra quyết định, xử lý ngoại lệ, ràng buộc rủi ro/tuân thủ.
Gợi ý: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
### Metrics (chỉ số)
Chỉ số dùng để biết hệ thống có “chạy tốt” không (hiệu suất, chất lượng, chi phí, rủi ro, trải nghiệm). Metrics giúp tránh tối ưu “hoạt động” thay vì tối ưu “giá trị”.
## 2) Kiến trúc vận hành số (Digital Operations Architecture)
### DOA (Digital Operations Architecture)
**DOA** là bản thiết kế kiến trúc hệ thống để tổ chức hệ thống, dữ liệu, quy trình và con người nhằm thực thi mô hình vận hành số và tạo ra giá trị.
**5 lớp DOA (tóm tắt):**
1. **Data & Connectivity**: mô hình dữ liệu, kiểm soát truy cập, tích hợp hệ thống
2. **Operational Apps**: app mô-đun, workflow engine, automation
3. **Event Orchestration**: nối workflow giữa bộ phận/value stream theo sự kiện
4. **Intelligence**: dashboard KPI, phân tích, tối ưu
5. **Autonomy**: tự học/tự phản hồi (AI/ML, feedback loops)
Learn (public) tập trung chủ yếu vào Layers 1–4 dưới góc độ “xây và vận hành app”. Các nội dung nâng cao hơn có thể được thảo luận trong cộng đồng.
## 3) Khái niệm về nền tảng và giải pháp
### DOP (Digital Operations Platform)
Nền tảng công nghệ để triển khai và quản lý digital operations: kết nối app, workflow, data sources và người dùng; hỗ trợ xây dựng mô-đun và giám sát theo thời gian thực.
### Digital Operations Solution
Giải pháp vận hành số là triển khai thực tế (cấu hình + thành phần tái sử dụng + hướng dẫn) để số hoá một chức năng/capability cụ thể (ví dụ: procurement, service delivery, onboarding).
## 4) Khái niệm về dữ liệu (Data Capability)
Các loại dữ liệu thường gặp trong vận hành số:
* **Master data**: dữ liệu “nguồn” ổn định (customer, supplier, employee, product…)
* **Transactional data**: sự kiện nghiệp vụ theo thời gian (orders, payments, shipments…)
* **Operational data**: dữ liệu “đang chạy” phục vụ vận hành tức thời (inventory, open tickets…)
* **Analytical data**: dữ liệu cho báo cáo và phân tích (KPI dashboards, trends…)
* **Reference data**: danh mục chuẩn (country codes, currency codes, tax rates…)
* **Metadata**: dữ liệu mô tả dữ liệu (schema, owner, timestamps…)
* **Streaming/Event data**: luồng sự kiện theo thời gian thực (IoT, logs, status updates…)
* **Unstructured/Semi-structured**: PDF, hình ảnh, JSON/XML payloads
* **Derived/Predictive**: dữ liệu suy diễn/dự báo (margins, forecasts, anomaly alerts)
Trong Cleeksy, các loại dữ liệu này thường được mô hình hoá qua **Entity/Field/Record**, và/hoặc kết nối từ hệ thống khác qua **Publish/Consume, Webhook, API**.
## 5) Thuật ngữ nền tảng trong Cleeksy DOP
### Space
Không gian làm việc nơi các app được tạo và vận hành (thường là ranh giới quản trị người dùng và quyền).
### App
Đơn vị triển khai chính trên Cleeksy. Một app là work system có thể chạy độc lập (data + UI + workflow + roles + controls).
Bắt đầu: [Cơ bản về App](/build-apps/app-basics)
### Entity
Thực thể dữ liệu (tương đương “bảng”). Entity chứa fields và records.
Hướng dẫn: [Thực thể dữ liệu (Entity)](/build-apps/data-modeling/entities)
### Field
Thuộc tính dữ liệu của entity (tương đương “cột”). Field có kiểu dữ liệu và hành vi (lọc, tính toán, liên kết…).
Hướng dẫn: [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
### Record
Bản ghi dữ liệu (tương đương “dòng”). Record là đối tượng được tạo/cập nhật trong quá trình vận hành.
Hướng dẫn: [Bản ghi (Record)](/build-apps/data-modeling/records)
## 6) Thuật ngữ UI (Views & Layout)
### View
Cách hiển thị và thao tác dữ liệu theo nhu cầu công việc (grid, kanban, dashboard…).
Tổng quan: [Tổng quan giao diện](/build-apps/ui-views/views-overview)
### Grid view
View dạng bảng, phù hợp nhập liệu, lọc, sắp xếp, theo dõi danh sách.
Hướng dẫn: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view)
### Kanban view
View theo cột/trạng thái (lanes), phù hợp theo dõi luồng theo stage/status.
Hướng dẫn: [Dạng thẻ (Kanban view)](/build-apps/ui-views/kanban-view)
### Dashboard view
View tổng quan để theo dõi chỉ số và trạng thái vận hành.
Hướng dẫn: [Bảng điều khiển (Dashboard view)](/build-apps/ui-views/dashboard-view)
### Record layout
Màn hình chi tiết/form của record, nơi bố trí trường và nhóm thông tin để thao tác nhanh và giảm lỗi nhập.
Hướng dẫn: [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
## 7) Thuật ngữ quy trình (Workflows & Automation)
### Workflow / Process
Chuỗi trạng thái/bước và quy tắc chuyển trạng thái để “công việc chạy được”.
Hướng dẫn: [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
### Approval
Bước phê duyệt trong workflow, thường gắn với vai trò Approver và kết quả Approve/Reject.
Hướng dẫn: [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
### Automation
Tự động hoá hành động dựa trên trigger/condition (ví dụ: cập nhật trạng thái, gửi thông báo…).
Hướng dẫn: [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules)
## 8) Thuật ngữ kiểm soát truy cập
### Role
Vai trò đại diện nhóm người dùng tham gia quy trình (Requester, Approver, Procurement…).
Tham khảo: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
### Permission
Quyền truy cập và thao tác (xem, tạo, sửa, duyệt…) theo vai trò và phạm vi.
Xử lý lỗi thường gặp: [Quyền & truy cập (Permissions & access)](/troubleshooting/permissions-access)
## 9) Thuật ngữ kết nối dữ liệu & tích hợp
### Publish / Consume
Cơ chế chia sẻ dữ liệu giữa các app theo hướng “app nguồn publish, app khác consume”, ưu tiên làm rõ ownership và giảm coupling.
Hướng dẫn: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
### Data Connection (1-way / 2-way)
Data Connection là Field dùng để liên kết record (link databases).
* **Trong cùng App**: liên kết trực tiếp giữa các Entity.
* **Giữa các App**: publish/consume là bước bắt buộc để tạo **connected app (kết nối ứng dụng)** (App nguồn publish, App tiêu thụ consume). Connected app này được dùng cho Data Connection, Lookup và Rollup.
### Lookup / Rollup / Formula
* **Lookup:** lấy giá trị từ record liên kết
* **Rollup:** tổng hợp giá trị từ record liên kết
* **Formula:** tính toán giá trị theo biểu thức
Hướng dẫn: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup), [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup), [Công thức (Formula)](/build-apps/data-modeling/formula)
### Webhook / API
* **Webhook:** nhận dữ liệu từ hệ thống ngoài theo sự kiện
* **API:** xuất/nhận dữ liệu theo giao diện lập trình
Hướng dẫn: [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal), [API portal (cổng API)](/build-apps/integrations/api-portal)
## 10) Thuật ngữ Scenario-Driven
### Scenario
Mô tả một luồng công việc cụ thể: actor, trigger, steps, exceptions, outcome.
Hướng dẫn: [Cơ bản về Scenario](/foundations/scenario-basics)
### Outer loop (vòng lặp ngoài) / Inner loop (vòng lặp trong)
* **Outer loop:** quản lý backlog theo scenario/value slice và ưu tiên theo kết quả
* **Inner loop:** Define → Design → Build → Test → Adopt
Tổng quan: [SDD là gì](/sdd/overview), [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)
## Mapping nhanh với no-code phổ biến
| Khái niệm | Cleeksy | No-code phổ biến (tham khảo) |
| ----------------- | -------------------------------- | ---------------------------- |
| Bảng dữ liệu | Entity | Table |
| Dòng dữ liệu | Record | Row/Record |
| Cột dữ liệu | Field | Column/Field |
| Màn hình làm việc | View | View |
| Form/chi tiết | Record layout | Form/Detail page |
| Quy trình | Workflow | Workflow/Process |
| Phân quyền | Roles/Permissions | Roles/ACL |
| Kết nối dữ liệu | Publish/Consume, Data Connection | Linked records/Shared data |
## Thảo luận & nhận hỗ trợ
* Cộng đồng builder: [community.cleeksy.com](https://community.cleeksy.com)
### Auto number
Field tự sinh mã tham chiếu cho record (ví dụ PR-000123) để dễ tìm kiếm và audit.
### Sub-dataset (child table)
Field dạng bảng con trong Entity để lưu dữ liệu phân cấp (một record cha có nhiều dòng con).
### Publish/Consume
Cơ chế chia sẻ dữ liệu giữa các app trong Cleeksy DOP. App “provider” chọn dữ liệu cho phép chia sẻ (publish). App “consumer” chọn dữ liệu được chia sẻ để sử dụng (consume) trong Connected app.
Publish/consume giúp kiểm soát:
* phạm vi dữ liệu được chia sẻ
* field được phép chia sẻ
* quyền truy cập theo vai trò/nhóm
Sau khi đã kết nối, các field như Data Connection/Lookup/Rollup có thể dùng dữ liệu theo quyền cho phép.
### Data source (cổng dữ liệu)
Kênh/điểm kết nối để app **nhận dữ liệu vào** hoặc **cung cấp dữ liệu ra**. Data source có nhiều loại: Request portal, Public portal, Connected app, Webhook, API.
Data source không phải bảng dữ liệu mới; dữ liệu vận hành vẫn nằm trong Entity của app.
### Connected app (kết nối ứng dụng)
Một loại Data source để kết nối giữa các app trong Cleeksy DOP. Dùng khi cần:
* submit/bàn giao dữ liệu sang app khác
* và/hoặc pull/đọc dữ liệu từ app khác (tuỳ cấu hình cho phép)
Connected app thường đi cùng cơ chế publish/consume để kiểm soát quyền chia sẻ.
# Cleeksy DOP
Source: https://learn.cleeksy.com/get-started/overview
Nắm bức tranh tổng quan về Cleeksy DOP.
Cleeksy DOP là nền tảng **no-code** hỗ trợ xây dựng và cải tiến **ứng dụng nghiệp vụ** để vận hành công việc hằng ngày.
Mục tiêu của Cleeksy không phải “xây app cho có”. Mục tiêu là **Digital Operations (Vận hành số)**: tạo ra kết quả **đo lường được** bằng cách chạy công việc đầu-cuối (**value stream**) thông qua các **work system** có thể triển khai và kết nối với nhau.
Để bắt đầu xây ngay, xem: [App đầu tiên](/get-started/first-app)
## Ý tưởng cốt lõi
* Tổ chức vận hành các **value stream** (công việc đầu-cuối tạo ra giá trị/kết quả).
* Value stream được triển khai theo từng **value slice** (một “lát giá trị” nhỏ nhưng có ý nghĩa và đo được).
* Một **App** trên Cleeksy là một **work system** có thể triển khai: **Dữ liệu + Quy trình + Con người (vai trò) + UI + Cơ chế kiểm soát**.
* Nhiều app có thể kết nối thành một **hệ thống vận hành số tích hợp** thông qua **publish/consume** và tích hợp với hệ thống bên ngoài.
Bản tóm tắt 3–5 phút: [Vận hành số (Digital Operations)](/foundations/digital-operations).
## Có thể xây dựng gì trên Cleeksy?
Một app trên Cleeksy có thể chạy độc lập (standalone) và đầy đủ:
* **Mô hình dữ liệu** (entities, fields, records)
* **UI** (views và record layouts)
* **Quy trình** (workflows, approvals, automation)
* **Con người** (roles và phân quyền truy cập)
* **Kiểm soát** (validation, permission, protection rules)
* **Dữ liệu vào/ra** (internal/public portals, webhook/API)
* **Kết nối** (publish dữ liệu để app khác consume)
## Các khối xây dựng (và chúng liên kết với nhau thế nào)
| Khía cạnh của work system | Tính năng trong Cleeksy DOP | Mục đích |
| ------------------------- | ----------------------------------------------------- | ------------------------------------------------------------- |
| Dữ liệu | **Entities, Fields, Records** | Lưu trữ “sự thật” và trạng thái vận hành |
| UI | **Views, Record Layouts** | Hỗ trợ thao tác nhanh trong công việc hằng ngày |
| Quy trình | **Process Builder, Approvals** | Biến quy trình thành “đường chạy” từ bắt đầu đến hoàn tất |
| Con người | **Roles & Permissions** | Làm rõ trách nhiệm và quyền truy cập |
| Kiểm soát | **Validations / Protection Rules** | Nhúng chính sách vào hệ thống (không chỉ nằm trong email/PDF) |
| Kết nối app | **Publish & Consume, Data Connections (1-way/2-way)** | Kết nối các value slice giữa nhiều app |
| Tích hợp bên ngoài | **Public Portal, Webhook, API** | Kết nối hệ thống khác, tự động hoá dữ liệu vào/ra |
| Đo lường & cải tiến | **Analytics Hub (tuỳ chọn)** | Theo dõi kết quả và tối ưu value slice |
## App kết nối với nhau như thế nào (để tránh “mega-app”)
Thông thường có 2 cách kết nối chính:
1. **Publish & Consume (khuyến nghị dùng trước)**
* Một app **publish** dữ liệu để app khác đọc/sử dụng.
* App còn lại **consume** dữ liệu thông qua các connection fields.
* Cách này giúp rõ **ownership** và hạn chế phụ thuộc chặt (tight coupling).
2. **Kết nối hai chiều (two-way) — dùng có chủ đích**
* Chỉ dùng khi ownership và quy tắc đồng bộ đã rõ ràng.
* Nếu lạm dụng, two-way dễ tạo ra phụ thuộc phức tạp.
Một thất bại phổ biến ở no-code là **mega-app**: một app khổng lồ cố gắng làm mọi thứ. Cleeksy khuyến khích xây theo **value slice** và kết nối app một cách có chủ đích.
Xem thêm: [Ranh giới App](/foundations/app-boundaries).
## Lộ trình khuyến nghị
Thực hành: [App đầu tiên](/get-started/first-app)
Đọc: [Vận hành số (Digital Operations)](/foundations/digital-operations)
Bắt đầu với: [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
Xem các mục trong **Build apps**: Data modeling, Views & UI, Workflows, Integrations.
Đọc: [SDD là gì](/sdd/overview)
## So sánh thuật ngữ với các công cụ phổ biến
* Entity ≈ Bảng (Table), Record ≈ Dòng (Row), Field ≈ Cột (Column)
* View ≈ Giao diện hiển thị/lọc đã lưu
* Workflow ≈ Quy trình/trạng thái (state machine)
* Publish/Consume ≈ Chia sẻ dữ liệu qua kết nối
Danh sách đầy đủ: [Thuật ngữ (Glossary)](/get-started/glossary).
## Thảo luận & nhận hỗ trợ
* Cộng đồng builder: [community.cleeksy.com](https://community.cleeksy.com)
# Cleeksy Learn
Source: https://learn.cleeksy.com/index
Tài liệu hướng dẫn xây dựng hệ thống vận hành số trên nền tảng Cleeksy DOP.
Cleeksy DOP là nền tảng no-code để thiết kế và vận hành **ứng dụng nghiệp vụ**: có dữ liệu, quy trình, giao diện, phân quyền và khả năng kết nối hệ thống. Cleeksy Learn tập trung vào những nội dung giúp xây app **chạy được**, **dễ mở rộng**, và **vận hành ổn định**.
***
## Bắt đầu theo lộ trình phù hợp
Hiểu bức tranh tổng quan và các khái niệm cốt lõi.
Thực hành tạo một app tối thiểu chạy đầu-cuối.
Nắm cách Cleeksy nhìn về Digital Operations và ranh giới ứng dụng.
***
## Học theo chủ đề (đúng lúc cần dùng)
Tạo app, mô hình dữ liệu, giao diện, quy trình và tích hợp.
Quy tắc ra quyết định: chọn phạm vi, chia nhỏ, ownership dữ liệu.
Triển khai theo kịch bản để tránh mega-app và cải tiến liên tục.
***
## Trang tra cứu nhanh (khi cần “check đúng/sai”)
Kiểu trường, bộ lọc/toán tử, giới hạn, mô hình quyền, mã lỗi.
Triệu chứng thường gặp và cách xử lý theo bước.
Theo dõi thay đổi ảnh hưởng đến việc xây và vận hành app.
***
## Gợi ý cho người mới bắt đầu
### 1) Có kết quả trong ngày đầu
1. [Tổng quan](/get-started/overview)
2. [Xây app đầu tiên](/get-started/first-app)
3. [Cơ bản về App](/build-apps/app-basics)
### 2) Mở rộng theo nhu cầu vận hành
* [Mô hình dữ liệu](/build-apps/data-modeling/entities)
* [Tổng quan giao diện](/build-apps/ui-views/views-overview)
* [Thiết kế quy trình](/build-apps/workflows/process-builder)
* [Chia sẻ dữ liệu](/build-apps/integrations/publish-consume-overview)
* [Phân tích dữ liệu](/build-apps/analytics-hub/overview)
***
## Nhận hỗ trợ và trao đổi
Câu hỏi triển khai và thảo luận tình huống thực tế có thể trao đổi tại **[Community](https://community.cleeksy.com)**.
# Các loại cổng dữ liệu (Data source types)
Source: https://learn.cleeksy.com/reference/data-source-types
Tra cứu các loại Data source và khi nào nên dùng.
Trang này mô tả các **Data source (cổng dữ liệu)** trong Cleeksy DOP. Data source là “điểm kết nối” giúp app nhận dữ liệu từ bên ngoài hoặc chia sẻ dữ liệu cho hệ thống/app khác.
> Gợi ý: trước khi chọn loại data source, xác định rõ **hướng dữ liệu**: vào app (intake), ra ngoài (expose), hay hai chiều.
> Ghi chú: Trong tài liệu này, **Internal portal (cổng nội bộ)** bao gồm cả cách gọi **request portal** (cổng yêu cầu) trong một số ngữ cảnh.
***
## Tổng quan các loại Data source
| Loại | Mục tiêu | Hướng dữ liệu | Dùng khi |
| --------------------------------- | ---------------------------------------- | ---------------------- | --------------------------------------------- |
| Internal portal (Internal portal) | Form nội bộ (request) có kiểm soát quyền | Vào app | Nhân viên nội bộ gửi dữ liệu, cần role gating |
| Public portal | Form công khai | Vào app | Thu thập dữ liệu từ bên ngoài, cần chống spam |
| Webhook portal | Nhận sự kiện/payload từ hệ thống ngoài | Vào app | Hệ thống ngoài đẩy dữ liệu vào app |
| API portal | Cung cấp API đọc/ghi có kiểm soát | Ra ngoài (và/hoặc vào) | Hệ thống ngoài cần pull/push dữ liệu |
| Connected app | Kết nối giữa các app trong Cleeksy | Hai chiều tuỳ cấu hình | Cross-app trong một value slice |
***
## 1) Internal / Public portal (các cổng dạng form)
### Khi nên dùng
* Dữ liệu chủ yếu đến từ “người nhập”
* Cần chuẩn hoá field theo form
* Cần kiểm soát ai được submit (internal) hoặc chống spam (public)
### Điểm cấu hình chính
* Chọn entity đích và field cần nhận
* Map field form → field entity
* Validation ở mức form (bắt buộc, format)
* Quyền submit và giới hạn truy cập
Liên quan:
* Internal portal: [Cổng nội bộ (Internal portal)](/build-apps/integrations/internal-portal)
* Public portal: [Cổng công khai (Public portal)](/build-apps/integrations/public-portal)
***
## 2) Webhook portal (cổng webhook)
### Khi nên dùng
* Hệ thống ngoài phát sinh sự kiện và cần “đẩy” dữ liệu vào app
* Muốn xử lý theo gần thời gian thực
### Điểm cấu hình chính
* Xác định payload tối thiểu cần nhận
* Map payload → field
* Xử lý lỗi và retry (idempotency ở mức thiết kế)
Liên quan: [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
***
## 3) API portal (cổng API)
### Khi nên dùng
* Hệ thống ngoài cần **pull** dữ liệu theo điều kiện
* Hoặc cần **push** dữ liệu có kiểm soát
### Điểm cấu hình chính
* Token/authentication cơ bản
* Endpoint patterns (list/get/create/update)
* Filter/parameter cho truy vấn
Liên quan: [API portal (cổng API)](/build-apps/integrations/api-portal)
***
## 4) Connected app (kết nối ứng dụng)
Connected app là **một loại Data source** dùng để kết nối dữ liệu giữa các app trong Cleeksy. Nó thường đi kèm cơ chế chia sẻ dữ liệu giữa app (publish/consume) và các field liên kết (Data Connection/Lookup/Rollup).
Liên quan:
* [Kết nối ứng dụng (Connected app)](/build-apps/integrations/connected-app)
* [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
***
## Quy tắc chọn nhanh
* Cần người nhập dữ liệu → ưu tiên portal (internal/public)
* Cần hệ thống ngoài đẩy dữ liệu → webhook
* Cần hệ thống ngoài truy vấn theo điều kiện → API
* Cần app ↔ app trong Cleeksy → Connected app + publish/consume + liên kết dữ liệu
***
## Bảo mật tối thiểu
* Không đưa token vào nơi công khai
* Chỉ expose field cần thiết (nguyên tắc tối thiểu)
* Dùng validation để chặn dữ liệu lỗi ngay tại cổng
Liên quan: [Bảo mật (Security)](/build-apps/integrations/security-tokens)
# Mã lỗi & thông báo lỗi (Error messages)
Source: https://learn.cleeksy.com/reference/error-messages
Tra cứu lỗi thường gặp và hướng xử lý nhanh.
Trang này tổng hợp **lỗi phổ biến** theo nhóm và hướng xử lý nhanh. Mục tiêu là giúp tự chẩn đoán trước khi cần hỗ trợ.
***
## 1) Lỗi quyền (permissions)
**Triệu chứng**
* Không thấy view/entity/record
* Không sửa được field
* Không chạy được bước workflow
**Nguyên nhân thường gặp**
* Chưa được mời vào app hoặc role sai
* View/record bị giới hạn theo role
* Workflow step yêu cầu role khác
**Cách xử lý**
* Kiểm tra theo checklist: [Quyền & truy cập (Permissions & access)](/troubleshooting/permissions-access)
***
## 2) Lỗi dữ liệu (data/validation)
**Triệu chứng**
* Không lưu được record
* Field báo thiếu hoặc sai định dạng
* Formula lỗi hoặc cho kết quả trống
**Nguyên nhân thường gặp**
* Field bắt buộc chưa nhập
* Date/number sai format
* Công thức tham chiếu field không tồn tại/không phù hợp kiểu dữ liệu
**Cách xử lý**
* Kiểm tra field type và giá trị nhập
* Kiểm tra ràng buộc bắt buộc và validation trong UI cấu hình
***
## 3) Lỗi workflow & automation
**Triệu chứng**
* Workflow không kích hoạt
* Step không được gán người phụ trách
* Automation rules chạy lặp hoặc tạo spam
**Nguyên nhân thường gặp**
* Điều kiện entry/trigger không thoả
* Trạng thái (Status) không đúng
* Rule thiếu điều kiện chặn vòng lặp
**Cách xử lý**
* Xem lại điều kiện và status
* Áp dụng guardrails chống spam trong: [Thông báo & giao việc](/build-apps/notifications-tasks)
***
## 4) Lỗi Data Connection / publish-consume
**Triệu chứng**
* Không chọn được data source
* Data Connection/Lookup/Rollup không thấy dữ liệu
* Dữ liệu liên kết sai hoặc trống
**Nguyên nhân thường gặp**
* App nguồn chưa publish dataset hoặc chưa chia sẻ đúng data source
* Field liên kết cấu hình sai
* Quyền xem dữ liệu nguồn bị chặn
**Cách xử lý**
* Checklist: [Liên kết dữ liệu (Data connections)](/troubleshooting/data-connections)
***
## 5) Lỗi portal/webhook/API
**Triệu chứng**
* Webhook nhận 401/403/timeout
* API trả lỗi token hoặc rate limit
* Submission không tạo record
**Nguyên nhân thường gặp**
* Token sai/hết hạn
* Payload thiếu field bắt buộc
* Endpoint/URL sai
**Cách xử lý**
* Kiểm tra token và cấu hình data source
* Dùng cách xử lý lỗi và idempotency: [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
***
## Khi nào cần hỗ trợ?
* Lỗi xảy ra ngẫu nhiên, không tái hiện được
* Có rủi ro dữ liệu (mất dữ liệu, sai dữ liệu hàng loạt)
* Liên quan đến tích hợp ngoài với lỗi xác thực/giới hạn phức tạp
Gợi ý: ghi lại **triệu chứng + bước tái hiện + ảnh chụp cấu hình** để hỗ trợ nhanh hơn.
# Ma trận kiểu trường (Field types matrix)
Source: https://learn.cleeksy.com/reference/field-type-matrix
Tra cứu field types và cách chọn kiểu trường phù hợp.
Trang này là bảng tra cứu nhanh về **field types (kiểu trường)** thường dùng trong Cleeksy DOP. Mục tiêu là chọn đúng kiểu trường để dữ liệu dễ dùng, dễ lọc và hỗ trợ quy trình vận hành.
> Quy tắc chung: ưu tiên field có **cấu trúc** (select/status/date/number) thay vì text tự do khi cần lọc, thống kê hoặc kiểm soát trạng thái.
***
## Nhóm field phổ biến
### Text
* **Text / Long text**: nhập mô tả, ghi chú, lý do, nội dung tự do
* Dùng khi: thông tin không có cấu trúc hoặc không cần thống kê theo nhóm
### Number
* **Number / Currency / Percent**: số lượng, chi phí, tỷ lệ
* Dùng khi: cần tính toán, lọc theo ngưỡng, tổng hợp báo cáo
### Date & time
* **Date / Datetime**: thời hạn, ngày hẹn, timestamp phục vụ đo lường
* Dùng khi: cần SLA, lịch, Gantt, cycle time
### Select
* **Single select / Multi select / Status**
* Dùng khi: cần phân loại/nhóm/điều hướng workflow
* Gợi ý: dùng **Status** cho trạng thái vòng đời; dùng select cho phân loại phụ
### People
* **User/People**: người phụ trách, người duyệt, người yêu cầu
* Dùng khi: phân công, kiểm soát quyền, thông báo theo người
### Files
* **Attachment**: chứng từ, hình ảnh, file đính kèm
* Dùng khi: cần lưu bằng chứng hoặc tài liệu liên quan
***
## Field cho liên kết và tổng hợp dữ liệu
> Các field dưới đây dùng để **liên kết dữ liệu** (trong cùng app hoặc giữa các app). Với liên kết giữa app, cần có cơ chế chia sẻ dữ liệu phù hợp (ví dụ publish/consume) để data source xuất hiện trong app đang cấu hình.
### Data Connection
* **Data Connection (một chiều / hai chiều)**: liên kết record giữa hai tập dữ liệu
* Dùng khi: cần “chọn” record nguồn để tham chiếu hoặc gửi/nhận dữ liệu theo thiết kế
### Lookup
* **Lookup (tham chiếu)**: kéo trường từ record đã liên kết để hiển thị
* Dùng khi: muốn hiển thị thông tin nguồn mà không tạo bản sao dữ liệu
### Rollup
* **Rollup (tổng hợp)**: tổng hợp (count/sum/min/max…) từ tập record liên kết
* Dùng khi: cần KPI hoặc số liệu tổng hợp theo một đối tượng
***
## Field tính toán và tự động
### Formula
* Tính toán giá trị từ các field khác (theo công thức)
* Dùng khi: cần logic tính điểm, tổng tiền, trạng thái suy ra…
### Auto number
* Tạo mã tự tăng (ID nội bộ, mã phiếu)
* Dùng khi: cần mã định danh đơn giản và nhất quán
***
## Field cho dữ liệu dạng dòng chi tiết
### Sub-dataset / child table (bảng con)
* Dùng để biểu diễn quan hệ **dạng danh sách dòng** trong một record (ví dụ: order items)
* Dùng khi: một record cần chứa nhiều dòng chi tiết có cấu trúc
***
## Field “bổ sung” (tuỳ nhu cầu)
* **Barcode / QR**: lưu mã và hỗ trợ quét
* **Location**: lưu vị trí
* **Rating**: lưu đánh giá
***
## Ma trận chọn nhanh
| Nhu cầu | Field gợi ý |
| ------------------------------------- | ---------------------------- |
| Trạng thái xử lý | Status |
| Phân loại theo nhóm | Single select / Multi select |
| Người phụ trách / người duyệt | User/People |
| Deadline / lịch hẹn | Date / Datetime |
| Chi phí / số lượng | Number / Currency |
| Ghi chú tự do | Long text |
| Đính kèm chứng từ | Attachment |
| Liên kết record | Data Connection |
| Hiển thị thông tin từ record liên kết | Lookup |
| Tổng hợp số liệu từ record liên kết | Rollup |
| Tính toán tự động | Formula |
| Mã phiếu tự tăng | Auto number |
***
## Liên quan
* Data Connection: [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
* Lookup: [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* Rollup: [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
* Data source: [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
# Bộ lọc & toán tử (Filters & operators)
Source: https://learn.cleeksy.com/reference/filters-operators
Tra cứu filters và operators để lọc dữ liệu đúng.
Trang này là bảng tra cứu nhanh về **filters (bộ lọc)** và **operators (toán tử)**. Mục tiêu là giúp lọc dữ liệu chính xác theo kiểu field.
> Gợi ý: khi lọc nâng cao, luôn xác định rõ **field type** trước (text/number/date/status/people…) để chọn operator phù hợp.
***
## Operators thường gặp (khái quát)
| Nhóm | Operators phổ biến | Dùng khi |
| ---------- | --------------------------- | --------------------------- |
| So khớp | `equals` , `not equals` | so khớp giá trị chính xác |
| Chứa | `contains` , `not contains` | tìm theo từ khoá trong text |
| Rỗng | `is empty` , `is not empty` | kiểm tra thiếu dữ liệu |
| Tập hợp | `in` , `not in` | lọc theo danh sách giá trị |
| So sánh | `>` , `≥` , `<` , `≤` | số lượng, chi phí, điểm |
| Khoảng | between | date/number trong khoảng |
| Thời gian | `before` , `after` , `on` | lọc theo mốc thời gian |
| Người dùng | is, is not, is me | phân công theo user |
***
## Theo từng field type
### Text / Long text
* contains / not contains
* equals / not equals (khi có chuẩn hoá)
* is empty / is not empty
**Ví dụ**
* “Title contains ‘urgent’”
* “Reason is empty”
### Number / Currency / Percent
* `=` , `≠` , `>` , `≥` , `<` , `≤`
* between
* is empty / is not empty
**Ví dụ**
* “Estimated cost > 10,000,000”
* “Qty between 1 and 5”
### Date / Datetime
* before / after / on
* between
* is empty / is not empty
**Ví dụ**
* “Due date before today”
* “Scheduled at between 2026-02-01 and 2026-02-28”
### Single select / Multi select / Status
* equals / not equals
* in / not in
* contains (áp dụng cho multi select theo giá trị)
**Ví dụ**
* `Status in (New, In progress)`
* `Tags contains 'Vendor A'`
### User/People
* is / is not
* is me / is not me
* is empty / is not empty
**Ví dụ**
* “Assignee is me”
* “Approver is empty”
### Attachment
* is empty / is not empty
* (tuỳ UI) has attachments / no attachments
**Ví dụ**
* “Receipt is not empty”
### Data Connection / Lookup / Rollup
* is empty / is not empty
* equals / not equals (với các trường có giá trị xác định)
* `>` , `<` (với rollup dạng số)
**Ví dụ**
* “Vendor link is empty”
* “Total item cost rollup > 5,000,000”
***
## Logic kết hợp (AND/OR)
* **AND**: tất cả điều kiện cùng đúng
* **OR**: chỉ cần một điều kiện đúng
**Pattern phổ biến**
* (Status = Needs info) AND (Due date before today)
* (Assignee is me) OR (Watcher contains me)
***
## Debug lọc “không ra kết quả”
Checklist nhanh:
* Field type có đúng không?
* Giá trị lọc có đúng format (đặc biệt date/datetime)?
* Có filter ẩn khác đang áp dụng không?
* Người dùng có quyền xem record đó không?
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
# Quy ước & giới hạn (Naming & limits)
Source: https://learn.cleeksy.com/reference/naming-limits
Tra cứu quy ước đặt tên và giới hạn thường gặp.
Trang này tổng hợp **quy ước đặt tên** và **giới hạn thường gặp** khi cấu hình app. Mục tiêu là giúp cấu hình nhất quán và tránh lỗi khó debug.
> Lưu ý: một số giới hạn có thể thay đổi theo phiên bản. Khi cần con số cụ thể, ưu tiên kiểm tra trực tiếp trong UI cấu hình.
***
## Quy ước đặt tên (nên áp dụng)
### App
* Dùng danh từ mô tả mục đích vận hành: *Purchase Requests*, *Order Ops*
* Tránh tên quá chung: *System*, *Test*, *New App*
### Entity (thực thể dữ liệu)
* Dùng danh từ số nhiều (gợi ý): *Orders*, *Requests*, *Vendors*
* Một entity = một “đối tượng vận hành” rõ ràng
### Field (trường dữ liệu)
* Dùng cụm danh từ rõ nghĩa: *Requested date*, *Estimated cost*
* Tránh trùng nghĩa: *Date*, *Request date*, *Created date* (khó phân biệt)
### View
* Đặt theo vai trò và mục tiêu: *Verifier queue*, *My tasks*, *Overdue*
* Giúp người dùng hiểu ngay “view này để làm gì”
### Workflow/Step
* Đặt theo hành động hoặc trạng thái: *Verify*, *Approve*, *Schedule*
* Tên step nên khớp status để dễ đọc
***
## Giới hạn thường gặp (nhóm)
### Dữ liệu
* Số lượng entity/field/view/workflow trong một app
* Số lượng record và kích thước file đính kèm
* Giới hạn hiển thị theo view (tuỳ cấu hình)
### Tích hợp
* Giới hạn tần suất gọi API/webhook (rate limit)
* Giới hạn kích thước payload và timeout
### Quyền và chia sẻ
* Giới hạn phạm vi dữ liệu được publish/consume (theo dataset/field)
***
## Lỗi phổ biến do đặt tên
* Field bị trùng tên → khó chọn đúng field khi cấu hình view/workflow
* Entity và view đặt tên mơ hồ → người dùng không biết nên thao tác ở đâu
* Không chuẩn hoá status → khó báo cáo, khó đo cycle time
***
## Checklist nhanh trước khi “go-live”
* [ ] Entity và status đặt tên nhất quán
* [ ] View có tên mô tả mục tiêu sử dụng
* [ ] Field đo lường (timestamps) được đặt rõ và dùng nhất quán
Liên quan: [Rà soát & vận hành (App review)](/build-apps/app-review)
# Mô hình phân quyền (Permissions model)
Source: https://learn.cleeksy.com/reference/permissions-model-public
Hiểu cơ chế phân quyền và phạm vi dữ liệu theo vai trò.
Trang này mô tả **mô hình phân quyền (permissions model)** ở mức . Mục tiêu là giúp hiểu “ai được làm gì” trong app, và tránh lỗi không thấy dữ liệu/không thao tác được.
> Phân quyền tốt giúp app vận hành ổn định: đúng người, đúng việc, đúng dữ liệu.
***
## Các khái niệm cốt lõi
### Role (vai trò)
* Role đại diện cho nhóm người có cùng trách nhiệm trong app (Requester, Approver, Operator…).
* Role quyết định quyền xem/sửa và phạm vi dữ liệu được thao tác.
### App members (thành viên app)
* Người dùng được mời vào app thường được gán role.
* Không có role phù hợp thường dẫn đến lỗi “không thấy view/không sửa được”.
### Permission levels (mức quyền)
Từ góc nhìn người dùng (khái quát):
* **View**: xem dữ liệu
* **Edit**: sửa dữ liệu trong phạm vi cho phép
* **Manage/Admin**: cấu hình app (chỉ dành cho builder/quản trị)
> Tên mức quyền có thể khác theo UI, nhưng ý nghĩa thường tương đương.
***
## Phạm vi quyền (scope)
### Object-level (theo đối tượng)
* Quyền trên entity, view, workflow, data source…
* Ví dụ: được xem entity Orders nhưng không được quản lý workflow
### Record-level (theo record)
* Quy định người dùng được thấy record nào (tất cả / theo điều kiện / theo ownership)
* Ví dụ: requester chỉ thấy record do mình tạo; operator thấy toàn bộ
### Field-level (theo field)
* Cho phép hạn chế sửa một số field theo role hoặc theo trạng thái
* Dùng để giữ “source of truth” và giảm rủi ro sửa sai
***
## Mẫu phân quyền thường dùng
### Requester / Approver / Operator
* Requester: tạo và theo dõi yêu cầu, không chỉnh sửa phần xử lý nội bộ
* Approver: xem thông tin cần duyệt, quyết định approve/reject
* Operator: xử lý nghiệp vụ, cập nhật trạng thái và dữ liệu vận hành
***
## Permission checklist khi gặp lỗi
Nếu “không thấy dữ liệu” hoặc “không thao tác được”, kiểm tra theo thứ tự:
1. Người dùng có được mời vào app chưa?
2. Role có đúng không?
3. View có bị ẩn theo role không?
4. Record visibility có chặn không?
5. Workflow/step có yêu cầu role cụ thể không?
Liên quan: [Quyền & truy cập (Permissions & access)](/troubleshooting/permissions-access)
***
## Liên quan đến chia sẻ dữ liệu giữa app
Khi publish/consume dữ liệu:
* Chỉ publish những field cần thiết (nguyên tắc tối thiểu)
* Kiểm tra quyền xem dữ liệu nguồn và quyền dùng data source ở app đích
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
# Chia sẻ dữ liệu (Publish/Consume)
Source: https://learn.cleeksy.com/reference/publish-consume
Tra cứu cơ chế publish/consume và cách dùng đúng.
Trang này là bảng tra cứu nhanh về **publish/consume** để chia sẻ dữ liệu giữa các app.
Mục tiêu:
* Làm rõ vai trò **provider app** (app nguồn) và **consumer app** (app sử dụng)
* Làm rõ “điểm rơi” khi dùng Data Connection/Lookup/Rollup
* Nhắc các lưu ý quyền và phạm vi dữ liệu
***
## Khái niệm chính
* **Dataset (tập dữ liệu chia sẻ)**: phần dữ liệu được chọn từ entity (và có thể kèm điều kiện/field)
* **Provider app**: app publish dataset
* **Consumer app**: app sử dụng dataset thông qua field liên kết (Data Connection/Lookup/Rollup)
* **Data source (cổng dữ liệu) – data source**: kênh dùng để chia sẻ dataset giữa các app trong Cleeksy
***
## Luồng đúng
### 1) Provider app: publish dataset
* Chọn entity nguồn
* Chọn field được phép chia sẻ (nguyên tắc tối thiểu)
* (Tuỳ cấu hình) thêm điều kiện lọc dữ liệu được chia sẻ
* Chia sẻ qua Data source loại **data source**
### 2) Consumer app: dùng dataset khi cấu hình field liên kết
Trong consumer app, khi tạo field:
* **Data Connection**: chọn dataset (từ data source đã được chia sẻ) để liên kết record
* **Lookup**: tham chiếu field từ record đã liên kết
* **Rollup**: tổng hợp dữ liệu từ các record liên kết
> Lưu ý: “consume” thường diễn ra **ngay trong lúc cấu hình field** (chọn dataset/data source để dùng), không cần một bước tách rời trước đó.
Liên quan:
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
* [Tra cứu (Lookup)](/build-apps/data-modeling/lookup)
* [Tổng hợp (Rollup)](/build-apps/data-modeling/rollup)
***
## One-way vs Two-way (hướng dẫn nhanh)
* **One-way (một chiều)**: consumer liên kết/đọc hoặc gửi dữ liệu theo thiết kế một chiều
Dùng khi: cần ranh giới ownership rõ, tránh vòng lặp đồng bộ
* **Two-way (hai chiều)**: hai bên có liên kết cập nhật/đồng bộ theo thiết kế
Dùng khi: có nhu cầu đồng bộ trạng thái giữa hai bên và đã kiểm soát rõ ràng
Liên quan: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
***
## Lưu ý quyền
* Field nào được chia sẻ
* App nào được chia sẻ quyền **đọc/ghi** dữ liệu
***
## Lỗi thường gặp
* Không thấy dataset/data source để chọn
→ provider chưa publish hoặc chưa chia sẻ đúng phạm vi
* Lookup/Rollup ra trống
→ Filter có thể được thiết lập chưa phù hợp
Liên quan: [Liên kết dữ liệu (Data connections)](/troubleshooting/data-connections)
# Khái niệm workflow (Workflow primitives)
Source: https://learn.cleeksy.com/reference/workflow-primitives
Tra cứu các khái niệm nền tảng của workflow và automation.
Trang này là bảng tra cứu nhanh về các **khái niệm workflow** trong Cleeksy DOP. Mục tiêu là giúp đọc đúng và cấu hình đúng khi xây quy trình.
***
## 1) Status / State (trạng thái)
* **Status** là field biểu diễn trạng thái của record theo vòng đời xử lý.
* Status tốt giúp:
* theo dõi tồn đọng
* đo cycle time
* điều hướng workflow theo step
Gợi ý:
* Chỉ cần 3–6 status cho vòng đời chính (đừng quá nhiều)
* Tách “phân loại” sang select khác, không nhồi vào status
***
## 2) Process (quy trình) & Step (bước)
### Process
* Một quy trình mô tả các bước xử lý chính của một loại record.
### Step
* Một step là một giai đoạn xử lý với:
* điều kiện vào bước (entry)
* người phụ trách (assignment)
* người được theo dõi (CC/Informed)
* thời hạn (due date)
* hành động/đầu ra (chuyển trạng thái, cập nhật field…)
***
## 3) Assignment (giao việc)
Các pattern phổ biến:
* **PIC (person in charge)**: một người chịu trách nhiệm chính
* **Group assignment**: giao cho một nhóm/role
* **CC/Informed**: người được theo dõi thông tin (không phải người xử lý)
Liên quan: [Thông báo & giao việc](/build-apps/notifications-tasks)
***
## 4) Approval (phê duyệt)
Approval là một dạng quyết định có cấu trúc:
* approve / reject (và có thể kèm yêu cầu bổ sung)
* có người duyệt hoặc nhóm duyệt
* thường gắn với audit trail và notification
Gợi ý:
* Dùng approval khi cần “quyết định” theo vai trò
* Không dùng approval cho các bước xử lý tác nghiệp thông thường
Liên quan: [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
***
## 5) Tasks & Notifications (tác vụ & thông báo)
* **Task** thường xuất hiện khi một step yêu cầu người dùng hành động.
* **Notification** giúp người dùng biết:
* có task mới
* task quá hạn
* record chuyển trạng thái quan trọng
Guardrails chống spam :
* Chỉ thông báo theo sự kiện quan trọng
* Tránh gửi lặp khi automation chạy nhiều lần
* Có “điều kiện chặn” trong rule nếu cần
***
## 6) Automation rules (tự động hoá)
Automation rules thường dùng để:
* gán người phụ trách theo điều kiện
* tạo mới record hoặc cập nhật field dữ liệu
* gửi thông báo/email theo sự kiện
Gợi ý:
* Luôn có điều kiện rõ để tránh vòng lặp
Liên quan: [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules)
***
## 7) Workflow + validation + roles (chọn đúng “công cụ”)
* **Roles/permissions**: kiểm soát “ai được làm gì”
* **Validation**: chặn dữ liệu sai ngay khi nhập
* **Workflow**: điều phối luồng xử lý và giao việc
Liên quan: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
# 2026
Source: https://learn.cleeksy.com/release-notes/2026
Ghi chú phát hành theo tuần trong năm 2026.
Trang này tổng hợp các thay đổi theo từng đợt phát hành trong năm 2026. Mỗi mục tập trung vào thay đổi **ảnh hưởng đến việc xây và vận hành app**.
* **Highlights**: thay đổi quan trọng nhất
* **Mới / Cải tiến / Sửa lỗi**: thay đổi theo nhóm
* **Thay đổi có thể ảnh hưởng**: cần kiểm tra lại app hiện có (nếu có)
### Highlights
* Cập nhật cấu trúc tài liệu và chuẩn hoá thuật ngữ trên Learn.
* Bổ sung trang Troubleshooting để giảm thời gian xử lý lỗi phổ biến.
### Mới
* Thêm hướng dẫn khắc phục lỗi cho Views & UI, Data connections, Workflows và Integrations.
### Cải tiến
* Tối ưu nội dung liên kết giữa các trang tham chiếu và hướng dẫn.
### Sửa lỗi
* Sửa lỗi parse MDX do ký tự đặc biệt trong một số ví dụ toán tử/lọc.
### Thay đổi có thể ảnh hưởng
* Một số trang đổi tên/đổi đường dẫn theo chuẩn điều hướng mới (liên kết cũ có thể cần cập nhật).
### Vấn đề đã biết
* Một số ví dụ sẽ được mở rộng theo lộ trình khi tính năng tương ứng được bổ sung trong sản phẩm.
### Bảo mật
* Cập nhật hướng dẫn bảo mật token theo nguyên tắc “không chia sẻ thông tin nhạy cảm trong tài liệu công khai”.
### Highlights
* Bổ sung Gantt view (dạng sơ đồ) trong nhóm Views & UI.
* Cải thiện luồng cấu hình Data Connection (một chiều) với data source.
### Mới
* Views & UI: thêm Gantt view (dạng sơ đồ) để theo dõi kế hoạch theo thời gian.
### Cải tiến
* Views & UI: cải thiện trải nghiệm điều hướng và cấu hình record layout.
* Data sources & integrations: làm rõ các loại data source và phạm vi sử dụng.
### Sửa lỗi
* Khắc phục một số trường hợp view không hiển thị đúng khi filter phức tạp.
### Thay đổi có thể ảnh hưởng
* Kanban view: group theo **Status** của workflow (các field khác chưa hỗ trợ group).
### Highlights
* Cải thiện độ ổn định của process builder khi app có nhiều bước.
* Bổ sung trang tham chiếu Filters & operators.
### Mới
* Workflows: bổ sung mẫu cấu hình task/notification theo bước.
* Reference: bổ sung hướng dẫn filters/operators cho các kiểu field phổ biến.
### Cải tiến
* Workflows: tối ưu thao tác gán người phụ trách và người được theo dõi (CC/Informed).
### Sửa lỗi
* Sửa lỗi hiển thị không nhất quán khi chuyển trạng thái liên tiếp trong workflow.
### Vấn đề đã biết
* Một số automation rule có thể cần điều kiện chặn để tránh gửi thông báo lặp trong trường hợp cập nhật hàng loạt.
# Ghi chú phát hành
Source: https://learn.cleeksy.com/release-notes/index
Theo dõi thay đổi sản phẩm theo từng đợt phát hành.
Trang này là điểm vào cho **release notes** của Cleeksy DOP.
* Xem ghi chú theo năm: [2026](/release-notes/2026)
* Mục tiêu của release notes: giúp người xây app biết **có gì thay đổi** và **cần kiểm tra gì**.
## Cách đọc nhanh
* Bắt đầu từ **Highlights**.
* Nếu thấy mục **Thay đổi có thể ảnh hưởng**, nên rà soát các app đang chạy (workflow, view, data source…).
* Mỗi thay đổi nên được hiểu theo “ảnh hưởng tới cấu hình/ vận hành”, không đi sâu chi tiết kỹ thuật nội bộ.
# Khái niệm & đầu ra cốt lõi
Source: https://learn.cleeksy.com/sdd/core-concepts-artifacts
Khái niệm và đầu ra (Core concepts & key artifacts) tối thiểu để áp dụng SDD.
Trang này tóm tắt **bộ khái niệm và tài liệu (artifacts) tối thiểu** để áp dụng SDD trong thực tế. Các artifacts được tổ chức theo mức độ “từ ý tưởng → triển khai → vận hành”, nhằm đảm bảo:
* Phạm vi nhỏ nhưng chạy được end-to-end
* Có tiêu chí đo lường để biết “đã tạo giá trị hay chưa”
* Tránh mega-app bằng cách chốt ranh giới và triển khai theo kịch bản
Liên quan:
* [SDD là gì](/sdd/overview)
* [Outer loop: scenario backlog (lập kế hoạch theo kịch bản)](/sdd/outer-loop-scenario-backlog)
* [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)
***
## Cấu trúc artifacts theo SDD
* **Outer loop** thường dùng: *Value slice* → *BRD* → ưu tiên *scenario backlog*
* **Inner loop** thường dùng: *User scenario* → *Solution concept* → *Application specification* → *Test scenario* → *Runbook*
Mục tiêu không phải là tạo tài liệu “đầy đủ tuyệt đối”, mà là tạo **đầu ra vừa đủ** để đội build đúng, test được, và vận hành ổn định.
***
## 1) Value Slice (lát giá trị)
**Value slice** là một lát nhỏ, có ranh giới rõ trong **value stream (chuỗi giá trị)**, tạo ra giá trị end-to-end và **đo được**.
**Tiêu chí chất lượng**
* Nhỏ và có ranh giới (in/out) rõ
* Chạy end-to-end cho một mục tiêu vận hành cụ thể
* Có 1–3 **measurable outcomes** (kết quả đo được)
* Gồm nhiều **user scenario** (happy path + ngoại lệ quan trọng)
* Có thể gồm **một hoặc nhiều app** (tuỳ ranh giới dữ liệu và ranh giới vận hành)
**Đầu ra tối thiểu**
* Mục tiêu và phạm vi (in/out)
* Kết quả đo được + cách lấy số (từ field nào/report nào)
* Danh sách scenario thuộc slice (3–10 scenario ở mức thô)
Liên quan: [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
***
## 2) BRD (Business Requirements Document) theo value stream
BRD là tài liệu yêu cầu theo **value stream**, trong đó có các phần (section) cho từng slice. BRD giúp giữ sự nhất quán giữa “vấn đề cần giải” và “thứ sẽ triển khai”.
**Nội dung gợi ý (tối thiểu)**
* **Problem / goals / scope** (vấn đề – mục tiêu – phạm vi)
* **Current workflow & pain points** (quy trình hiện tại + điểm đau)
* **Stakeholders & roles** (bên liên quan + vai trò)
* Nhóm yêu cầu theo loại (để dễ kiểm thử và truy vết):
* **FR (Functional Requirements)**: yêu cầu chức năng theo kịch bản
* **DR (Data Requirements)**: dữ liệu cần thu thập/hiển thị/chuẩn hoá
* **IR (Integration Requirements)**: tích hợp nội bộ/ngoài (portal/webhook/api/connected app)
* **RA (Roles & Access)**: vai trò và phân quyền
* **SR (Security/Sharing Requirements)**: chia sẻ dữ liệu, giới hạn truy cập, quy tắc công khai
* **NFR (Non-Functional Requirements)**: hiệu năng, ổn định, audit, lưu trữ, SLA…
**Đầu ra tối thiểu cho mỗi value slice trong BRD**
* Mục tiêu slice + measurable outcomes
* Danh sách scenario (kèm ưu tiên thô)
* Ghi chú ranh giới dữ liệu/app (ownership, publish/consume nếu có)
***
## 3) User Scenario (kịch bản người dùng)
User scenario là đơn vị trung tâm của SDD để thiết kế, build và test. Một scenario tốt đủ chi tiết để chạy end-to-end, nhưng không sa vào “đặc tả kỹ thuật”.
**Cấu trúc tối thiểu**
* **Actor** (vai trò) + **trigger** (điểm kích hoạt) + **preconditions** (điều kiện trước)
* **Steps**: happy path + ngoại lệ quan trọng (1–2 ngoại lệ)
* **Expected outcome**: kết quả mong đợi (dữ liệu, trạng thái, ai được thông báo)
**Gợi ý thêm để dễ triển khai**
* Field tối thiểu cần nhập/xem/cập nhật
* Tiêu chí chấp nhận (acceptance criteria) 5–10 ý
* “Điểm kiểm tra” về quyền (ai được làm gì/nhìn gì)
Liên quan: [Cơ bản về Scenario](/foundations/scenario-basics)
***
## 4) Solution Concept (khái niệm giải pháp)
Solution concept là bản thiết kế cấp hệ thống để trả lời: *giải pháp sẽ được tổ chức thành những app nào, dữ liệu ở đâu, kết nối ra sao, ai dùng thế nào*.
**Nội dung tối thiểu**
* **Workspaces & apps**: app nào thuộc workspace nào, ranh giới trách nhiệm
* **Key entities** và cách liên kết (Data Connection/Lookup/Rollup/Sub-dataset)
* **Roles & access**: nhóm vai trò và quyền chính
* **Internal/external integrations**:
* Intake dữ liệu (Internal portal / Public portal / Webhook)
* Pull/đồng bộ (API)
* Cross-app (publish/consume + Data source loại Connected app)
**Đầu ra tối thiểu**
* Một sơ đồ đơn giản (app ↔ dữ liệu ↔ người dùng ↔ tích hợp)
* Ghi chú “source of truth” cho dữ liệu quan trọng
* Quyết định cross-app: khi nào submit, khi nào tham chiếu, khi nào tổng hợp
Liên quan:
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
* [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
* [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
***
## 5) Application Specification (đặc tả ứng dụng)
Application specification là đặc tả ở mức “cấu hình được” cho từng app trong slice. Đây là cầu nối giữa Design và Build.
**Nội dung tối thiểu**
* **Entities & fields**: entity chính, field bắt buộc, field dùng để đo (timestamp/status/owner)
* **Workflows & states**: trạng thái, bước xử lý, điều kiện chuyển trạng thái, approvals (nếu có)
* **Forms & views**: view theo vai trò (requester/operator/approver), record layout
* **Permissions & data connections**: role-based access, publish/consume nếu cross-app, các Data Connection cần dùng
**Đầu ra tối thiểu**
* Danh sách cấu hình “must-have” để scenario chạy được
* Danh sách cấu hình “nice-to-have” để mở rộng sau (để tránh scope creep)
Liên quan:
* [Cơ bản về App](/build-apps/app-basics)
* [Tổng quan giao diện](/build-apps/ui-views/views-overview)
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
***
## 6) Test Scenario (kịch bản kiểm thử)
Test scenario dùng để kiểm thử **end-to-end theo scenario**, đặc biệt khi slice có nhiều app.
**Cấu trúc tối thiểu**
* Preconditions & test data (điều kiện và dữ liệu kiểm thử)
* Steps across apps (các bước chạy qua các app, nếu có)
* Expected results (kết quả mong đợi về dữ liệu, trạng thái, quyền)
* Mapping to BRD requirements (liên kết tới FR/DR/IR/RA/SR/NFR liên quan)
**Đầu ra tối thiểu**
* Một bộ test cho happy path
* 1–2 test cho ngoại lệ quan trọng (reject, thiếu dữ liệu, quá hạn…)
* Test quyền theo role (ai thấy gì, ai làm gì)
Liên quan: [Rà soát & vận hành (App review)](/build-apps/app-review)
***
## 7) Runbook (sổ tay vận hành)
Runbook là tài liệu cho “day-2 operations”: sau go-live, hệ thống được theo dõi, xử lý sự cố và cải tiến như thế nào.
**Nội dung tối thiểu**
* Cách theo dõi vận hành: tồn đọng, quá hạn, cycle time, lỗi thường gặp
* Cách xử lý sự cố: phân loại lỗi (data/workflow/permission/integration), bước kiểm tra nhanh
* Quy trình thay đổi: cập nhật field/workflow/view, kiểm thử lại, phát hành
* Quản lý quyền: cấp quyền, thu hồi, nguyên tắc tối thiểu
* Quy tắc xử lý dữ liệu: khi nào được sửa dữ liệu, ai chịu trách nhiệm, cách truy vết
Liên quan:
* [Thông báo & giao việc](/build-apps/notifications-tasks)
* [Tổng quan phân tích dữ liệu](/build-apps/analytics-hub/overview)
***
## Bước tiếp theo
* Nếu đang lập kế hoạch và ưu tiên: [Outer loop: scenario backlog (lập kế hoạch theo kịch bản)](/sdd/outer-loop-scenario-backlog)
* Nếu đang triển khai một vòng: [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)
# Inner loop: Chu kỳ triển khai
Source: https://learn.cleeksy.com/sdd/inner-loop-delivery-cycle
Triển khai giải pháp theo trình Define -> Design -> Build -> Test -> Adopt.
Inner loop là **chu kỳ triển khai (delivery cycle)** trong SDD. Mục tiêu là đưa một lát cải tiến vào vận hành **an toàn, đo được, và có thể lặp lại**.
Chu kỳ gồm 5 bước:
1. Define → 2) Design → 3) Build → 4) Test → 5) Adopt
Điểm quan trọng: mỗi bước đều tạo ra **artifact** (đầu ra) rõ ràng và có “điểm rơi” tương ứng trong Cleeksy DOP.
Liên quan:
* [SDD là gì](/sdd/overview)
* [Outer loop: scenario backlog (lập kế hoạch theo kịch bản)](/sdd/outer-loop-scenario-backlog)
* [Khái niệm & đầu ra cốt lõi (Core concepts & key artifacts)](/sdd/core-concepts-artifacts)
***
## Tổng quan: bước → artifacts → điểm rơi trong Cleeksy
| Bước | Mục tiêu | Artifacts tối thiểu | Điểm rơi trong Cleeksy DOP |
| ------ | ------------------------------------------------ | ------------------------------------------------------ | ------------------------------------------------------------------------ |
| Define | Chốt “đang làm gì” và “xong là như thế nào” | Scenario rõ + tiêu chí hoàn thành + dữ liệu tối thiểu | Entity/Field nháp, Role/đối tượng người dùng, tiêu chí đo |
| Design | Chốt “sẽ vận hành như thế nào” | Future-state flow + trạng thái + ranh giới app/dữ liệu | Views/Record layout, Workflow design, publish/consume & data source plan |
| Build | Cấu hình để chạy được end-to-end | App skeleton chạy được | Data modeling, Views & UI, Workflows, Roles/permissions, Data sources |
| Test | Kiểm tra đúng kịch bản, đúng quyền, đúng dữ liệu | Test cases theo scenario + kết quả | App review checklist, lỗi & cách sửa, điều chỉnh config |
| Adopt | Đưa vào vận hành và đo hiệu quả | Hướng dẫn sử dụng + số đo + backlog cải tiến | Onboarding người dùng, Analytics Hub, vòng cải tiến |
> Nếu một bước chưa tạo ra artifact tối thiểu, thường nên dừng để làm rõ trước khi đi tiếp.
***
## 1) Define
### Mục tiêu
* Chốt 1–3 **scenario** cho increment (happy path trước)
* Chốt **definition of done** (DoD): chạy end-to-end + tiêu chí đo
* Chốt dữ liệu tối thiểu cần có để kịch bản chạy được
### Artifacts tối thiểu
* **Scenario card** (thẻ kịch bản) gồm:
* Vai trò (role) liên quan
* Trigger và mục tiêu
* Các bước chính (5–10 bước)
* Dữ liệu cần nhập/xem/cập nhật
* Ngoại lệ tối thiểu (nếu có)
* **Acceptance criteria** (tiêu chí chấp nhận)
* **Data checklist**: field bắt buộc để chạy kịch bản
### Mapping sang Cleeksy
* Xác định Entity chính và các field cốt lõi: [Thực thể dữ liệu (Entity)](/build-apps/data-modeling/entities), [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
* Xác định role và phạm vi quyền: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
* Xác định kênh vào/ra dữ liệu (nếu có): [Cổng dữ liệu (Data source)](/build-apps/integrations/data-sources-overview)
***
## 2) Design
### Mục tiêu
* Chốt **future state**: quy trình và trải nghiệm vận hành sau khi có hệ thống
* Chốt **trạng thái (status)** và các chuyển trạng thái
* Chốt ranh giới app và ownership dữ liệu (đặc biệt khi có nhiều app)
### Artifacts tối thiểu
* **Process sketch**: các bước và trạng thái (as-is → to-be ở mức tối thiểu)
* **State model**: status + điều kiện chuyển trạng thái
* **UI sketch**: view nào cho ai (operational view vs requester view)
* **Data boundary note**: dữ liệu thuộc app nào, có cần publish/consume không
### Mapping sang Cleeksy
* Views/Record layout theo vai trò:
* [Tổng quan giao diện](/build-apps/ui-views/views-overview)
* [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
* Workflow thiết kế theo trạng thái:
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
* [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
* Chia sẻ dữ liệu giữa app:
* [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
* [Kết nối dữ liệu hai chiều (Data Connection two-way)](/build-apps/data-modeling/data-connection-two-way)
***
## 3) Build
### Mục tiêu
* Cấu hình đủ để kịch bản chạy end-to-end
* Giữ phạm vi đúng như Define/Design (tránh “tiện thì làm thêm”)
### Artifacts tối thiểu
* App skeleton:
* Entity/Field đủ dùng
* 2–3 view tối thiểu theo vai trò
* Workflow tối thiểu để chuyển trạng thái
* Role/permission tối thiểu để chạy kịch bản
* Data source cần thiết (nếu có intake/submit/integration)
### Mapping sang Cleeksy
* Data modeling: [Bản ghi (Record)](/build-apps/data-modeling/records), [Kiểu trường dữ liệu (Field types)](/build-apps/data-modeling/field-types)
* Views & UI: [Dạng bảng (Grid view)](/build-apps/ui-views/grid-view), [Dạng thẻ (Kanban view)](/build-apps/ui-views/kanban-view)
* Workflow: [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules)
* Permissions: [Cơ bản về App](/build-apps/app-basics)
***
## 4) Test
### Mục tiêu
* Kiểm thử theo scenario (không chỉ kiểm thử tính năng)
* Kiểm tra quyền (ai thấy gì, ai làm gì)
* Kiểm tra dữ liệu (đúng nguồn, đúng trạng thái)
### Artifacts tối thiểu
* **Scenario test cases**:
* Happy path
* 1–2 ngoại lệ quan trọng (thiếu dữ liệu, bị reject, quá hạn…)
* **Permission check** theo role
* Danh sách lỗi + quyết định sửa (fix/adjust/scope out)
### Mapping sang Cleeksy
* Dùng view vận hành để kiểm tra flow
* Dùng [Rà soát & vận hành (App review)](/build-apps/app-review) làm checklist:
* workflow chạy đúng?
* trạng thái rõ?
* thông báo/giao việc đúng?
* dữ liệu không bị lệch?
***
## 5) Adopt
### Mục tiêu
* Đưa increment vào vận hành thực tế
* Thiết lập nhịp theo dõi và phản hồi
* Tạo vòng cải tiến trở lại outer loop
### Artifacts tối thiểu
* Hướng dẫn ngắn theo vai trò (Requester/Approver/Operator)
* “Operational dashboard” tối thiểu (hoặc báo cáo đơn giản)
* Danh sách phản hồi + quyết định cải tiến (đưa vào backlog)
### Mapping sang Cleeksy
* Thông báo và giao việc: [Thông báo & giao việc](/build-apps/notifications-tasks)
* Báo cáo: [Tổng quan phân tích dữ liệu](/build-apps/analytics-hub/overview)
* Vòng cải tiến: [Vòng lặp cải tiến (Improve loop)](/foundations/improve-loop)
***
## Guardrails để inner loop “nhỏ mà chạy được”
* Chỉ chọn 1–3 scenario cho một vòng triển khai
* Happy path trước, ngoại lệ mở rộng theo dữ liệu vận hành
* Chốt ranh giới dữ liệu và app trước khi làm cross-app
* Mọi thay đổi phải map được về scenario và tiêu chí đo
***
## Bước tiếp theo
* Xem cách map tổng thể: [Khái niệm & đầu ra cốt lõi (Core concepts & key artifacts)](/sdd/core-concepts-artifacts)
# Outer loop: Lập kế hoạch
Source: https://learn.cleeksy.com/sdd/outer-loop-scenario-backlog
Lập kế hoạch theo kịch bản (scenario backlog) và ưu tiên value slice.
Outer loop là cơ chế lập kế hoạch và điều hướng cải tiến theo SDD. Mục tiêu là chọn đúng phạm vi, giao giá trị sớm, và duy trì nhịp cải tiến dựa trên dữ liệu vận hành.
Outer loop trả lời 3 câu hỏi:
* Nên triển khai **lát giá trị (value slice)** nào trước?
* Cần những **kịch bản (scenario)** nào để lát đó chạy end-to-end?
* Làm sao biết increment đã tạo ra **kết quả đo được**?
Liên quan: [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
***
## 1) Scenario backlog là gì?
Scenario backlog là danh sách các **user scenario** được mô tả theo ngôn ngữ vận hành (ai làm gì, bối cảnh nào, ngoại lệ nào, dữ liệu nào cần kiểm soát), được sắp xếp theo mức ưu tiên để triển khai theo vòng lặp.
Một scenario backlog tốt giúp:
* Giữ phạm vi luôn bám theo công việc thực tế
* Tránh “gom yêu cầu” thành mega-app
* Tạo ngôn ngữ chung giữa vận hành – nghiệp vụ – builder
***
## 2) Prioritization (ưu tiên) theo giá trị và rủi ro
Ưu tiên trong outer loop nên dựa trên kết hợp:
### A) Tác động (impact)
* Giảm thời gian xử lý / giảm tồn đọng
* Tăng khả năng kiểm soát / giảm lỗi
* Tăng minh bạch và khả năng truy vết
### B) Tần suất (frequency)
* Scenario xảy ra nhiều lần/ngày/tuần thường đáng ưu tiên hơn.
### C) Rủi ro (risk)
* Rủi ro tuân thủ, rủi ro sai số liệu, rủi ro tài chính
* Ưu tiên scenario giúp giảm rủi ro lớn sớm
### D) Nỗ lực (effort)
* Ưu tiên “nhỏ nhưng tạo giá trị sớm” (small win)
* Tránh chọn “đại dự án” ngay từ đầu
Gợi ý khung ưu tiên nhanh:
* **High impact + low effort** → làm trước
* **High risk** → đưa vào sớm để giảm rủi ro
* **Low impact + high effort** → để sau hoặc loại bỏ
***
## 3) Slicing (cắt lát) để tránh mega-app
Khi cắt lát, mục tiêu là tạo ra một increment có thể chạy end-to-end với phạm vi nhỏ, thay vì cố gắng “bao trọn” quy trình lớn.
Các cách cắt lát thường dùng:
### A) Theo kết quả (outcome)
Ví dụ: “Từ submitted → approved” trước, rồi mới mở rộng “approved → procurement”.
### B) Theo vai trò (role)
Ví dụ: làm trước luồng cho Requester + Approver, sau đó mở rộng thêm Finance hoặc Procurement.
### C) Theo mức độ ngoại lệ
* Làm **happy path** trước
* Thêm ngoại lệ theo dữ liệu vận hành (dựa trên các case thực tế)
### D) Theo dữ liệu tối thiểu
* Chỉ thu thập các field cần để quyết định và vận hành
* Mở rộng field khi có nhu cầu đo lường hoặc kiểm soát tốt hơn
Liên quan:
* [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
* [Cơ bản về Scenario](/foundations/scenario-basics)
* [Ranh giới App](/foundations/app-boundaries)
***
## 4) Measurable outcomes (kết quả đo được)
Mỗi value slice nên có 1–3 kết quả đo được, ví dụ:
* Thời gian xử lý trung bình giảm từ X xuống Y
* Tỷ lệ quá hạn giảm từ X% xuống Y%
* Tỷ lệ dữ liệu thiếu/không hợp lệ giảm
* Số bước thủ công hoặc số lần trao đổi lại giảm
Nguyên tắc:
* Đo theo **hành vi vận hành** (work actually happens), không chỉ theo số tính năng
* Chọn chỉ số có thể lấy từ dữ liệu trong app/Analytics Hub
Liên quan: [Tổng quan phân tích dữ liệu](/build-apps/analytics-hub/overview)
***
## 5) Từ value slice → scenario backlog (cách lập backlog)
Một quy trình thực dụng:
1. Viết mô tả value slice: mục tiêu + tiêu chí thành công
2. Liệt kê 5–10 scenario theo vai trò:
* Happy path
* Ngoại lệ phổ biến
* Case rủi ro cao
3. Gắn “độ ưu tiên” và “độ khó” cho từng scenario
4. Chọn 1–3 scenario đầu để đưa vào inner loop
5. Sau khi adopt: thu phản hồi + dữ liệu, cập nhật backlog
***
## 6) Output của outer loop (để vào inner loop)
Outer loop nên tạo ra các đầu ra tối thiểu:
* Danh sách value slice theo ưu tiên
* Scenario backlog (đã cắt lát, đã gắn ưu tiên)
* Tiêu chí đo lường cho increment
* Ràng giới sơ bộ: app nào, dữ liệu nào thuộc ownership ở đâu
Sau đó chuyển sang inner loop để define/design/build/test/adopt.
Liên quan: [Inner loop: delivery cycle (chu kỳ triển khai)](/sdd/inner-loop-delivery-cycle)
# Khung tư duy SDD
Source: https://learn.cleeksy.com/sdd/overview
Tổng quan về SDD và hai vòng lặp outer/inner loop.
SDD (Scenario-Driven Development), được phát triển bởi Cleeksy, là phương pháp thiết kế và triển khai các hệ thống Digital Operations bằng cách bắt đầu từ giá trị cần đạt (value) và đi đến hệ thống (system) thông qua kịch bản vận hành (scenarios).
Trong SDD:
* **Value Slice** xác định *mục tiêu* và *phạm vi cải thiện*.
* **User Scenarios** là đơn vị trung tâm để phân tích → thiết kế → build → test.
* **Work System** (hệ thống vận hành) được cấu hình để các kịch bản chạy **end-to-end** trong thực tế.
***
## Vì sao cần SDD?
Khi triển khai no-code/low-code, các vấn đề hay gặp:
* Dễ “xây theo tính năng rời rạc” → khó ưu tiên, khó kiểm thử end-to-end
* Scope phình to thành mega-app
* Dữ liệu bị nhân bản
* Go-live xong nhưng thiếu nhịp **đo lường → học → cải tiến**
SDD tạo ra một chu kỳ lặp rõ ràng để mỗi phiên bản triển khai:
* có phạm vi nhỏ, test được
* có tiêu chí thành công (success criteria)
* bám sát hành vi vận hành thực tế
* dễ mở rộng theo backlog scenario ưu tiên
***
## Chuỗi tư duy cốt lõi của SDD
SDD giữ mọi thứ “có thể truy vết” theo một chuỗi đơn giản:
**Value Slice → Business Requirements → User Scenarios → Integrated Work System**
### 1) Value Slice (đơn vị lập kế hoạch)
Một value slice là một lát cắt giá trị nhỏ, đo lường được trong value stream (chuỗi giá trị end-to-end). Value slice làm rõ:
* outcome/kết quả mong muốn
* phạm vi cải thiện (start/end boundary)
* tiêu chí thành công (metrics)
### 2) Business Requirements (nguồn thông tin chính thống)
**Business Requirements** là yêu cầu về kinh doanh của value slice, thường gồm:
* mục tiêu, phạm vi
* các đối tượng liên quan và vai trò
* hiện trạng hệ thống vận hành
* nhóm yêu cầu: **FR** (chức năng), **DR** (dữ liệu), **IR** (tích hợp), **RA** (báo cáo), **SR** (bảo mật)
### 3) User Scenario (đơn vị phân tích & kiểm thử)
**User Scenario** mô tả một tình huống người thật làm việc để đạt một outcome cụ thể:
* Vai trò người dùng, sự kiện, điều kiện kích hoạt
* Luông vận hành (chuỗi hành động của người dùng và hệ thống)
* Ngoại lệ
* Kết quả mong đợi
### 4) Integrated Work System (giải pháp triển khai trên Cleeksy DOP)
**Work system** là giải pháp cấu hình chạy được:
* Apps, mô hình dữ liệu, giao diện người dùng
* Luồng xử lý/phê duyệt/tự động hóa
* Vai trò/quyền truy cập/kiểm soát hệ thống
* Tích hợp và kết nối các ứng dụng
***
## Hai vòng lặp của SDD
SDD vận hành theo **2 vòng lặp**: lập kế hoạch và triển khai.
### Outer loop: Scenario Backlog (lập kế hoạch)
Outer loop trả lời: **“Xây gì tiếp theo?”**
1. Khám phá/xác định user scenarios
2. Lập backlog theo ưu tiên:
* giá trị kinh doanh
* trải nghiệm người dùng
* độ phức tạp/rủi ro
3. Chọn **1–3 scenarios** cho vòng triển khai
4. Triển khai giải pháp → tiếp nhận feedback → cập nhật backlog → lặp lại
Mục tiêu: luôn tập trung vào một nhóm nhỏ kịch bản quan trọng và kết thúc bằng một phiên bản chạy được.
### Inner loop: Delivery cycle (chu kỳ triển khai)
Inner loop trả lời: **“Làm thế nào để triển khai giải pháp?”**
Xác định rõ scenarios và success criteria.
Thiết kế future-state của hệ thống và solution concept.
Xây dựng ứng dụng trên Cleeksy DOP để scenarios chạy được end-to-end.
Kiểm thử end-to-end bằng Test Scenarios.
UAT/go-live, bàn giao, theo dõi vận hành và đưa feedback vào backlog.
Trong SDD, “delivery” không chỉ là build — mà là define/design/test/adopt để đảm bảo hệ thống chạy được trong thực tế.
***
## Đọc tiếp
* Outer loop: [Scenario backlog](/sdd/outer-loop-scenario-backlog)
* Inner loop: [Delivery cycle](/sdd/inner-loop-delivery-cycle)
* Core concepts & artifacts: [Khái niệm & artifacts](/sdd/core-concepts-artifacts)
* Viết scenario: [Scenario basics](/foundations/scenario-basics)
* Tránh mega-app: [App boundaries](/foundations/app-boundaries)
# Phân tích dữ liệu (Analytics Hub)
Source: https://learn.cleeksy.com/troubleshooting/analytics-hub
Khắc phục lỗi report không đúng số hoặc không thấy dữ liệu.
Trang này tổng hợp lỗi phổ biến khi tạo và dùng **reports** trong Analytics Hub.
Liên quan:
* [Tổng quan phân tích dữ liệu](/build-apps/analytics-hub/overview)
* [Tạo báo cáo (Create reports)](/build-apps/analytics-hub/create-reports)
* [Chia sẻ & phân quyền (Sharing & permissions)](/build-apps/analytics-hub/sharing-permissions)
***
## Checklist nhanh
1. Report đang đọc dữ liệu từ **entity/dataset** nào?
2. Filter có đang chặn dữ liệu không?
3. Người xem report có đủ quyền xem dữ liệu nguồn không?
4. Field dùng để nhóm/tính toán có đúng kiểu dữ liệu (number/date/status) không?
5. Khoảng thời gian (date range) có đúng timezone và đúng field thời gian không?
***
## 1) Không thấy dữ liệu trong report
### Nguyên nhân thường gặp
* Người dùng không có quyền xem dữ liệu nguồn
* Data source được chia sẻ nhưng dữ liệu nguồn bị giới hạn theo role/visibility
* Filter mặc định quá chặt hoặc sai giá trị
### Cách xử lý
* Kiểm tra quyền xem entity/record của người xem
* Thử tắt/bỏ filter để kiểm tra dữ liệu có xuất hiện không
* Kiểm tra report có trỏ đúng data source không
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
***
## 2) Số liệu “không đúng” (count/sum sai)
### Nguyên nhân thường gặp
* Field cần tổng hợp đang là Text thay vì Number/Currency
* Filter điều kiện chưa phản ánh đúng phạm vi (ví dụ: status đã đổi, nhưng filter vẫn lấy status cũ)
* Grouping theo field không ổn định (nhiều giá trị trống/không chuẩn hoá)
### Cách xử lý
* Kiểm tra field type và chuẩn hoá dữ liệu
* Đối chiếu bằng một view lọc cùng điều kiện để kiểm tra số record
* Chuẩn hoá status/select trước khi nhóm
Liên quan: [Ma trận kiểu trường (Field types matrix)](/reference/field-type-matrix)
***
## 3) Report theo thời gian bị lệch
### Nguyên nhân thường gặp
* Dùng nhầm field thời gian (Created at vs Scheduled at)
* Field là Date nhưng kỳ vọng Datetime (hoặc ngược lại)
* Filter “today/this week” phụ thuộc timezone
### Cách xử lý
* Chốt một field thời gian “chuẩn” cho từng chỉ số
* Nếu đo SLA/cycle time: ưu tiên Datetime và có timestamp rõ ràng (Verified at, Scheduled at…)
* Đối chiếu bằng dữ liệu mẫu trong một khoảng nhỏ để kiểm tra
***
## 4) Không chia sẻ được report hoặc người khác không thấy report
### Nguyên nhân thường gặp
* Report chưa publish/chia sẻ đúng phạm vi
* Người xem thiếu quyền xem report hoặc thiếu quyền xem dữ liệu nguồn
### Cách xử lý
* Kiểm tra cấu hình chia sẻ report
* Kiểm tra quyền trên dữ liệu nguồn
* Thử chia sẻ với một nhóm nhỏ để kiểm tra trước
Liên quan: [Chia sẻ & phân quyền (Sharing & permissions)](/build-apps/analytics-hub/sharing-permissions)
***
## 5) Debug nhanh bằng “report tối thiểu”
Khi report phức tạp khó debug:
1. Tạo report mới chỉ có **1 metric** và **không filter**
2. Thêm từng filter một để xác định filter nào làm sai số
3. Thêm grouping sau cùng
# Liên kết dữ liệu (Data connections)
Source: https://learn.cleeksy.com/troubleshooting/data-connections
Khắc phục lỗi Data Connection, Lookup, Rollup và publish/consume.
Trang này tập trung vào lỗi liên quan đến:
* **Publish/Consume (chia sẻ dữ liệu)** giữa các app
* **Data Connection** (một chiều/hai chiều)
* **Lookup** và **Rollup**
Liên quan:
* [Chia sẻ dữ liệu (Publish/Consume)](/reference/publish-consume)
* [Kết nối dữ liệu một chiều (Data Connection one-way)](/build-apps/data-modeling/data-connection-one-way)
***
## Checklist nhanh (khi “không thấy dữ liệu”)
1. Xác định liên kết trong **cùng app** hay **giữa các app**.
2. Nếu giữa các app: kiểm tra app nguồn đã **publish dữ liệu chia sẻ** và chia sẻ qua **Data source loại Connected app**.
3. Ở app đích: khi tạo field Data Connection/Lookup/Rollup, chọn đúng **data source** hoặc **dữ liệu chia sẻ**.
4. Kiểm tra quyền xem dữ liệu nguồn (role/visibility).
5. Kiểm tra record đã được liên kết chưa (Data Connection không rỗng).
***
## 1) Không chọn được data source/dữ liệu chia sẻ
### Nguyên nhân thường gặp
* Provider app chưa publish dữ liệu chia sẻ
* Provider app chưa chia sẻ dữ liệu chia sẻ qua data source loại Connected app
* Thiếu quyền dùng data source hoặc thiếu quyền xem dữ liệu nguồn
### Cách xử lý
* Nhờ builder/provider:
* publish dữ liệu chia sẻ đúng entity
* chỉ chia sẻ các field cần thiết
* bật chia sẻ qua Connected app
* Nhờ admin kiểm tra quyền ở app nguồn và app đích
***
## 2) Field liên kết hiển thị trống hoặc không chọn được dữ liệu
Các field type **Data Connection**, **Lookup** và **Rollup** sử dụng **data source (cổng dữ liệu)** do app nguồn (provider) chia sẻ, hoặc do hệ thống ngoài cung cấp (Webhook/API). Nếu cấu hình đúng mà vẫn “trống”, thường do **phạm vi dữ liệu** hoặc **điều kiện lọc**.
### Triệu chứng thường gặp
* Data Connection không tìm thấy record để chọn, hoặc danh sách trống
* Lookup trả về trống dù đã chọn đúng field cần hiển thị
* Rollup trả về 0/trống dù kỳ vọng có dữ liệu
### Nguyên nhân thường gặp
* Chọn sai **data source** hoặc **dữ liệu chia sẻ** khi tạo field
* **Filter/điều kiện** ở data source làm dữ liệu bị loại bỏ
### Cách xử lý
* Kiểm tra lại field:
* Data Connection/Lookup/Rollup đang trỏ tới **đúng data source** hay không
* Field cần tham chiếu/tổng hợp có nằm trong tập field được chia sẻ không
* Tạm thời nới filter (hoặc bỏ filter) để kiểm tra dữ liệu có xuất hiện không
Liên quan: [Chia sẻ dữ liệu (Publish/Consume)](/reference/publish-consume)
## 3) Dữ liệu “không cập nhật” như kỳ vọng
### Nguyên nhân thường gặp
* Hiểu nhầm giữa “tham chiếu” và “sao chép”
* Data Connection/Lookup/Rollup là **liên kết** và **hiển thị/tổng hợp** theo dữ liệu nguồn; không tạo bản sao dữ liệu
### Cách xử lý
* Nếu cần dữ liệu “được chốt” tại thời điểm nào đó (snapshot): cân nhắc lưu riêng vào field khác theo quy tắc vận hành (builder quyết định)
* Nếu cần luôn đúng theo nguồn: dùng Lookup/Rollup thay vì nhập lại
***
## 4) Nhầm one-way vs two-way
### Dấu hiệu
* Hai bên sửa và “đè” lên nhau
* Trạng thái giữa hai app bị khó kiểm soát
### Gợi ý xử lý
* Bắt đầu bằng **one-way** để giữ ownership rõ
* Chỉ dùng **two-way** khi đã xác định rõ:
* bên nào là nguồn chuẩn của từng field
* khi nào đồng bộ
* ai được phép thay đổi
Liên quan: [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)
***
## 5) Thu thập thông tin khi cần hỗ trợ
* App nguồn/app đích là gì?
* dữ liệu chia sẻ nào được publish?
* Field Data Connection/Lookup/Rollup cấu hình trỏ tới đâu?
* Role của người dùng đang gặp lỗi
* Ảnh chụp cấu hình field và data source
# Tích hợp (Integrations)
Source: https://learn.cleeksy.com/troubleshooting/integrations
Khắc phục lỗi tích hợp và các cổng dữ liệu.
Trang này tổng hợp lỗi phổ biến khi cấu hình và vận hành:
* Internal/Public portal
* Webhook portal
* API portal
* Connected app (kết nối giữa các app)
Liên quan:
* [Các loại cổng dữ liệu (Data source types)](/reference/data-source-types)
* [Bảo mật (Security)](/build-apps/integrations/security-tokens)
***
## Checklist nhanh
1. Đúng loại data source chưa? (portal/webhook/API/connected app)
2. Token/credentials đúng và còn hiệu lực không?
3. Payload/request có đủ field bắt buộc không?
4. Có lỗi quyền (permissions) ở entity/field không?
5. Có log/response để đối chiếu không?
***
***
## 2) Webhook: nhận 401/403/timeout
### Nguyên nhân thường gặp
* Token sai/hết hạn
* URL endpoint sai hoặc bị chặn bởi mạng/proxy
* Timeout do payload lớn hoặc hệ thống ngoài retry không đúng
### Cách xử lý
* Xác nhận token và endpoint
* Giảm payload về mức tối thiểu cần thiết
* Thiết kế retry có idempotency ở mức dữ liệu (tránh tạo trùng)
Liên quan: [Webhook portal (cổng webhook)](/build-apps/integrations/webhook-portal)
***
## 3) API: gọi được nhưng dữ liệu “không đúng”
### Nguyên nhân thường gặp
* Filter/parameter sai
* Quyền xem dữ liệu bị giới hạn theo role/visibility
* Endpoint thao tác nhầm entity/field
### Cách xử lý
* Thử gọi API với phạm vi nhỏ (1 record) để đối chiếu
* Kiểm tra quyền và điều kiện hiển thị record
* Kiểm tra mapping field type (date/number)
Liên quan: [API portal (cổng API)](/build-apps/integrations/api-portal)
***
## 4) Connected app: không thấy data source để chọn
### Nguyên nhân thường gặp
* App nguồn chưa publish data source hoặc chưa chia sẻ cho consuming app
* Chưa cấu hình đúng cơ chế chia sẻ dữ liệu
### Cách xử lý
* Xem checklist tại: [Liên kết dữ liệu (Data connections)](/troubleshooting/data-connections)
* Tra cứu cơ chế tại: [Chia sẻ dữ liệu (Publish/Consume)](/reference/publish-consume)
***
## Chuẩn bị thông tin khi cần hỗ trợ
* Loại data source và tên data source
* Entity/field mapping
* Mã lỗi/HTTP status và response (nếu có)
* Ảnh chụp cấu hình token (che phần nhạy cảm)
* Thời điểm lỗi và request mẫu
# Đăng nhập/đăng ký (Login/signup)
Source: https://learn.cleeksy.com/troubleshooting/login-signup
Khắc phục sự cố đăng nhập và tạo tài khoản.
Trang này tổng hợp các lỗi phổ biến khi đăng nhập/đăng ký và cách xử lý nhanh theo checklist.
***
## Checklist nhanh
1. Xác nhận email đăng nhập đúng (không thừa khoảng trắng, đúng tên miền).
2. Thử đặt lại mật khẩu nếu không chắc mật khẩu hiện tại.
3. Kiểm tra email xác minh/invite (nếu mới được mời vào workspace/app).
4. Thử đăng nhập ở cửa sổ ẩn danh hoặc trình duyệt khác để loại trừ cache/cookie.
5. Nếu dùng mạng công ty: thử đổi mạng hoặc tắt proxy/VPN để kiểm tra.
***
## 1) Không đăng nhập được
### Triệu chứng
* Báo sai email/mật khẩu
* Đăng nhập xong nhưng quay lại màn hình đăng nhập
* Báo lỗi chung (không rõ nguyên nhân)
### Nguyên nhân thường gặp
* Nhập sai email/mật khẩu hoặc email khác với email đã đăng ký
* Trình duyệt chặn cookie hoặc extension chặn script
* Phiên đăng nhập cũ bị lỗi (cache/cookie)
### Cách xử lý
* Dùng **Forgot password** để đặt lại mật khẩu
* Xoá cookie/site data của cleeksy, hoặc thử ẩn danh
* Tắt tạm extension chặn quảng cáo/script, thử lại
***
## 2) Không nhận được email xác minh / email đặt lại mật khẩu
### Checklist
* Kiểm tra thư mục Spam/Promotion
* Tìm theo từ khoá: “Cleeksy”, “verify”, “reset”
* Đợi vài phút và thử gửi lại
### Nếu vẫn không có
* Xác nhận email nhập đúng chính tả
* Nếu dùng email doanh nghiệp: có thể bị chặn bởi chính sách (cần IT cho phép)
***
## 3) Không vào được workspace hoặc app sau khi đăng nhập
### Triệu chứng
* Đăng nhập thành công nhưng không thấy workspace/app
* Bị báo “no access” / “permission denied”
### Nguyên nhân thường gặp
* Chưa được mời vào workspace/app
* Invite đã hết hạn hoặc gửi nhầm email
* Được mời nhưng chưa gán role phù hợp trong app
### Cách xử lý
* Yêu cầu admin gửi lại invite đúng email
* Xác nhận đã join đúng workspace
* Nếu đã vào được app nhưng “không thấy dữ liệu”: xem [Quyền & truy cập (Permissions & access)](/troubleshooting/permissions-access)
***
## 4) Chuẩn bị thông tin để hỗ trợ nhanh
Nếu cần gửi cho admin/hỗ trợ:
* Email đăng nhập
* Thời điểm lỗi xảy ra
* Ảnh chụp màn hình lỗi
* Trình duyệt + phiên bản (Chrome/Safari/Edge…)
# Thông báo & giao việc
Source: https://learn.cleeksy.com/troubleshooting/notifications-tasks
Khắc phục lỗi thông báo và giao việc.
Trang này giúp xử lý các vấn đề phổ biến liên quan đến **inbox notifications** và **tasks** (tác vụ) trong Cleeksy DOP.
Liên quan:
* [Thông báo & giao việc](/build-apps/notifications-tasks)
* [quy trình & tự động hoá (Workflows & automation)](/troubleshooting/workflows-automation)
***
## Checklist nhanh
1. Thông báo đến từ **built-in** hay từ **automation rules**?
2. Người dùng có phải là **assignee/approver/CC** của bước workflow không?
3. Record có vừa vào step kích hoạt task không?
4. Người dùng có quyền xem record không? (thiếu quyền = không thấy task/notification như kỳ vọng)
5. Có rule gửi lặp (loop) hoặc điều kiện quá rộng không?
***
## 1) Không nhận được thông báo khi có việc mới
### Nguyên nhân thường gặp
* Record chưa vào đúng step tạo task (workflow chưa kích hoạt)
* Không được gán là người phụ trách (assignee) hoặc không nằm trong role được gán
* Notification chỉ gửi cho một nhóm/role khác
* Người dùng không có quyền xem record nên “có việc nhưng không thấy”
### Cách xử lý
* Mở record và kiểm tra:
* status hiện tại
* step hiện tại (nếu có)
* assignee/approver/CC
* Nhờ builder kiểm tra cấu hình assignment ở step
* Kiểm tra quyền: [Quyền & truy cập (Permissions & access)](/troubleshooting/permissions-access)
***
## 2) Có task nhưng mở ra không thao tác được
### Nguyên nhân thường gặp
* Role chỉ có quyền xem
* Field cần nhập bị bắt buộc nhưng không hiển thị trong record layout
* Record đang ở trạng thái khác với bước hiện tại (step đã đổi)
### Cách xử lý
* Kiểm tra role và quyền sửa
* Kiểm tra record layout có đủ field bắt buộc không
* Nếu workflow đang chạy: kiểm tra record có đúng step được gán không
Liên quan: [giao diện (Views & UI)](/troubleshooting/views-ui)
***
## 3) Nhận quá nhiều thông báo (spam)
### Nguyên nhân thường gặp
* Automation rule gửi thông báo mỗi lần record được cập nhật (quá rộng)
* Rule tự kích hoạt lại chính nó (loop) do cập nhật field
* Có nhiều rule trùng nhau cho cùng một sự kiện
### Cách xử lý
* Tách bạch rule “cập nhật dữ liệu” và rule “gửi thông báo”
* Thêm điều kiện chặn (ví dụ chỉ gửi khi status **vừa đổi**)
* Giới hạn đối tượng nhận (PIC/Approver thay vì “tất cả”)
* Với email: chỉ gửi cho các mốc quan trọng (approve/reject/quá hạn)
Liên quan:
* [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules)
* [quy trình & tự động hoá (Workflows & automation)](/troubleshooting/workflows-automation)
***
## 4) Chuẩn bị thông tin để debug nhanh
* App + entity + record mẫu
* Người dùng gặp lỗi + role hiện tại
* Step/assignment của workflow (nếu có)
* Rule nào gửi notification (tên rule + điều kiện)
# Quyền & truy cập (Permissions & access)
Source: https://learn.cleeksy.com/troubleshooting/permissions-access
Khắc phục lỗi không thấy dữ liệu hoặc không thao tác được.
Trang này giúp xử lý các lỗi “không thấy/không sửa/không chạy được” bằng cách kiểm tra quyền theo thứ tự.
***
## Checklist nhanh (theo thứ tự)
1. Người dùng đã được mời vào **app** chưa?
2. Role trong app có đúng không?
3. View có bị ẩn theo role không?
4. Record visibility có giới hạn theo điều kiện không?
5. Workflow/step có yêu cầu role cụ thể không?
6. Data source (cổng dữ liệu) có bị giới hạn quyền dùng không?
Liên quan: [Mô hình phân quyền (Permissions model)](/reference/permissions-model-public)
***
## 1) Không thấy app hoặc không vào được app
### Nguyên nhân thường gặp
* Chưa được mời vào app
* Invite gửi sai email
### Cách xử lý
* Nhờ admin kiểm tra danh sách members và gửi lại invite
* Xác nhận đăng nhập đúng email
***
## 2) Thấy app nhưng không thấy entity/view/record
### Nguyên nhân thường gặp
* View bị ẩn theo role
* Record visibility đang áp dụng **quyền truy cập giới hạn** theo điều kiện (ví dụ: theo người tạo, theo phòng ban hoặc theo vai trò).
* Filter mặc định trong view đang chặn dữ liệu
### Cách xử lý
* Thử chuyển sang view khác (nếu có)
* Nhờ builder kiểm tra:
* quyền xem entity
* điều kiện hiển thị record
* filter trên view
Liên quan: [giao diện (Views & UI)](/troubleshooting/views-ui)
***
## 3) Thấy dữ liệu nhưng không sửa được / không tạo record
### Nguyên nhân thường gặp
* Role chỉ có quyền xem
* Field bị khoá theo trạng thái (status) hoặc theo bước workflow
* Validation yêu cầu field bắt buộc nhưng UI không hiển thị rõ
### Cách xử lý
* Kiểm tra role của người dùng
* Kiểm tra field bắt buộc trong entity
* Nếu có workflow: kiểm tra record đang ở bước nào
***
## 4) Không chạy được workflow hoặc không chuyển trạng thái được
### Nguyên nhân thường gặp
* Người dùng không phải người được gán (assignee) của step
* Step yêu cầu role khác
* Điều kiện vào bước (entry condition) không thoả
### Cách xử lý
* Kiểm tra assignee và role của step
* Kiểm tra status/field điều kiện
* Xem hướng dẫn tại: [quy trình & tự động hoá (Workflows & automation)](/troubleshooting/workflows-automation)
***
## 5) Không chọn được data source khi cấu hình liên kết dữ liệu
### Nguyên nhân thường gặp
* App nguồn chưa chia sẻ dataset đúng cách
* Người dùng/builder thiếu quyền dùng data source
* Data source không thuộc phạm vi workspace/app hiện tại
### Cách xử lý
* Kiểm tra publish/consume và quyền
* Xem checklist tại: [Liên kết dữ liệu (Data connections)](/troubleshooting/data-connections)
# giao diện (Views & UI)
Source: https://learn.cleeksy.com/troubleshooting/views-ui
Khắc phục lỗi hiển thị và cấu hình view/record layout.
Trang này tổng hợp lỗi phổ biến khi dùng **views** và **record layout**.
Liên quan:
* [Tổng quan giao diện](/build-apps/ui-views/views-overview)
* [Bố cục bản ghi (Record layout)](/build-apps/ui-views/record-layout)
***
## Checklist nhanh
1. Người dùng có quyền xem entity/field không?
2. View có filter mặc định đang chặn dữ liệu không?
3. Field có bị ẩn trong view/record layout không?
4. Với Kanban/Gantt: field dùng để group/timeline có đúng kiểu dữ liệu không?
***
## 1) Grid view không thấy field
### Nguyên nhân thường gặp
* Field chưa được thêm vào view
* Field bị ẩn theo role
* Field thuộc section khác trong record layout (nhưng chưa đưa vào grid)
### Cách xử lý
* Builder thêm field vào view
* Kiểm tra quyền xem field theo role
***
## 2) Kanban view không nhóm đúng
### Nguyên nhân thường gặp
* Kanban chỉ hỗ trợ group theo **Status** (trạng thái theo bước workflow). Nếu chọn field khác (ví dụ Single select), hệ thống chưa hỗ trợ group theo field đó.
* Giá trị **Status** chưa chuẩn hoá (trống hoặc sai) nên cột Kanban không hiển thị đúng.
### Cách xử lý
* Đảm bảo entity có field **Status** và workflow đang dùng Status đó để điều phối bước.
* Chuẩn hoá dữ liệu Status (bổ sung giá trị còn thiếu, tránh để trống).
* Nếu cần phân loại phụ, dùng Single select để lọc/hiển thị trong grid hoặc record layout (Kanban chưa hỗ trợ group theo Single select).
***
## 3) Gantt view không hiển thị hoặc lệch thời gian
### Nguyên nhân thường gặp
* Field timeline không phải Date/Datetime
* Thiếu start/end hoặc thiếu scheduled date/time
* Quyền xem field thời gian bị chặn
### Cách xử lý
* Đảm bảo timeline dùng Date/Datetime
* Kiểm tra dữ liệu thời gian có bị trống không
***
## 4) Record layout hiển thị “lạ” hoặc không lưu
### Nguyên nhân thường gặp
* Field bắt buộc nhưng không hiển thị trong layout
* Validation yêu cầu format nhưng người dùng nhập sai
* Trình duyệt cache layout cũ
### Cách xử lý
* Builder đảm bảo các field bắt buộc xuất hiện trong layout
* Người dùng thử refresh mạnh hoặc đăng nhập lại
***
## 5) View chậm hoặc khó dùng
Gợi ý tối thiểu:
* Giảm số field hiển thị trong grid
* Tách view theo mục tiêu (queue theo trạng thái/role)
* Dùng filter để giảm khối lượng dữ liệu hiển thị
# quy trình & tự động hoá (Workflows & automation)
Source: https://learn.cleeksy.com/troubleshooting/workflows-automation
Khắc phục lỗi workflow, approvals và automation rules.
Trang này tập trung vào lỗi khi cấu hình/ vận hành workflow:
* Process Builder (quy trình)
* Approvals (phê duyệt)
* Automation rules (tự động hoá)
* Notifications/Tasks (thông báo & giao việc)
Liên quan:
* [Thiết kế quy trình (Process Builder)](/build-apps/workflows/process-builder)
* [Phê duyệt (Approvals)](/build-apps/workflows/approvals)
* [Luật tự động (Automation rules)](/build-apps/workflows/automation-rules)
* [Thông báo & giao việc](/build-apps/notifications-tasks)
***
## Checklist nhanh
1. Record đang ở **đúng status** để vào step chưa?
2. Điều kiện entry/trigger có thoả không?
3. Người phụ trách (assignee) có được gán đúng không?
4. Người dùng hiện tại có đúng role/permission không?
5. Automation rules có điều kiện chặn vòng lặp chưa?
***
## 1) Workflow không kích hoạt
### Nguyên nhân thường gặp
* Record chưa vào đúng trạng thái đầu vào
* Điều kiện entry dựa trên field nhưng field đang trống/khác giá trị
* Step bị giới hạn theo role
### Cách xử lý
* Kiểm tra status hiện tại của record
* Kiểm tra các field điều kiện
* Thử tạo record mới với dữ liệu “đúng chuẩn” để kiểm tra
***
## 2) Không giao được người phụ trách / không tạo task
### Nguyên nhân thường gặp
* Field User/People trống hoặc rule gán không thoả
* Role không có người dùng nào được gán
* Step cấu hình assignee sai
### Cách xử lý
* Kiểm tra assignee theo rule hoặc theo field
* Kiểm tra danh sách users trong role liên quan
***
## 3) Approval không đến người duyệt
### Nguyên nhân thường gặp
* Approver không được gán hoặc bị thiếu quyền
* Record không vào đúng step approval
* Notification bị tắt theo cấu hình
### Cách xử lý
* Kiểm tra approver/role
* Kiểm tra inbox/task của approver
***
## 4) Automation rules gây spam hoặc chạy lặp
### Nguyên nhân thường gặp
* Rule cập nhật field làm thoả điều kiện chính nó
* Thiếu điều kiện chặn (ví dụ chỉ chạy khi status vừa đổi)
### Cách xử lý
* Thêm điều kiện chặn theo trạng thái trước/sau
* Tách rule thành “cập nhật dữ liệu” và “gửi thông báo”
* Chỉ gửi thông báo theo sự kiện quan trọng
***
## 5) Debug bằng dữ liệu tối thiểu
Khi khó tái hiện:
* Tạo 1 record mẫu với dữ liệu tối thiểu
* Chạy từng bước theo scenario
* Ghi lại: status, assignee, timestamp, rule nào đã chạy
Liên quan: [Rà soát & vận hành (App review)](/build-apps/app-review)