Thiết kế thư mục tích hợp mở rộng từ 3 đến 30 ứng dụng

Những gì một màn hình tích hợp cần làm (nói dễ hiểu)

Mọi người mở thư mục tích hợp vì một lý do: để kết nối công cụ và giữ chúng hoạt động mà không phải nghĩ hàng ngày. Nếu màn hình khiến người dùng phải đoán cái gì đang kết nối, cái gì hỏng, hoặc phải bấm gì tiếp theo, niềm tin sẽ giảm rất nhanh.

Với 3 tích hợp, một lưới logo đơn giản có thể ổn. Với 30, cách đó sụp: người dùng ngừng quét, ticket hỗ trợ tăng, và nút “Connect” trở thành bẫy vì mỗi tích hợp có thể ở trạng thái khác nhau.

Mỗi thẻ tích hợp (hoặc hàng) nên trả lời ba câu hỏi trong nháy mắt:

• Đây là gì? (Tên kèm mục đích ngắn)
• Hiện tại có hoạt động không? (Trạng thái rõ ràng kèm lần kiểm tra hoặc đồng bộ gần nhất)
• Tôi làm gì tiếp theo? (Connect, tiếp tục thiết lập, re-auth, quản lý)

Phần lớn sự nhầm lẫn đến từ các trường hợp cạnh biên xảy ra liên tục trong đội thực tế. Ai đó kết nối Google bằng tài khoản cá nhân thay vì tài khoản công ty. Token Stripe hết hạn và việc đồng bộ hóa thanh toán dừng. Một workspace Slack được kết nối nhưng scope yêu cầu chưa được cấp, nên thiết lập “chưa xong” dù giao diện trông ổn.

Một màn hình tốt làm cho những tình huống đó hiển nhiên. Thay vì chỉ “Connected”, hãy hiển thị ví dụ “Connected (needs permission)” hoặc “Connected to: [email protected]”, và đặt bước tiếp theo ngay trên thẻ. Điều đó giữ người dùng khỏi phải đoán và giúp danh sách vẫn quản lý được khi nó lớn lên.

Một mô hình dữ liệu đơn giản: catalog vs installs vs connections

Cách đơn giản nhất để mở rộng thư mục tích hợp là tách:

• thứ bạn cung cấp (catalog)
• thứ mỗi workspace bật (installs)
• các tài khoản bên ngoài hoặc thông tin đăng nhập đang được dùng (connections)

Cách này vẫn dễ đọc ở 3 tích hợp và vẫn hiệu quả ở 30.

Ba đối tượng cốt lõi

Một Integration là mục trong catalog. Nó toàn cục, không ràng buộc vào workspace nào.

Một Install đại diện cho một workspace bật Integration đó (ví dụ: “Slack được bật cho Workspace A”).

Một Connection đại diện cho một tài khoản bên ngoài thực tế hoặc thông tin đăng nhập (ví dụ: “Slack workspace X qua OAuth” hoặc “Stripe account Y bằng API key”). Một Install có thể có nhiều Connection.

Một tập trường tối thiểu thường mở rộng tốt:

• Integration: id, key ("slack"), display_name, category, auth_type (oauth/api_key/webhook), docs_hint (văn bản ngắn), created_at
• Install: id, workspace_id, integration_id, status (enabled/disabled), setup_state (not_started/in_progress/complete), created_by, created_at, updated_at
• Connection: id, install_id, label ("Marketing Slack"), connection_status (ok/expired/error), external_account_id (nếu biết), scopes/permissions_granted, last_success_at, created_at

Cấu hình vs bí mật (và gì không được rò rỉ)

Lưu cấu hình hiển thị cho người dùng (kênh được chọn, bí danh URL webhook, các event bật) trên Install hoặc Connection như dữ liệu thường. Lưu bí mật (refresh token OAuth, API key, signing secret) chỉ trong kho bí mật hoặc trường mã hóa với kiểm soát truy cập nghiêm ngặt.

Đừng đưa bí mật, mã ủy quyền đầy đủ, hoặc payload webhook thô vào logs. Nếu phải log, chỉ log tham chiếu (connection_id) và metadata an toàn (HTTP status, error code).

Để linh hoạt giữa OAuth, API key và webhook, đặt các trường liên quan đến auth trong Connection (metadata token vs dấu vân tay key vs trạng thái xác minh webhook). Giữ trạng thái hiển thị UI (enabled và tiến độ thiết lập) trên Install.

