KB-5FD8

GPT S176 — Lark mechanisms report

29 min read Revision 1

s176larkfeishubitableresearchreportautomationlookupsync-tablelink-field

Báo cáo nghiên cứu kỹ thuật — 4 cơ chế liên kết dữ liệu của Lark Base (Bitable)

Người thực hiện: Incomex Hội đồng AI / GPT
Ngày: 2026-04-11
Phạm vi: Link field, Sync table, Lookup field, Automation/Workflow
Mục tiêu: xác định cơ chế, OpenAPI đọc được gì, phần nào phải bù bằng UI/Computer Use

Mức độ chắc chắn

Đã xác nhận bằng docs chính thức / endpoint docs / help center chính thức: endpoint tồn tại, tên resource, một số field type, một số cấu trúc dữ liệu record, một số giới hạn chức năng.

Chưa thể xác nhận tuyệt đối chỉ bằng docs public trong phiên này: toàn bộ response example JSON cho mọi endpoint, toàn bộ field trong payload workflow/list fields, metadata nội bộ của sync table, execution log automation, source code script action.

Nguyên nhân: một phần trang docs chính thức của Lark/Feishu render động; công cụ duyệt web trong phiên này lấy được search snippet tốt hơn là full HTML body.

Hệ quả: những chỗ chưa có bằng chứng đầy đủ được đánh dấu rõ là cần verify bằng thử API thật hoặc cần đọc UI.

Cơ chế 1: Link field (liên kết trong cùng Base)

1. Bản chất

Theo tài liệu Help Center chính thức của Lark Base, Base hỗ trợ ít nhất hai loại liên kết người dùng nhìn thấy trong UI: one-way link và two-way link. One-way link liên kết record từ bảng hiện tại sang record ở bảng khác trong cùng base; two-way link tạo quan hệ hai chiều để hai bảng cùng nhìn thấy dữ liệu liên kết. Trong tài liệu kiểu dữ liệu của Base Extension / Client API, các tên kỹ thuật tương ứng được lộ ra là SingleLink và DuplexLink.
Nguồn: official Help Center về one-way link / two-way link và FieldType enum của Base Extension.
Links: https://www.larksuite.com/hc/en-US/articles/360048488237-use-one-way-link-fields-in-base ; https://www.larksuite.com/hc/en-US/articles/360048488383-use-two-way-link-fields-in-base ; https://open.larksuite.com/document/uAjLw4CM/uYjL24iN/base-view-extensions/data-type/fieldtype

2. API endpoints liên quan

Endpoint	Method	Scope cần	Trả về gì
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/fields`	GET	field read scope của Bitable (docs endpoint tồn tại)	Danh sách field của bảng; dùng để nhận ra field liên kết qua `type`/`ui_type`/`property`
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records`	GET	record read scope của Bitable	Dữ liệu record; dùng để xem giá trị của link field trong từng record
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records/search`	POST	record read scope của Bitable	Truy vấn record có filter/sort, cũng dùng để kiểm tra cell link
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/fields/{field_id}`	PUT	field write scope	Update field; có thể dùng để test metadata property của link field nếu tenant test cho phép

3. Data fields trong response

3.1. Các field đã xác nhận chắc chắn trên `list fields`

Field path	Type	Ý nghĩa	Bắt buộc
`data.items[]`	array	Danh sách field	Y
`data.items[].field_id`	string	ID field	Y
`data.items[].field_name`	string	Tên field	Y
`data.items[].type`	integer	Numeric field type	Y
`data.items[].ui_type`	string	Tên field type ở tầng UI/API model	Y
`data.items[].description`	string	Mô tả field	N
`data.items[].property`	object	Metadata riêng theo từng field type	N

3.2. Field type number đã xác nhận

Field type name	Type number	Ghi chú
`SingleLink`	`18`	one-way association
`Lookup`	`19`	lookup reference
`Formula`	`20`	công thức
`DuplexLink`	`21`	bidirectional association

3.3. Property của link field

Các docs public/snippet trong phiên này xác nhận có property, nhưng không lộ đầy đủ bảng field của property trong HTML snippet. Các field như table_id, field_id, multiple, is_reverse là nhóm field rất đáng kiểm thử, nhưng trong phiên này tôi chưa có bằng chứng chính thức đủ mạnh để khẳng định từng tên field đều xuất hiện đúng nguyên văn trong response public docs. Vì vậy phần này phải đánh dấu cần verify bằng thử API thật.

