Tự động tạo field LarkBase bằng n8n: hết ngồi thêm cột bằng tay

TL;DR: Khi đổ dữ liệu từ nguồn lạ vào LarkBase, thay vì ngồi tạo từng cột, hãy để workflow tự làm: đọc danh sách field hiện có, so với key của dữ liệu mới, tìm ra field còn thiếu, suy ra kiểu rồi tạo hàng loạt. Chỉ tạo cái thiếu nên chạy lại nhiều lần vẫn an toàn.

Vấn đề: schema nguồn thay đổi liên tục

Dữ liệu từ API bên ngoài có hàng chục trường, đủ kiểu: chuỗi, số, ngày, mảng. Trước khi insert được vào LarkBase, bảng đích phải có sẵn cột tương ứng.

Làm tay thì hai chuyện xảy ra:

• Lần đầu dựng bảng: ngồi tạo ba bốn chục cột, chọn đúng kiểu cho từng cột. Mất buổi sáng.
• Mỗi lần nguồn thêm trường: workflow gãy, lại vào sửa tay. Và thường phát hiện ra vào lúc báo cáo thiếu số.

Việc này máy làm được, chỉ là ít người nghĩ tới.

Ý tưởng: dò field thiếu rồi tạo hàng loạt

Luồng gồm bốn bước, chạy trước bước insert dữ liệu:

Bước 1: Lấy danh sách field hiện có

Gọi API list field của bảng đích để biết bảng đang có những cột nào.

Bước 2: So khớp key

Đối chiếu key của dữ liệu mới với danh sách field. Key nào đã có thì bỏ qua, key nào chưa có thì đánh dấu là field thiếu.

Bước 3: Suy ra kiểu dữ liệu

Dựa vào giá trị mẫu để đoán kiểu: số, ngày, chuỗi, nhiều lựa chọn.

Bước 4: Tạo cột

Gọi API tạo field cho từng field thiếu, đúng kiểu vừa suy ra.

Sau bước này, bảng LarkBase tự có đủ cột khớp dữ liệu nguồn. Lúc đó mới insert.

Node Code cho bước 2 và 3:

// Field đang có trong bảng — lấy từ node gọi API list field
const existingNames = new Set(
  $('List field').all().map(i => i.json.field_name)
);

// Một bản ghi mẫu từ nguồn để suy ra kiểu
const sample = $input.first().json;

// Mã kiểu field của LarkBase: 1 = text, 2 = number, 5 = date
function guessFieldType(value) {
  if (typeof value === 'number') return 2;
  if (value instanceof Date) return 5;
  if (typeof value === 'string' && /^\d{4}-\d{2}-\d{2}/.test(value)) return 5;
  return 1; // mặc định về text — an toàn nhất
}

const missing = [];
for (const [key, value] of Object.entries(sample)) {
  if (existingNames.has(key)) continue;
  missing.push({
    json: { field_name: key, type: guessFieldType(value) },
  });
}

return missing;

Nối tiếp bằng node HTTP Request gọi API tạo field, chạy qua Loop Over Items để tạo từng cột.

Chỗ dễ sai nhất: suy ra kiểu

Phần guessFieldType là nơi hỏng nhiều nhất, và hỏng theo kiểu âm thầm.

Số lưu thành text thì cột đó không cộng được, dashboard ra 0. Ngày lưu thành chuỗi thì lọc theo khoảng thời gian không chạy. Cả hai lỗi này không báo gì cả — bảng vẫn đầy dữ liệu, chỉ là không dùng được.

⚠️ Warning: Kiểm vài bản ghi mẫu trước khi chạy cho cả lô. Đặc biệt cẩn thận với trường số dạng chuỗi ("1200") và ngày ở định dạng lạ. Khi phân vân, để về text rồi sửa tay một cột còn hơn để sai kiểu cả bảng — đổi kiểu field trên bảng đã có dữ liệu là việc rất khó chịu.

Bốn nguyên tắc an toàn

Chỉ tạo cái thiếu, không đụng cột có sẵn. Không xoá, không đổi kiểu, không ghi đè — nhất là những cột người dùng tự thêm tay. Nhờ vậy workflow idempotent: chạy lại lần thứ mười cũng không làm gì thêm.

Chạy thử trên bảng nháp trước. Đây là workflow sửa cấu trúc của bảng, không phải sửa dữ liệu. Chạy nhầm vào bảng đang dùng thật thì dọn rất mệt. Nhân bản một bảng nháp, chạy vào đó, nhìn kết quả rồi mới trỏ vào bảng thật.

Ghi log field đã tạo. Cho workflow bắn một tin về nhóm chat mỗi khi tạo cột mới. Vừa biết nguồn dữ liệu vừa đổi cái gì, vừa phát hiện sớm khi nguồn đẻ ra cột rác do lỗi phía họ.

Giữ tên key sạch và nhất quán. Tên key nguồn chính là tên cột. Nguồn đổi order_id thành orderId là workflow tạo thêm một cột mới bên cạnh cột cũ, và dữ liệu tách làm hai chỗ.

Khi nào nên dùng

Hợp lý khi schema nguồn hay thay đổi — API đối tác liên tục thêm trường — hoặc khi cần dựng bảng nhanh từ một nguồn lạ mà không muốn ngồi tạo cột thủ công.

Không cần thiết khi bảng đã cố định cột và ổn định lâu rồi. Lúc đó thêm cột là việc hiếm, làm tay còn nhanh hơn dựng workflow.

Có cột rồi thì bước tiếp theo thường là upsert dữ liệu vào LarkBase — nhớ xử lý phân trang khi đọc để không so khớp thiếu.

ℹ️ Info: Trước đây tôi dựng luồng này bằng AnyCross. Từ 2026 chuyển sang n8n vì tự host được, có log từng node để lần lỗi, và không tính tiền theo lượt chạy.

Tự làm mất bao lâu

Dòng cuối là lý do nên cân nhắc. Đây là workflow sửa cấu trúc bảng — nhóm việc mà sai thì không có nút hoàn tác, và thường chỉ phát hiện sau vài ngày khi báo cáo ra số lạ.