Trạng thái và tiến độ thiết lập mà người dùng hiểu được

Người ta mở thư mục tích hợp để nhanh trả lời ba điều: nó có hoạt động không, đã tiến bao xa trong thiết lập, và tôi phải làm gì tiếp theo. Nếu từ ngữ trạng thái mơ hồ, ticket hỗ trợ tăng và niềm tin giảm.

Bắt đầu với một tập trạng thái nhỏ mà bạn có thể giữ trong nhiều năm:

• Chưa thiết lập (Not set up)
• Đang tiến hành (In progress)
• Đã kết nối (Connected)
• Cần chú ý (Needs attention)
• Đã tắt (Disabled)

Ưu tiên trạng thái suy ra hơn trạng thái lưu. Nhãn lưu dễ bị lỗi thời: ai đó sửa xong lỗi nhưng badge vẫn đỏ. Trạng thái suy ra được tính từ các sự kiện bạn đã theo dõi, như token còn hợp lệ, các bước thiết lập bắt buộc đã xong, và admin có tạm dừng tích hợp hay không. Nếu bạn lưu gì đó, hãy lưu các sự kiện nền tảng (last successful sync, last error code), không lưu nhãn cuối cùng.

Tiến độ thiết lập hoạt động tốt nhất như một checklist ngắn, với sự phân tách rõ ràng giữa bắt buộc và tuỳ chọn. Mô hình hoá nó như định nghĩa bước (tĩnh, theo từng integration) cộng với kết quả bước (theo từng install).

Ví dụ: Slack có thể yêu cầu “Authorize workspace” và “Select channels”, với một bước tuỳ chọn như “Enable message previews.” UI có thể hiển thị “2 trong 3 bước bắt buộc hoàn thành” trong khi giữ các mục tuỳ chọn dễ tìm mà không chặn.

Nhiều connection dưới một integration có thể biến thư mục thành mớ lộn xộn nếu bạn không lên kế hoạch. Giữ một thẻ cho mỗi integration, hiển thị số lượng connection, và tổng hợp trạng thái một cách trung thực. Nếu bất kỳ connection nào hỏng, hiện “Needs attention” với gợi ý như “1 trong 4 workspace cần re-auth.” Tổng quan vẫn gọn, nhưng phản ánh thực tế.

Phân quyền và vai trò mà không làm phức tạp

Quyền tích hợp trở nên rắc rối khi mọi thứ bị coi như một công tắc duy nhất. Rõ ràng hơn khi tách:

• ai có thể xem một integration
• ai có thể cấu hình nó
• ai có thể sử dụng nó hàng ngày

Bắt đầu với một kiểm tra vai trò nhẹ áp dụng khắp nơi. Với nhiều app, ba vai trò là đủ: Admin, Manager và Member. Admin làm được mọi chuyện. Manager có thể thiết lập hầu hết tích hợp cho đội họ. Member có thể dùng những tích hợp đã bật nhưng không thể thay đổi cài đặt.

Rồi chỉ thêm các flag quyền theo từng integration khi thực sự cần. Hầu hết tích hợp (calendar, chat) có thể theo quy tắc vai trò mặc định. Những tích hợp nhạy cảm (payments, payroll, exports) nên yêu cầu kiểm tra thêm như “Payments admin” hoặc “Billing manager.” Giữ điều này như một boolean đơn giản trên install, đừng tạo cả hệ thống role mới.

Bản đồ dễ đọc:

• View: Admin, Manager, Member
• Configure: Admin, Manager (Member có thể xem nhưng không thể connect hoặc chỉnh)
• Use: Bất kỳ ai trong workspace sau khi bật (trừ khi bị giới hạn)
• Sensitive override: Chỉ người có flag cụ thể mới cấu hình hoặc kích hoạt hành động

Audit không cần quá nặng, nhưng nên tồn tại. Theo dõi đủ để trả lời câu hỏi hỗ trợ và an ninh nhanh: ai kết nối, khi nào thông tin đăng nhập thay đổi, và ai tắt nó. Một panel “Activity” trên trang chi tiết với 5–20 sự kiện gần nhất thường là đủ.

Ví dụ: Stripe có thể hiển thị cho mọi người, nhưng chỉ Admin (hoặc người được gắn “Billing manager”) mới có thể connect, xoay key, hoặc tắt payouts. Slack có thể cho phép Manager kết nối, trong khi Member vẫn nhận được thông báo Slack sau khi bật.