3.4. Dữ liệu link trong record

Tài liệu “Base record data structure” của Feishu xác nhận với double/bidirectional link thì giá trị record là một object; trong object đó có mảng string link_record_ids, dùng để chứa record ID liên kết. Tài liệu cùng trang cũng xác nhận có các kiểu SingleLink và DuplexLink trong record data structure overview.
=> Kết luận chắc nhất hiện có: ở tầng record payload, link không chỉ là text label; ít nhất với DuplexLink nó là object chứa mảng ID record. Với SingleLink, docs snippet không đủ để chốt 100% hình dạng object trong phiên này, nhưng khả năng rất cao là cũng đi theo hướng “record id based structure”, cần verify bằng API thật.

4. Sample response JSON thực tế

Trung thực: tôi chưa có tenant test trong phiên này để gọi live API và công cụ web không kéo được trọn JSON example từ doc render động. Vì vậy dưới đây là mẫu tối thiểu được neo theo cấu trúc chính thức đã xác nhận, nhưng vẫn cần verify bằng API thật trước khi dùng làm golden sample.

{
  "code": 0,
  "data": {
    "items": [
      {
        "field_id": "fldxxxxxxxx",
        "field_name": "Related Orders",
        "type": 21,
        "ui_type": "DuplexLink",
        "description": "",
        "property": {
          "_verify_with_live_api": true
        }
      }
    ]
  }
}

Ví dụ record value cho duplex link theo docs record structure:

{
  "fields": {
    "Related Orders": {
      "link_record_ids": ["reca", "recb"]
    }
  }
}

5. Cách trace / đọc metadata

Gọi list fields cho từng bảng.
Lọc các field có type = 18 hoặc type = 21, hoặc ui_type là SingleLink / DuplexLink.
Với từng field link, đọc property và thử map sang bảng đích. Trong tenant test cần kiểm tra đặc biệt các khóa như table_id, backlink field id, cờ multiple/reverse.
Gọi list records / search records để xem giá trị cell thực tế. Lấy các link_record_ids rồi join ngược sang bảng đích theo record_id.
Để phân biệt field gốc với field phản chiếu của cùng một quan hệ hai chiều, cần kết hợp hai tín hiệu:
- metadata property của hai field DuplexLink tương ứng;
- hướng xuất hiện trong UI: field gốc là field người dùng tạo trước, field phản chiếu xuất hiện kèm ở bảng còn lại.
Với API public hiện nhìn thấy trong docs, không có bằng chứng chắc chắn rằng một call duy nhất sẽ cho bạn cả hai đầu quan hệ hai chiều dưới dạng fully-expanded relation object. Cách làm an toàn là dump field metadata của cả hai bảng rồi merge theo cặp.

6. Giới hạn

Đọc được qua API:

Có thể phát hiện field liên kết trong schema dump qua list fields.
Có thể biết numeric type của liên kết: 18 = SingleLink, 21 = DuplexLink.
Có thể đọc giá trị liên kết ở tầng record và ít nhất với duplex link thì docs xác nhận có link_record_ids.

KHÔNG đọc chắc chắn được qua API public/docs trong phiên này:

Full property schema của link field — cách bù: tenant test + gọi list fields/get field rồi lưu raw JSON.
Quy tắc phân biệt field gốc vs field phản chiếu chỉ bằng 1 field object — cách bù: dump cả hai bảng và đối chiếu UI.
Tất cả metadata quan hệ hai chiều trong một API call duy nhất — cách bù: merge kết quả nhiều call.

Ràng buộc sản phẩm:

Docs/help center nhất quán mô tả link là giữa các bảng trong cùng base; tài liệu sync giữa bases được tách thành tính năng khác. Vì vậy với yêu cầu cross-base, cơ chế thay thế chính thức không phải link field mà là sync data between bases / shared data source.

7. Link docs chính thức

Cơ chế 2: Sync table (bảng đồng bộ cross-base / external source sync)

1. Bản chất

