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

# Bản ghi (Record)

> 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)