Bố cục UI vẫn hiệu quả khi có 30 tích hợp

Với 3 tích hợp bạn có thể hiển thị mọi thứ. Với 30, thư mục phải trả lời một câu hỏi nhanh: “Những cái nào đang hoạt động, và tôi nên làm gì tiếp theo?” Cách sạch nhất là tách việc quét khỏi việc làm.

Giữ view danh sách tập trung vào quyết định nhanh. Đẩy các controls nặng hơn vào trang chi tiết sau nút “Manage”.

Trong danh sách, chỉ hiển thị những gì hỗ trợ cú click tiếp theo:

• Icon, tên, và một dòng mô tả (giữ độ dài nhất quán)
• Một pill trạng thái rõ ràng (Connected, Needs setup, Error, Disabled)
• Một nút hành động chính
• Một nút phụ “Manage” cho mọi thứ còn lại

Cấu trúc thẻ quan trọng vì nó tạo thói quen. Hành động chính luôn nên có nghĩa “bước tiếp theo” dựa trên trạng thái: Connect cho mới, Continue setup cho chưa hoàn tất, Reconnect khi auth hết hạn, và Manage khi mọi thứ ổn. Tránh hai nút có trọng lượng ngang nhau trên mỗi thẻ — làm trang ồn.

Ví dụ:

• Nếu “Google” đã Connected, hành động chính có thể là Manage.
• Nếu “Slack” bị lỗi tối qua, hiển thị Error và đặt hành động chính là Reconnect.
• Nếu “Stripe” đang nửa vời, hiển thị Needs setup và Continue setup.

Các trạng thái trống nên hướng dẫn mà không dội cả manual lên màn hình:

• Chưa có tích hợp nào: gợi ý 2–3 lựa chọn phổ biến và những gì chúng mở khóa
• Không tìm thấy kết quả: đưa mẹo đơn giản như “thử ‘CRM’ hoặc ‘billing’”
• Lần đầu thiết lập: một câu về quyền và dữ liệu sẽ được truy cập

Điều này giữ trang bình tĩnh khi có 30 tích hợp vì mỗi thẻ trả lời: nó là gì, có ổn không, và tôi làm gì ngay bây giờ?

Trang chi tiết: flow thiết lập, connections và controls

Danh sách đưa người đến đúng integration. Trang chi tiết là nơi họ quyết định: thiết lập, sửa, hoặc tắt. Giữ cấu trúc trang nhất quán cho mọi integration, ngay cả khi công việc backend khác nhau.

Bắt đầu với phần tổng quan gọn: tên integration, mô tả một dòng, và nhãn trạng thái rõ ràng (Connected, Needs attention, Disabled). Thêm một dòng “Setup progress” nhỏ để người dùng biết họ còn gần xong hay mới bắt đầu.

Flow thiết lập cho cảm giác an toàn

Một wizard đơn giản thường ổn: 3–6 bước, một màn hình cho mỗi bước, luôn có “Back”. Đặt tên bước bằng ngôn ngữ dễ hiểu (Kết nối tài khoản, Chọn workspace, Chọn dữ liệu để đồng bộ, Xác nhận). Nếu bước có lựa chọn tuỳ chọn, gắn nhãn là tuỳ chọn thay vì giấu.

Nếu có thể tạm dừng thiết lập, nói rõ: “Bạn có thể hoàn tất sau. Chúng tôi sẽ lưu lựa chọn của bạn.” Điều đó giảm nỗi sợ rời khỏi giữa chừng.

Connections và control người dùng không hối tiếc

Hiển thị Connections dưới dạng bảng nhỏ: tên tài khoản, kết nối bởi (user), ngày tạo, và lần sync cuối.

Về “next sync”, tránh hứa những thời điểm chính xác bạn không chắc. Dùng câu bạn có thể cam kết, như “Next sync: scheduled soon” hoặc “Next sync: within the next hour”, dựa trên khả năng hệ thống.

Đặt các hành động rủi ro tránh xa đường chính. Đặt hành động chính ở trên (Continue setup, Reconnect). Đặt Disable và Disconnect trong mục “Danger zone” ở dưới cùng với mô tả ngắn hậu quả. Nếu hỗ trợ vai trò, nói một câu (ví dụ: “Chỉ admin mới có thể disconnect”).

Thêm nhật ký hoạt động nhỏ: các sự kiện gần đây (connected, token refreshed, sync failed), timestamps, và một thông báo lỗi ngắn người dùng có thể copy vào ticket hỗ trợ.