Help Center chính thức của Lark/Feishu mô tả một nhóm tính năng riêng để đồng bộ dữ liệu vào Base thay vì link record trong cùng base. Có ít nhất các khái niệm người dùng nhìn thấy sau: Sync data between bases, Sync data from Sheets to Base, Sync Approval data to Base, Sync task lists to Base. Với “sync between bases”, dữ liệu từ base khác được đồng bộ vào các bảng ở base hiện tại để tập trung dữ liệu. Tài liệu Feishu còn nói rõ: bảng sync sau khi tạo thì không hỗ trợ sửa/edit dữ liệu đã sync, nhưng bạn có thể tạo field mới cục bộ, hoặc remove sync config để biến nó thành bảng thường.
=> Kết luận vận hành: “sync table” là bảng đích read-only cho phần dữ liệu nguồn, khác bản chất với link field.

2. API endpoints liên quan

Endpoint	Method	Scope cần	Trả về gì
`/open-apis/bitable/v1/apps/{app_token}/tables`	GET	table read scope	Liệt kê bảng; dùng để phát hiện bảng tồn tại nhưng không thấy docs public nói có sync_info
`/open-apis/bitable/v1/apps/{app_token}`	GET	app read scope	Metadata base; không có bằng chứng public cho sync graph
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/fields`	GET	field read scope	Schema của bảng sync sau khi đã materialize ở base đích
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records`	GET	record read scope	Dữ liệu hiện diện trong bảng sync

Điểm quan trọng: Base overview chính thức nói API hiện cung cấp 8 loại resource: Base App, Tables, Views, Records, Fields, Dashboards, Forms, Workflows. Trong danh sách resource công khai này không có resource riêng cho Sync Table / Sync Job / Sync Metadata. Vì vậy, ở mức public OpenAPI hiện thấy được, không có bằng chứng cho một endpoint chuyên đọc sync metadata như source_app_token, source_table_id, sync_type, last_sync_time, sync_status.

3. Data fields trong response

3.1. Table list / get — các field đã xác nhận chắc chắn qua snippet

Field path	Type	Ý nghĩa	Bắt buộc
`data.items[]`	array	Danh sách bảng	Y
`data.items[].table_id`	string	ID bảng	Y
`data.items[].revision`	integer/string	phiên bản bảng	Y
`data.items[].name`	string	tên bảng	Y

3.2. Sync metadata fields

Các field mà bạn muốn tìm như is_sync, source_app_token, source_table_id, sync_type, interval, last_sync_time, sync_status, error_log không tìm thấy bằng chứng chính thức trong docs public snippet của list tables / get app / overview trong phiên này.
=> Trạng thái nghiên cứu: chưa xác nhận có trong public API.

4. Sample response JSON thực tế

Mẫu tối thiểu của list tables, theo cấu trúc chính thức đã được doc search snippet xác nhận:

{
  "code": 0,
  "data": {
    "items": [
      {
        "table_id": "tblxxxxxxxx",
        "name": "Orders Sync",
        "revision": 12
      }
    ],
    "page_token": "",
    "has_more": false,
    "total": 1
  }
}

Lưu ý: JSON trên chỉ an toàn ở phần table_id / name / revision; các field pagination cần verify thêm bằng live API trước khi coi là golden sample.

5. Cách trace / đọc metadata

Dump list tables toàn bộ base.
Dump field schema + vài record mẫu của từng bảng.
Chạy heuristic để phát hiện bảng sync:
- bảng có dữ liệu nhưng write API thất bại / UI báo read-only;
- UI có menu “remove sync configuration” hoặc nhãn sync source;
- field set phản ánh nguồn ngoài (ví dụ Approval, Sheets, Task list) và có dấu hiệu không chỉnh trực tiếp được.
Nếu production có nghi ngờ là cross-base sync, mở UI góc trái dưới “Sync data from…”/“从其他数据源同步” để lấy upstream source.
Chụp ảnh hoặc trích raw HTML của dialog sync config vì public OpenAPI chưa lộ metadata này.

6. Giới hạn

Đọc được qua API:

Tên bảng, table_id, revision.
Schema đã materialize của bảng sync.
Record đã sync vào bảng đích.

KHÔNG đọc được qua API public/docs trong phiên này:

