> ## 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.

# Kết nối dữ liệu hai chiều (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)