Từng bước: thêm một tích hợp mới từ đầu đến cuối

Thêm tích hợp dễ hơn khi bạn coi nó như một sản phẩm nhỏ. Nó cần một listing, cách kết nối, nơi lưu connection, và kết quả rõ ràng cho thành công hoặc thất bại.

1) Bắt đầu với mục trong catalog

Thêm integration vào catalog để nó xuất hiện trong thư mục ngay cả trước khi ai đó kết nối. Bao gồm tên rõ ràng, mô tả ngắn, icon, và một hoặc hai category (Messaging, Payments). Viết kỳ vọng thiết lập bằng ngôn ngữ dễ hiểu, như “Kết nối tài khoản” và “Chọn workspace.” Đây cũng là nơi bạn định nghĩa những gì integration sẽ cần sau này (OAuth scopes, trường bắt buộc, tính năng hỗ trợ).

2) Xây phương thức kết nối

Chọn cách kết nối đơn giản nhất phù hợp nhà cung cấp:

1. OAuth khi người dùng phải đăng nhập và chấp thuận quyền (thường cho Google, Slack)
2. API key khi người dùng dán token từ nhà cung cấp
3. Webhooks khi nhà cung cấp gửi event vào app của bạn

3) Lưu thông tin đăng nhập và tạo bản ghi Connection

Khi người dùng hoàn tất flow, tạo một Connection liên kết với workspace hoặc account chứ không chỉ user. Lưu thông tin đăng nhập an toàn (mã hoá khi lưu và tránh hiển thị bí mật đầy đủ sau đó). Lưu những dữ liệu cơ bản cần cho hỗ trợ: provider account ID, thời gian tạo, ai kết nối, và quyền được cấp.

4) Chạy kiểm tra lần đầu và đặt trạng thái + tiến độ

Chạy kiểm tra đơn giản ngay lập tức (với Stripe: lấy thông tin tài khoản). Nếu pass, hiển thị Connected và đánh dấu tiến độ hoàn tất. Nếu pass một phần (kết nối nhưng thiếu quyền), đánh dấu Needs attention và chỉ ra cách sửa chính xác.

5) Quyết định hiển thị khi thất bại

Hiển thị một thông điệp rõ, một hành động đề xuất, và một phương án an toàn. Ví dụ: “Không thể kết nối tới Stripe. Kiểm tra API key hoặc thử lại.” Giữ thư mục có thể dùng được ngay cả khi một tích hợp hỏng.

Nếu bạn đang xây trên Koder.ai (koder.ai), bạn có thể soạn catalog, flow thiết lập và quy tắc trạng thái trong Planning Mode trước, rồi tạo UI và backend từ kế hoạch đó.

Lỗi, thử lại, và lịch sử hữu ích cho hỗ trợ

Tích hợp thường hỏng vì những lý do tẻ nhạt. Nếu thư mục không giải thích được lý do, người dùng đổ lỗi cho app của bạn và hỗ trợ không có gì để dùng.

Gom các lỗi thành các nhóm tương ứng với cách sửa thực tế: login hết hạn, thiếu quyền, nhà cung cấp gián đoạn, hoặc giới hạn tần suất. Giữ mã lỗi nội bộ chi tiết, nhưng hiện cho người dùng nhãn ngắn dễ hiểu.

Khi có sự cố, thông báo nên trả lời ba điều: chuyện gì xảy ra, người dùng nên làm gì, và hệ thống bạn sẽ làm gì tiếp theo. Ví dụ: “Kết nối Slack hết hạn. Kết nối lại để tiếp tục đồng bộ. Chúng tôi sẽ tự động thử lại khi bạn kết nối lại.” Cách này điềm tĩnh và có hành động hơn là hiện lỗi API thô.

Quy tắc retry không làm người dùng khó chịu

Chỉ tự động thử lại khi người dùng không thể tự sửa. Một tập quy tắc đơn giản là đủ:

• Nhà cung cấp sập hoặc lỗi mạng: auto-retry với backoff, giữ last success time
• Bị rate limit: tạm dừng, thử lại sau, và hiển thị “Paused (rate limit)”
• Auth hết hạn: dừng retry và yêu cầu người dùng reconnect
• Thiếu quyền: dừng và hiển thị chính xác quyền cần
• Cấu hình sai: dừng và chỉ vào thiết lập phải điền