Cờ is_sync hay sync table metadata dedicated.
Upstream source cụ thể: source_app_token, source_table_id, source view.
Lịch sync: interval, auto/manual, last_sync_time, sync_status, error log.
Downstream graph: một bảng nguồn đang bị bao nhiêu bảng khác sync từ nó.
Field-level mapping: sync tất cả field hay subset nào.

Cách bù khả thi:

Computer Use / UI scrape: mở base → chọn bảng sync → vào sync settings / data source dialog.
Ảnh chụp + OCR nhẹ cho dialog cấu hình sync nếu cần lưu evidence.
Manual tenant test: tạo một sync table test rồi so sánh raw API trước/sau để xác định có flag ẩn nào xuất hiện ở list tables hay không.
Share link / admin side evidence: nếu workspace có audit/admin log cho sync changes thì đối chiếu thêm.

7. Link docs chính thức

Cơ chế 3: Lookup field (trong cùng Base, dựa trên link)

1. Bản chất

Help Center chính thức mô tả Lookup field là cách “nhanh chóng tìm và tham chiếu dữ liệu” mà không cần tự viết formula phức tạp. Về logic dữ liệu, lookup phụ thuộc vào một field liên kết: trước hết record hiện tại phải link sang record ở bảng khác, sau đó lookup mới lấy một field nào đó từ bảng đích về để hiển thị ở bảng hiện tại.
Ở tầng type system của Base Extension, Lookup có numeric type 19. Như vậy lookup là một field type riêng, không phải chỉ là “một cách hiển thị” của link field.

2. API endpoints liên quan

Endpoint	Method	Scope cần	Trả về gì
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/fields`	GET	field read scope	Dùng để xác định field `type = 19` / `ui_type = Lookup`
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records`	GET	record read scope	Xem giá trị lookup materialized trong record payload nếu API trả về
`/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records/search`	POST	record read scope	Kiểm tra giá trị lookup ở tập record có filter

3. Data fields trong response

3.1. Field schema đã xác nhận chắc chắn

Field path	Type	Ý nghĩa	Bắt buộc
`data.items[].field_id`	string	ID field	Y
`data.items[].field_name`	string	Tên field	Y
`data.items[].type`	integer	`19` cho Lookup	Y
`data.items[].ui_type`	string	`Lookup`	Y
`data.items[].property`	object	metadata lookup	N

3.2. Property của lookup

Trong phiên này tôi chưa lấy được bằng chứng chính thức nguyên văn cho các khóa như reference_link_field_id hay target_field_id từ public docs HTML. Tuy nhiên về mặt logic sản phẩm, muốn trace lookup thì tối thiểu phải có thông tin tương đương với:

field link nguồn là gì;
field đích được lookup là gì.

=> Kết luận thực dụng: cần verify live API để chốt tên khóa chính xác trong property.

4. Sample response JSON thực tế

{
  "code": 0,
  "data": {
    "items": [
      {
        "field_id": "fld_lookup_xxx",
        "field_name": "Customer Tier (lookup)",
        "type": 19,
        "ui_type": "Lookup",
        "property": {
          "_verify_with_live_api": true
        }
      }
    ]
  }
}

5. Cách trace / đọc metadata

Trong list fields của bảng A, tìm field có type = 19.
Đọc property của field lookup để lấy field link nguồn (cần verify key name).
Từ field link nguồn, truy tiếp field schema của chính bảng A để biết nó trỏ sang bảng nào.
Sang bảng đích B, tìm target field được lookup.
Nếu production có “lookup của lookup”, kiểm tra field đích W ở bảng B xem W có phải lại là type = 19 hay không. Nếu có, chain trace tiếp.
Trong dump tool, nên model lookup bằng đồ thị: lookup_field -> source_link_field -> target_table -> target_field.

6. Giới hạn

Đọc được qua API:

Có thể nhận ra lookup là field type riêng (19, Lookup).
Có thể dump schema lookup field ở tầng field list.

KHÔNG đọc chắc chắn được qua API public/docs trong phiên này:

Tên chính xác của mọi key trong property lookup.
Lookup chain có được biểu diễn đầy đủ trong một object hay phải lần theo nhiều field.
Lookup value được API trả về dưới dạng text, array hay computed object cho mọi subtype.
“compute-on-read” hay materialized cache — docs public tôi thấy không nêu rõ.