Trạng thái sẽ lỗi thời trừ khi bạn làm mới chúng. Thêm job kiểm tra sức khỏe nhẹ nhàng định kỳ để xác nhận token vẫn hợp lệ, lần sync gần nhất chạy, và badge thư mục phản ánh thực tế.

Lịch sử hỗ trợ

Giữ lịch sử sự kiện nhỏ theo từng install. Bạn không cần full logs, chỉ đủ dấu vết: timestamp, sự kiện (“token refreshed”, “sync failed”), lý do ngắn, và ai kích hoạt (user hoặc hệ thống). Thêm trường notes chỉ nội bộ để support ghi lại những gì họ thay đổi và lý do.

Tìm kiếm, bộ lọc, và tổ chức thư mục

Thư mục lộn ngay khi số app vượt vài cái. Mục tiêu đơn giản: giúp người dùng tìm thứ họ cần trong vài giây, và giúp họ thấy vấn đề mà không phải mở từng thẻ.

Bắt đầu với tìm kiếm cơ bản theo tên integration và category. Hầu hết người dùng gõ đúng thứ họ biết (“Slack”, “Stripe”), nên khớp tên quan trọng hơn sắp xếp phức tạp. Tìm kiếm theo category hữu ích khi họ chỉ biết chức năng (payments, messaging).

Bộ lọc nên phản chiếu ý định thực tế. Ba bộ lọc này thường đủ:

• Connected (đang hoạt động)
• Needs attention (lỗi, token hết hạn, thiếu quyền)
• Not set up (có trong catalog nhưng chưa có install)

Với việc tổ chức danh sách, chọn một cách nhóm chính và giữ nó. Nhóm theo category thường tốt khi số lượng lớn (CRM, Payments, Messaging). Độ phổ biến cũng hữu ích nếu phản ánh nhóm người dùng của bạn, không phải marketing. Mặc định thực tế: hiện những cái dùng nhiều nhất trước, rồi nhóm phần còn lại theo category.

Bạn cũng cần kế hoạch rõ cho “không phải ai cũng thấy mọi thứ.” Nếu một integration nằm sau feature flag hoặc gói trả tiền, hoặc ẩn nó cho hầu hết người dùng, hoặc hiển thị nó ở trạng thái disabled kèm lý do ngắn như “Business plan.” Tránh hiện một trang đầy thẻ mờ; làm vậy làm trang cảm giác hỏng.

Giữ hiệu năng mượt bằng cách tách load danh sách và chi tiết. Phân trang hoặc ảo hoá danh sách để không render 30 thẻ nặng cùng lúc, và load chi tiết khi người dùng mở integration. Thư mục chỉ cần hiển thị trường tóm tắt (Slack: Connected, Google: Needs attention, Stripe: Not set up) trong khi trang chi tiết fetch lịch sử connection đầy đủ.

Ví dụ: Slack, Google và Stripe trong ứng dụng thực tế

Hãy tưởng tượng một app workspace tên Pinework. Nó có hai vai trò: Admin và Member. Admin có thể kết nối công cụ và thay đổi cài đặt. Member có thể dùng công cụ đã kết nối nhưng không thể thêm hay xoá.

Trong thư mục tích hợp của Pinework, mỗi thẻ hiển thị nhãn rõ ràng (Connected, Needs setup, Error), một dòng “mục đích” ngắn, và tiến độ thiết lập như “2 of 3 steps.” Mọi người biết cái nào hoạt động và cái nào còn thiếu mà không cần bấm nhiều.

Slack dùng cho thông báo. Một Admin mở Slack sẽ thấy: Status: Connected, Setup: “3 of 3 steps.” Member cũng thấy Slack, nhưng hành động chính bị vô hiệu hoá và hiển thị “Ask an Admin to manage.” Nếu Slack ngắt kết nối, Member vẫn có thể thấy lỗi, nhưng không thấy controls reconnect.

Google dùng cho calendar. Pinework hỗ trợ hai department, nên cho phép nhiều connection. Thẻ Google hiển thị: Status: Connected (2 accounts). Dưới đó, dòng ngắn liệt kê “Marketing Calendar” và “Support Calendar.” Trang chi tiết hiển thị hai connection riêng để Admin có thể thu hồi từng cái.

Stripe dùng cho billing. Một thiết lập bán phần thường gặp: account đã connect nhưng webhook chưa xong. Thẻ hiển thị: Status: Needs setup, Progress: “2 of 3 steps,” kèm cảnh báo “Payments may not sync.” Trang chi tiết chỉ rõ các bước còn thiếu:

• Connect Stripe account (xong)
• Choose billing plan mapping (xong)
• Add webhook endpoint (chưa xong)

Điều này tránh tình huống đau đầu “trông có vẻ đã kết nối nhưng chẳng việc gì hoạt động”.

Những sai lầm thường làm cho tích hợp khó quản lý

Thư mục tích hợp thường vỡ khi app mở rộng từ vài tích hợp lên hàng chục. Vấn đề hiếm khi là “công nghệ lớn.” Chúng là những lỗi nhỏ về gán nhãn và mô hình khiến người dùng bối rối hàng ngày.

Một vấn đề phổ biến là lẫn lộn “installed” vs “connected.” Installed thường có nghĩa “có sẵn trong workspace.” Connected nghĩa có chứng thực thực sự và dữ liệu chảy. Khi hai khái niệm này lẫn nhau, người dùng bấm vào tích hợp trông như đã sẵn sàng rồi gặp ngõ cụt.

Một sai lầm khác là tạo quá nhiều trạng thái. Đội bắt đầu với một badge đơn giản, rồi thêm các edge case: pending, verifying, partial, paused, degraded, blocked, expiring, v.v. Qua thời gian, các nhãn đó drift vì không ai giữ chúng nhất quán. Giữ tập nhỏ gắn với các kiểm tra bạn có thể chạy: Not connected, Connected, Needs attention.

Quyền ẩn cũng gây rắc rối. Ai đó kết nối, sau đó phát hiện integration có quyền lớn hơn họ nghĩ. Hiện scope rõ trước bước “Connect” cuối cùng, và hiển thị lại trên trang chi tiết để admin có thể audit.

Đừng giả định một connection cho mỗi integration

Nhiều app cần nhiều connection: hai workspace Slack, vài tài khoản Stripe, hoặc một tài khoản Google chia sẻ plus tài khoản cá nhân. Nếu bạn cứng nhắc “một integration = một connection”, bạn sẽ phải làm các giải pháp xấu sau này.

Lên kế hoạch cho:

• Nhiều connection dưới một integration
• Một connection “mặc định” rõ ràng (nếu cần)
• Connection chia sẻ vs cá nhân
• Nơi hiển thị ai đã kết nối

Giữ view danh sách nhẹ. Khi nhồi nhét logs, ánh xạ trường, và mô tả dài vào list, việc quét chậm lại. Dùng list cho tên, mục đích ngắn, và tiến độ thiết lập. Đặt lịch sử và cài đặt nâng cao vào trang chi tiết.

Checklist nhanh và bước tiếp theo

Một thư mục tích hợp có thể mở rộng gói gọn trong mô hình đơn giản và UI trung thực. Nếu người dùng có thể trả lời ba câu hỏi nhanh, hệ thống sẽ có cảm giác dự đoán được: đã kết nối gì, cái gì hỏng, và tôi phải làm gì tiếp theo?

Checklist trước khi phát hành:

• Tách mô hình: Integration (catalog) vs Install (bật trong workspace) vs Connection (OAuth token, API key, hoặc webhook). Thêm Event chỉ khi cần lịch sử audit và hỗ trợ.
• Suy ra trạng thái: tính nhãn từ các kiểm tra (token hợp lệ, scopes OK, webhook truy cập được) cộng với các bước thiết lập đã hoàn thành, để badge luôn chính xác.
• Giữ list scannable: mỗi hàng hiển thị tên, nhãn trạng thái rõ, và một “hành động tiếp theo” (Connect, Continue, Reconnect, Fix permissions).
• Đặt lifecycle action là first-class: Connect, Continue setup, Reconnect, Disable, và Disconnect nên dễ tìm, kèm xác nhận ngắn.
• Làm cho phân quyền hiển thị và audit được: hiển thị ai có thể connect hoặc disconnect, và ghi lại ai thay đổi gì và khi nào.

Bước tiếp theo: chọn ba tích hợp bạn đã hiểu rõ và mô hình hoá chúng end-to-end: một công cụ chat (OAuth), một kết nối dạng Google (OAuth với scopes), và một công cụ thanh toán (API key kèm webhooks). Nếu mô hình của bạn diễn đạt được cả ba mà không cần ngoại lệ lớn, nó thường sẽ mở rộng đến 30.