Phân biệt khái niệm:

Lookup: lấy giá trị field từ record đã link.
Rollup: là khái niệm khác, thường là tổng hợp/aggregate trên tập record liên kết; trong phiên này tôi không có snippet official đủ tốt để chốt type number của Rollup.
Formula: field type riêng, type number 20 theo FieldType doc; không nên trộn với Lookup.
=> Vì vậy khi dump schema, ít nhất phải tách ba nhóm: Lookup, Formula, và các field aggregate/rollup nếu có.

7. Link docs chính thức

Cơ chế 4: Automation / Workflow (quan trọng nhất)

1. Bản chất

Ở lớp OpenAPI, tài liệu chính thức gọi resource này là Workflow; ví dụ endpoint là app-workflow/list và app-workflow/update. Ở lớp sản phẩm/UI và Help Center, Lark dùng cả hai cách gọi Workflow và Automation/Automations. Help Center còn nói rõ: Workflow là tính năng mở rộng từ Automation hiện có, cùng chung logic “khi trigger xảy ra thì thực hiện action”.
=> Khi nghiên cứu production, nên coi “automation” và “workflow” là hai tên của cùng family tính năng, nhưng khi gọi OpenAPI phải dùng danh pháp workflow.

2. API endpoints liên quan

Endpoint	Method	Scope cần	Trả về gì
`/open-apis/bitable/v1/apps/{app_token}/workflows`	GET	workflow read scope của Bitable	List automations / workflows để lấy `workflow_id` và metadata cơ bản
`/open-apis/bitable/v1/apps/{app_token}/workflows/{workflow_id}`	PUT	workflow write scope	Cập nhật trạng thái workflow; docs snippet xác nhận request body yêu cầu `status = Enable/Disable`

Điểm xác nhận quan trọng: official search snippet ghi rõ “You can obtain the ID of automated workflows, i.e., workflow_id, through the List automated workflows interface” và endpoint GET /bitable/v1/apps/:app_token/workflows tồn tại. Đây là bằng chứng rất mạnh rằng đã có public API ít nhất để liệt kê workflow, không còn ở trạng thái “không có API công khai” như các giai đoạn cũ.

3. Data fields trong response

3.1. Những gì đã xác nhận chắc chắn

Field path	Type	Ý nghĩa	Bắt buộc
`workflow_id`	string	ID workflow/automation	Y
`status` (request update)	string enum	`Enable` hoặc `Disable` khi cập nhật trạng thái	Y

3.2. Những field metadata bạn muốn có nhưng tôi chưa thể xác nhận bằng docs public snippet trong phiên này

name
trigger_type
conditions
actions[]
related_tables
created_by
last_run
enabled/disabled trong response list
execution statistics / error summary

=> Các field trên rất có thể có ít nhất một phần trong response list, nhưng trong phiên này tôi không có bằng chứng HTML/json đủ chắc để liệt kê như fact tuyệt đối. Cần verify bằng live API.

4. Sample response JSON thực tế

4.1. Request thật đã được docs snippet xác nhận cho update status

{
  "status": "Enable"
}

4.2. Response list — mẫu cần verify bằng live API

{
  "code": 0,
  "data": {
    "items": [
      {
        "workflow_id": "wkf_xxxxxxxx"
      }
    ]
  }
}

Lưu ý trung thực: tôi chỉ dám chốt chắc workflow_id và endpoint; phần còn lại của JSON response list cần tenant test hoặc docs body example đầy đủ hơn.

5. Cách trace / đọc metadata

Gọi GET /bitable/v1/apps/{app_token}/workflows cho từng base.
Thu toàn bộ workflow_id.
So sánh số workflow API trả về với số workflow nhìn thấy trong UI Automation/Workflow panel. Nếu lệch, chụp UI làm evidence vì có thể API không expose toàn bộ subtype.
Với từng workflow_id, thử các khả năng:
- có endpoint get/detail không được docs search index trả nổi không;
- nếu không có, dùng UI scrape để đọc trigger, conditions, actions.
Dùng PUT .../workflows/{workflow_id} với tenant test để xác minh workflow đó có đang được API quản lý thật hay chỉ expose control tối thiểu.
Xây data model dump tool theo hai tầng:
- API layer: workflow_id, status, base app_token;
- UI-enriched layer: trigger tree, condition tree, action tree, script/webhook configuration, related table/field references.

6. Giới hạn

Đọc được qua API:

Có public API để list workflows/automations.
Có public API để enable/disable workflow.
Có thể lấy workflow_id từ list API.

KHÔNG đọc chắc chắn được qua API public/docs trong phiên này:

Toàn bộ cấu trúc trigger/condition/action.
Execution logs / run history / fail reason timeline.
Script source code của script action.
Rich metadata như created_by, last_run, action node config.
Quota/limit per base/workspace từ OpenAPI docs.

Cách bù khả thi:

Computer Use mở UI: Base → Automation / Workflow → mở từng workflow → chụp toàn bộ trigger, condition, action.
Chụp từng node action nếu có nested config.
Workspace admin / audit log nếu enterprise có log workflow changes/runs.
Tenant test: tạo workflow nhỏ với từng trigger/action rồi so sánh API list trước/sau.

7. Trigger và action — trạng thái nghiên cứu thực tế

7.1. Điều đã xác nhận

Workflow/Automation của Base có cấu trúc trigger + actions theo Help Center chính thức.
Có official article riêng cho button click trigger.
Có official article riêng cho receiving Lark messages trigger.
Có official article riêng cho HTTP request action.
Có community article chính thức của Feishu cho thấy scheduled trigger trong automation được dùng thực tế.

7.2. Điều chưa nên khẳng định là danh sách đầy đủ nếu chưa verify thêm

Các trigger như field_changed, record_created, record_matched, checkbox_toggled, webhook, manual, scheduled, v.v. rất hợp lý và nhiều khả năng tồn tại, nhưng trong phiên này tôi không có một trang official duy nhất liệt kê full taxonomy đầy đủ ở dạng machine-readable. Do đó không nên đóng dấu “đầy đủ” cho danh sách trigger/action nếu chưa làm thêm bước UI inventory hoặc tenant test.

8. So sánh thực dụng về discoverability

Không bàn về “tốt/xấu”, nhưng có thể rút ra kết luận kỹ thuật sau:

Với Zapier/n8n, graph trigger-action thường là thực thể API/JSON khá lộ rõ.
Với Lark Base hiện tại, public discoverability của workflow graph vẫn thấp hơn: OpenAPI public mà tôi xác nhận chắc được hiện mới thấy rõ ở mức list workflow ID + update status, còn phần business logic chi tiết vẫn phải nhờ UI nhiều hơn.
=> Đây là lý do hợp lý để dump tool của production phải có nhánh API + nhánh Computer Use/UI capture cho automation.

9. Link docs chính thức

Kết luận chốt cho bài toán dump tool

A. 4 cơ chế nên chia thành 2 nhóm kỹ thuật

Nhóm A — dump được tương đối tốt bằng OpenAPI hiện tại:

Link field: dump được field type, record value, quan hệ cơ bản; cần merge nhiều call để hiểu full graph.
Lookup field: dump được field type; trace được dependency nếu property expose đủ; cần verify key names bằng tenant test.

Nhóm B — OpenAPI chưa đủ, bắt buộc phải có UI/Computer Use bổ trợ: 3. Sync table: public docs không cho thấy sync metadata resource riêng; API nhìn thấy bảng và dữ liệu đã sync, nhưng không lộ upstream config một cách chắc chắn. 4. Automation/Workflow: đã có API list workflow và update status, nhưng business logic chi tiết của workflow graph nhiều khả năng vẫn phải lấy từ UI.

B. Ưu tiên triển khai research tiếp theo

Tenant test nhỏ để chốt raw JSON của:
- SingleLink field
- DuplexLink field
- Lookup field
- Một sync table cross-base
- Một workflow đơn giản
Computer Use script cho production:
- mở từng Base
- đi vào từng bảng nghi là sync table
- mở Automation/Workflow panel
- screenshot + copy text từng workflow
Golden evidence archive: lưu raw JSON + screenshot vào KB để không phụ thuộc nhân sự cũ.

C. Kết luận rất thực dụng cho production hiện tại

Link / Lookup: có thể coi là “schema-discoverable” ở mức khá.
Sync table: là “data-visible nhưng metadata-poor” qua public API.
Automation/Workflow: là “ID-discoverable nhưng logic-poor” qua public API hiện xác nhận được.

Danh sách claim trọng yếu đã được xác nhận từ nguồn chính thức

Base public API hiện có 8 resource types: App, Tables, Views, Records, Fields, Dashboards, Forms, Workflows.
GET /bitable/v1/apps/:app_token/workflows tồn tại để list automations/workflows và lấy workflow_id.
PUT /bitable/v1/apps/:app_token/workflows/:workflow_id tồn tại để update status với body status = Enable/Disable.
Field type enum công khai ở Base Extension xác nhận SingleLink = 18, Lookup = 19, Formula = 20, DuplexLink = 21.
Record data structure docs xác nhận kiểu liên kết hai chiều dùng object với link_record_ids.
Help Center xác nhận one-way link và two-way link là hai khái niệm UI riêng.
Help Center xác nhận sync between bases là tính năng riêng; synced data table không cho sửa dữ liệu sync, nhưng có thể thêm field mới hoặc bỏ sync config để biến thành bảng thường.
Help Center xác nhận workflow/automation dùng mô hình trigger + action; có ít nhất button trigger, receiving messages trigger và HTTP request action trong docs công khai.

Ghi chú phương pháp

Ưu tiên dùng Open Platform docs và Help Center chính thức của Lark/Feishu.
Chỉ những gì có bằng chứng đủ mạnh trong phiên này mới được chốt là fact.
Những chỗ docs public chưa đủ chi tiết đã được đánh dấu rõ là cần verify bằng live API hoặc UI.

Báo cáo nghiên cứu kỹ thuật — 4 cơ chế liên kết dữ liệu của Lark Base (Bitable)

Cơ chế 1: Link field (liên kết trong cùng Base)

1. Bản chất

2. API endpoints liên quan

3. Data fields trong response

3.1. Các field đã xác nhận chắc chắn trên list fields

3.2. Field type number đã xác nhận

3.3. Property của link field

3.4. Dữ liệu link trong record

4. Sample response JSON thực tế

5. Cách trace / đọc metadata

6. Giới hạn

7. Link docs chính thức

Cơ chế 2: Sync table (bảng đồng bộ cross-base / external source sync)

1. Bản chất

2. API endpoints liên quan

3. Data fields trong response

3.1. Table list / get — các field đã xác nhận chắc chắn qua snippet

3.2. Sync metadata fields

4. Sample response JSON thực tế

5. Cách trace / đọc metadata

6. Giới hạn

7. Link docs chính thức

Cơ chế 3: Lookup field (trong cùng Base, dựa trên link)

1. Bản chất

2. API endpoints liên quan

3. Data fields trong response

3.1. Field schema đã xác nhận chắc chắn

3.2. Property của lookup

4. Sample response JSON thực tế

5. Cách trace / đọc metadata

6. Giới hạn

7. Link docs chính thức

Cơ chế 4: Automation / Workflow (quan trọng nhất)

1. Bản chất

2. API endpoints liên quan

3. Data fields trong response

3.1. Những gì đã xác nhận chắc chắn

3.2. Những field metadata bạn muốn có nhưng tôi chưa thể xác nhận bằng docs public snippet trong phiên này

4. Sample response JSON thực tế

4.1. Request thật đã được docs snippet xác nhận cho update status

4.2. Response list — mẫu cần verify bằng live API

5. Cách trace / đọc metadata

6. Giới hạn

7. Trigger và action — trạng thái nghiên cứu thực tế

7.1. Điều đã xác nhận

7.2. Điều chưa nên khẳng định là danh sách đầy đủ nếu chưa verify thêm

8. So sánh thực dụng về discoverability

9. Link docs chính thức

Kết luận chốt cho bài toán dump tool

A. 4 cơ chế nên chia thành 2 nhóm kỹ thuật

B. Ưu tiên triển khai research tiếp theo

C. Kết luận rất thực dụng cho production hiện tại

Danh sách claim trọng yếu đã được xác nhận từ nguồn chính thức

Ghi chú phương pháp

3.1. Các field đã xác nhận chắc chắn trên `list fields`