Mô tả tính năng quản lý hồ sơ chat
Back to ezychatHồ sơ chat là cấu hình trung tâm để triển khai nhiều trải nghiệm chat khác nhau trên cùng một hệ thống. Mỗi hồ sơ có thể đại diện cho một website, thương hiệu, nhóm khách hàng hoặc ngữ cảnh hỗ trợ riêng.
Thông qua hồ sơ chat, quản trị viên có thể cấu hình giao diện widget, phương thức truyền tin, chatbot, yêu cầu thông tin khách hàng, quyền đính kèm tệp và đội ngũ phụ trách.
Kiến trúc tổng quát
flowchart TD
A[Hồ sơ chat] --> B[Khóa nhúng]
A --> C[Cấu hình widget]
A --> D[Cấu hình chatbot]
A --> E[Quy tắc thông tin khách hàng]
A --> F[Thành viên phụ trách]
A --> G[Danh sách nguồn được phép]
B --> H[Website hoặc iframe]
H --> I[Tạo kênh hỗ trợ]
I --> J[Gắn hồ sơ vào kênh]
F --> J
D --> K[Chatbot trả lời trong kênh]
Hồ sơ không phải là một cuộc hội thoại. Nó là cấu hình dùng chung cho nhiều kênh chat được tạo từ cùng một nguồn.
Mô hình dữ liệu
Mỗi hồ sơ chat lưu các nhóm thông tin sau:
| Nhóm | Thuộc tính chính |
|---|---|
| Định danh | ID, loại, tên, khóa nhúng |
| Nguồn sử dụng | URL website, nguồn được phép |
| Vòng đời | Trạng thái, thời gian tạo và cập nhật |
| Chatbot | Dịch vụ bot, system message |
| Giao diện | Kiểu, vị trí, kích thước và màu nút |
| Hình ảnh | Ảnh launcher, ảnh nhân viên hỗ trợ |
| Hiệu ứng | Bật hoặc tắt hiệu ứng launcher |
| Truyền tin | Socket hoặc HTTP |
| Thông tin khách hàng | Có yêu cầu thông tin, email hoặc điện thoại hay không |
| Tệp đính kèm | Cho phép hoặc không cho phép |
| Trang trang trí | ID nội dung dùng cho mở rộng giao diện |
| Thành viên | Danh sách nhân sự phụ trách hồ sơ |
Mô hình dữ liệu còn có các trường cấu hình AI như endpoint, model, giới hạn token, timeout và datasource. Tuy nhiên, màn hình quản trị hồ sơ hiện tại chưa cung cấp các trường này.
Loại hồ sơ
Hệ thống định nghĩa hai loại hồ sơ:
-
CHAT_WIDGET: cấu hình widget chat được nhúng vào website. -
CHATBOT: hồ sơ dành cho ngữ cảnh chatbot.
Nếu không chỉ định loại khi tạo, hệ thống mặc định sử dụng
CHAT_WIDGET.
Màn hình danh sách cho phép lọc theo cả hai loại. Tuy nhiên, biểu mẫu thêm và cập nhật hiện không có trường chọn loại, và request lưu hồ sơ cũng không chứa thuộc tính loại. Vì vậy, hồ sơ được tạo từ giao diện hiện tại luôn nhận loại mặc định
CHAT_WIDGET.Trạng thái hồ sơ
Hồ sơ có hai trạng thái:
stateDiagram-v2
[*] --> ACTIVATED: Tạo mới
ACTIVATED --> INACTIVATED: Ngừng sử dụng
INACTIVATED --> ACTIVATED: Kích hoạt lại
ACTIVATED --> [*]: Xóa
INACTIVATED --> [*]: Xóa
Đang hoạt động
Chỉ hồ sơ
ACTIVATED được sử dụng khi:- Tải widget bằng khóa nhúng.
- Mở trang chat hỗ trợ theo hồ sơ.
- Tạo kênh hỗ trợ từ nguồn nhúng.
- Lấy cấu hình chatbot theo kênh.
- Kiểm tra thành viên đang phụ trách hồ sơ.
Ngừng hoạt động
Hồ sơ
INACTIVATED vẫn tồn tại trong trang quản trị nhưng không được giải quyết từ khóa nhúng trong các luồng phía người dùng.Nếu client tiếp tục dùng khóa của một hồ sơ đã ngừng hoạt động, hệ thống phản hồi như không tìm thấy hồ sơ hợp lệ.
Việc ngừng hồ sơ không tự động:
- Xóa widget khỏi các website đã nhúng.
- Xóa các kênh đã tạo.
- Xóa thành viên hồ sơ.
- Ngừng các cuộc hội thoại đang tồn tại.
- Gỡ hồ sơ khỏi các kênh đã liên kết.
Xóa hồ sơ
Xóa hồ sơ là xóa vật lý bản ghi, không phải chuyển sang trạng thái đã xóa.
Hệ thống đồng thời xóa metadata gắn với hồ sơ, chẳng hạn cấu hình nguồn được phép. Tuy nhiên, luồng xóa hiện không thể hiện việc xóa theo chuỗi đối với:
- Thành viên hồ sơ.
- Kênh đang tham chiếu đến hồ sơ.
- Tin nhắn trong các kênh đó.
Do đó, nên ưu tiên chuyển sang
INACTIVATED nếu cần ngừng sử dụng nhưng vẫn muốn bảo toàn quan hệ dữ liệu.
Danh sách hồ sơ chat

Màn hình danh sách hiển thị:
- ID.
- Tên hồ sơ.
- URL website.
- Loại hồ sơ.
- Khóa nhúng.
- Dịch vụ chatbot.
- Trạng thái.
- Các thao tác xem, lấy mã nhúng, sửa và xóa.
Danh sách hỗ trợ lọc theo:
- Loại hồ sơ.
- Trạng thái.
- Từ khóa.
- Số bản ghi mỗi trang.
Số lượng bản ghi trên một trang có thể chọn từ 30 đến 500.
Tìm kiếm hồ sơ
Tên và khóa nhúng của hồ sơ được đưa vào chỉ mục tìm kiếm.
Từ khóa tìm kiếm sử dụng cơ chế khớp tiền tố. Điều này cho phép:
- Tìm theo phần đầu tên hồ sơ.
- Tìm bằng khóa nhúng.
- Gợi ý hồ sơ khi nhập từ khóa.
Khi nhập từ khóa trên màn hình danh sách:
- Nhấn Enter để thực hiện tìm kiếm.
- Xóa toàn bộ từ khóa để tự động tải lại danh sách.
- Từ khóa và các bộ lọc được đồng bộ vào URL trình duyệt.
Hệ thống cũng cung cấp luồng gợi ý hồ sơ, trả về ID, tên và khóa nhúng. Nếu từ khóa trống, danh sách gợi ý rỗng.
Phân trang
Danh sách dùng phân trang cursor và hỗ trợ:
- Trang đầu.
- Trang trước.
- Trang tiếp theo.
- Trang cuối.
- ID tăng dần.
- ID giảm dần.
Cursor được giữ riêng cho truy vấn hiện tại. Sau khi xóa một hồ sơ, giao diện tải lại trang đang xem với điều kiện tìm kiếm trước đó.
Tạo hồ sơ
Khi tạo hồ sơ, hệ thống:
- Nhận cấu hình từ biểu mẫu.
- Sinh một khóa nhúng ngẫu nhiên.
- Áp dụng loại mặc định nếu thiếu.
- Áp dụng trạng thái mặc định nếu thiếu.
- Lưu hồ sơ.
- Ghi nhận thời gian tạo và cập nhật.
- Chuyển người quản trị đến trang chi tiết.
Khóa nhúng được sinh ở máy chủ, không nhận trực tiếp từ trình duyệt. Điều này tránh việc người dùng tự chọn khóa yếu hoặc dễ đoán.
Khóa nhúng không được thay đổi khi cập nhật hồ sơ.
Thông tin cơ bản

Tên hồ sơ
Tên giúp người quản trị phân biệt các cấu hình, ví dụ:
- Website bán hàng.
- Trang hỗ trợ kỹ thuật.
- Cổng khách hàng doanh nghiệp.
- Widget tư vấn sản phẩm.
Tên cũng được đưa vào chỉ mục tìm kiếm.
URL website
URL website mô tả nguồn hoặc trang liên quan đến hồ sơ. Giá trị này:
- Được hiển thị trong danh sách và trang chi tiết.
- Được chuyển xuống cấu hình widget.
- Có thể được dùng làm đường dẫn liên quan trong trải nghiệm phía người dùng.
URL website không tự động trở thành quy tắc bảo mật nguồn nhúng. Việc kiểm soát origin sử dụng metadata riêng.
Khóa nhúng
Mỗi hồ sơ có một
embed key duy nhất được sinh khi tạo.Khóa này được dùng để:
- Tải đúng cấu hình widget.
- Mở trang hỗ trợ đúng hồ sơ.
- Xác định hồ sơ khi tạo kênh.
- Liên kết kênh chat với cấu hình tương ứng.
Khóa nhúng là định danh truy cập, không phải mật khẩu quản trị.
Mã nhúng widget
Từ màn hình danh sách hoặc trang chi tiết, quản trị viên có thể tạo và sao chép một đoạn script nhúng.
Cấu trúc tổng quát:
<script src="https://chat.example.com/ezychat/js/embed.js" data-profile="EMBED_KEY" data-lang="default" data-style="" async> </script>
Trong đó:
-
srctrỏ tới script widget của hệ thống chat. -
data-profilechứa khóa của hồ sơ. -
data-langchọn ngôn ngữ. -
data-styledành cho tùy chỉnh kiểu hiển thị. -
asyncgiúp script không chặn quá trình tải trang chính.
Khi widget được tải, khóa nhúng được gửi về máy chủ để lấy hồ sơ đang hoạt động.
Iframe hỗ trợ
Ngoài script widget, trang chi tiết còn sinh một đoạn iframe mở giao diện hỗ trợ toàn trang.
Cấu trúc tổng quát:
<iframe src="https://chat.example.com/ezychat/support?profile=EMBED_KEY&lang=default&style=" title="Support Chat" width="100%" height="700" frameborder="0" allow="clipboard-write"> </iframe>
Quản trị viên có thể:
- Sao chép đoạn iframe.
- Mở thử giao diện hỗ trợ trong tab mới.
- Dùng iframe trong trang nội bộ hoặc một bố cục tùy chỉnh.
Script widget phù hợp với nút chat nổi; iframe phù hợp khi muốn dành một vùng trang cố định cho chat.
Xác thực nguồn nhúng
Khi nhận khóa nhúng, máy chủ thực hiện:
- Tìm hồ sơ theo khóa.
- Kiểm tra hồ sơ đang hoạt động.
- Lấy header
Origin. - Nếu không có
Origin, suy ra origin từReferer. - Kiểm tra origin có nằm trong danh sách được phép hay không.
Origin được chuẩn hóa về dạng:
scheme://host[:port]
Ví dụ:
https://example.com https://support.example.com http://localhost:3000
Nếu hồ sơ chưa có bất kỳ origin nào được cấu hình, hệ thống cho phép mọi nguồn. Nếu đã có danh sách, request chỉ được chấp nhận khi origin khớp một giá trị đã lưu.
Mô hình kiểm tra là khớp chính xác, không phải so sánh hậu tố tên miền hoặc wildcard.
Cấu hình giao diện widget
Mỗi hồ sơ có thể tùy chỉnh nút mở chat.
Kiểu nút
Giao diện hỗ trợ:
- Hình tròn.
- Hình vuông bo góc.
- Hình vuông.
Vị trí
Nút có thể nằm:
- Bên phải.
- Bên trái.
Kích thước
Các lựa chọn gồm:
- Nhỏ.
- Trung bình.
- Lớn.
Giá trị mặc định trên biểu mẫu là kích thước trung bình.
Màu sắc
Quản trị viên có thể:
- Chọn màu bằng color picker.
- Nhập mã màu dạng hex.
- Chọn một trong các màu gợi ý.
Widget dùng màu này cho:
- Màu chính của launcher.
- Gradient của nút.
- Màu nền tin nhắn do khách hàng gửi.
Ô nhập mã hex chỉ đồng bộ sang color picker khi giá trị có dạng
#RRGGBB.
Ảnh launcher
Có thể cấu hình URL hình ảnh thay cho biểu tượng chat mặc định. Khi có URL, widget hiển thị ảnh trong nút mở chat.
Hiệu ứng launcher
Hiệu ứng của nút mở chat có thể bật hoặc tắt theo từng hồ sơ.
Ảnh nhân viên hỗ trợ
Hồ sơ có thể cấu hình ảnh đại diện riêng cho đội hỗ trợ. Ảnh này được sử dụng trong widget phía khách hàng thay cho ảnh hỗ trợ mặc định toàn hệ thống.
Phương thức truyền tin
Hồ sơ cho phép chọn cách chat trên web:
- Socket.
- HTTP.
Biểu mẫu thể hiện lựa chọn này bằng tùy chọn “chat qua socket trên web”:
- Bật: lưu phương thức
SOCKET. - Tắt: lưu phương thức
HTTP.
Socket
Phù hợp với hội thoại realtime:
- Nhận tin ngay lập tức.
- Gửi trạng thái đang nhập.
- Nhận trạng thái chatbot.
- Duy trì kết nối lâu dài.
HTTP
Widget sử dụng API HTTP để tạo kênh và trao đổi dữ liệu. Chế độ này phù hợp với môi trường không muốn hoặc không thể duy trì kết nối socket liên tục.
Phương thức truyền tin là cấu hình theo hồ sơ, nên hai website có thể sử dụng hai cơ chế khác nhau trên cùng hệ thống.
Thu thập thông tin khách hàng
Hồ sơ có các tùy chọn:
- Yêu cầu nhập thông tin trước khi chat.
- Bắt buộc email.
- Bắt buộc số điện thoại.
- Mật khẩu và xác nhận mật khẩu trên biểu mẫu đăng ký.
Khi yêu cầu thông tin được bật, widget hiển thị biểu mẫu gồm:
- Tên hiển thị.
- Email.
- Số điện thoại.
- Mật khẩu tùy chọn.
- Xác nhận mật khẩu.
Email và số điện thoại chỉ được kiểm tra bắt buộc khi đồng thời:
- Chế độ yêu cầu thông tin được bật.
- Trường tương ứng được cấu hình là bắt buộc.
Nếu người dùng không nhập mật khẩu, widget sinh một mật khẩu ngẫu nhiên. Thông tin liên hệ không được sử dụng làm mật khẩu.
Nếu người dùng nhập mật khẩu, mật khẩu đó được dùng khi truy cập một tài khoản đã tồn tại.
Quyền đính kèm tệp
Hồ sơ có thể cho phép hoặc không cho phép khách hàng đính kèm tệp.
Khi được phép, widget hiển thị:
- Nút đính kèm.
- Ô chọn nhiều tệp.
- Chức năng tải tài nguyên trước khi gửi tin.
Khi không được phép, nút đính kèm không được sinh ra trong giao diện.
Đây là cấu hình phía trải nghiệm người dùng. API tải tệp vẫn cần kiểm tra quyền và giới hạn tệp ở máy chủ để bảo đảm an toàn.
Cấu hình chatbot
Mỗi hồ sơ có thể chọn:
- Dịch vụ chatbot.
- System message riêng.
Danh sách dịch vụ chatbot trên biểu mẫu được lấy từ các dịch vụ đang được đăng ký trong hệ thống.
Khi chatbot trả lời trong một kênh:
- Hệ thống tìm hồ sơ đang hoạt động gắn với kênh.
- Nếu tìm thấy, dùng dịch vụ chatbot của hồ sơ.
- Nếu không tìm thấy hồ sơ hoạt động, thử dùng cấu hình chatbot mặc định toàn hệ thống.
- Lấy các tin gần nhất làm ngữ cảnh.
- Dùng system message của hồ sơ nếu có.
- Nếu system message của hồ sơ trống, dùng system message mặc định.
- Gửi yêu cầu streaming đến dịch vụ chatbot.
- Phát từng phần câu trả lời về client.
- Lưu câu trả lời hoàn chỉnh thành tin nhắn.
sequenceDiagram
participant U as Khách hàng
participant C as Kênh chat
participant P as Hồ sơ chat
participant B as Dịch vụ chatbot
U->>C: Gửi câu hỏi
C->>P: Lấy hồ sơ đang hoạt động
P-->>C: Dịch vụ bot và system message
C->>B: Gửi câu hỏi cùng lịch sử gần nhất
B-->>C: Streaming nội dung trả lời
C-->>U: Hiển thị nội dung đang sinh
C->>C: Lưu câu trả lời hoàn chỉnh
Việc chọn dịch vụ chatbot trong hồ sơ không tự động bảo đảm chatbot đã là thành viên của mọi kênh. Trạng thái bật hoặc tắt chatbot vẫn được quản lý riêng theo từng kênh.
Liên kết hồ sơ với kênh
Khi khách hàng bắt đầu chat bằng khóa nhúng:
- Máy chủ xác thực khóa và origin.
- Tìm hoặc tạo kênh hỗ trợ.
- Gắn ID hồ sơ vào kênh.
- Thêm khách hàng vào kênh.
- Thêm đội hỗ trợ toàn cục.
- Thêm các thành viên đang hoạt động của hồ sơ.
- Có thể thêm chatbot.
- Trả về thông tin kênh cho widget.
sequenceDiagram
participant W as Widget
participant V as Bộ kiểm tra hồ sơ
participant P as Hồ sơ chat
participant C as Dịch vụ kênh
participant M as Thành viên
W->>V: Gửi khóa nhúng và origin
V->>P: Tìm hồ sơ đang hoạt động
P-->>V: Cấu hình hồ sơ
V->>V: Kiểm tra origin
V->>C: Tìm hoặc tạo kênh hỗ trợ
C->>C: Gắn hồ sơ vào kênh
P->>M: Lấy thành viên đang hoạt động
M->>C: Thêm thành viên vào kênh
C-->>W: Trả về ID kênh
Kênh lưu
chatProfileId, nhờ đó các luồng sau có thể:- Xác định nguồn của hội thoại.
- Dùng cấu hình chatbot tương ứng.
- Lọc danh sách chat theo hồ sơ.
- Kiểm tra thành viên chuyên trách.
- Hiển thị thông tin hồ sơ trong chi tiết kênh.
Thành viên hồ sơ
Trang chi tiết hồ sơ chứa danh sách thành viên phụ trách.
Mỗi phân công gồm:
- Loại thành viên.
- ID thành viên.
- Vai trò.
- Trạng thái.
- Thời gian tạo và cập nhật.
Loại thành viên trên giao diện gồm:
- Người dùng.
- Quản trị viên.
Vai trò hiện có trên giao diện là nhân viên chăm sóc khách hàng.
Trạng thái gồm:
-
ACTIVATED: được đưa vào các kênh mới của hồ sơ. -
INACTIVATED: giữ bản ghi nhưng không được đưa vào kênh mới.
Quản trị viên có thể:
- Thêm thành viên.
- Sửa danh tính, vai trò hoặc trạng thái.
- Xóa phân công.
- Duyệt danh sách bằng cursor.
Khi tạo kênh từ hồ sơ, chỉ các thành viên
ACTIVATED được thêm vào kênh.
Việc thay đổi danh sách thành viên không tự động đồng bộ ngược tới các kênh đã tồn tại.
Trang chi tiết hồ sơ
Trang chi tiết tập hợp:
- Thông tin cơ bản.
- Trạng thái.
- Khóa nhúng.
- Đoạn script nhúng.
- Đoạn iframe hỗ trợ.
- Cấu hình chatbot.
- Cấu hình giao diện.
- Cấu hình thu thập thông tin.
- Quyền đính kèm tệp.
- Danh sách thành viên.
- Thao tác sửa và xóa.
Ảnh launcher và ảnh nhân viên hỗ trợ được hiển thị trực tiếp để quản trị viên kiểm tra.
Trang cũng cung cấp nút mở thử giao diện hỗ trợ bằng khóa nhúng hiện tại.
Cập nhật hồ sơ
Khi cập nhật:
- Khóa nhúng được giữ nguyên.
- Thời gian cập nhật được thay đổi.
- Các thuộc tính trong biểu mẫu được ghi đè vào hồ sơ.
- Quản trị viên được chuyển về trang chi tiết sau khi lưu.
Các kênh đã gắn ID hồ sơ không cần cập nhật lại quan hệ. Khi một luồng cần cấu hình hồ sơ, hệ thống đọc hồ sơ hiện tại theo ID.
Điều này có nghĩa thay đổi system message hoặc dịch vụ chatbot có thể ảnh hưởng tới các lần trả lời tiếp theo trong những kênh cũ vẫn gắn hồ sơ đó.
Trang trí bằng nội dung
Hồ sơ có trường ID nội dung trang trí. Mục đích kiến trúc là cho phép liên kết một nội dung quản trị với trải nghiệm chat.
Tuy nhiên, trong các luồng runtime đã đọc, trường này hiện chỉ được:
- Nhập từ biểu mẫu.
- Lưu vào hồ sơ.
- Hiển thị trên trang chi tiết.
Chưa thấy cơ chế runtime sử dụng ID này để tải hoặc áp dụng nội dung trang trí cho widget. Vì vậy, đây hiện là điểm mở rộng hơn là một tính năng hoàn chỉnh.
Quan hệ dữ liệu
erDiagram
CHAT_PROFILE ||--o{ CHAT_PROFILE_MEMBER : "có thành viên"
CHAT_PROFILE ||--o{ CHANNEL : "cấu hình cho"
CHANNEL ||--o{ MESSAGE : "chứa"
CHAT_PROFILE ||--o{ DATA_META : "có metadata"
CHAT_PROFILE {
long id
string type
string embedKey
string name
string webUrl
string status
string chatBotServiceName
string chatTransportType
string systemMessage
}
CHAT_PROFILE_MEMBER {
long chatProfileId
string memberType
long memberId
string roleName
string status
}
CHANNEL {
long id
long chatProfileId
string status
}
DATA_META {
string metaKey
string metaValue
}
Bảo mật
Khóa nhúng không phải bí mật tuyệt đối
Khóa xuất hiện trong HTML của website nên khách truy cập có thể đọc được. Bảo mật không nên chỉ dựa vào việc giữ kín khóa.
Các lớp bảo vệ cần thiết gồm:
- Hồ sơ phải đang hoạt động.
- Kiểm tra origin.
- Xác thực người dùng khi tạo hoặc truy cập kênh.
- Kiểm tra thành viên kênh.
- Giới hạn upload.
- Kiểm tra quyền gửi tin.
Origin và Referer
Máy chủ ưu tiên header
Origin. Nếu không có, origin được suy ra từ Referer.Nếu cả hai đều thiếu, giá trị kiểm tra là rỗng. Khi hồ sơ có danh sách origin, request dạng này bị từ chối trừ khi metadata tương ứng cho phép rõ ràng.
Không dùng URL website thay cho allowlist
Trường URL website không được dùng trực tiếp trong phép kiểm tra origin. Quản trị viên cần cấu hình allowlist riêng nếu muốn giới hạn nguồn nhúng.
Giới hạn và điểm cần lưu ý
Chưa có giao diện quản lý origin
Backend có khả năng lưu và kiểm tra origin được phép, nhưng trong các luồng quản trị đã đọc:
- Không có trường nhập origin.
- Không có API quản trị origin.
- Không thấy lời gọi lưu origin.
Vì vậy, hồ sơ thông thường chưa có metadata origin và mặc định cho phép mọi nguồn sử dụng khóa nhúng.
Cấu hình “yêu cầu thông tin người dùng” chưa được lưu
Request và model có thuộc tính yêu cầu thông tin trước khi chat. Tuy nhiên, quá trình ánh xạ model vào entity hiện không gán thuộc tính này.
Hệ quả có thể là:
- Checkbox được gửi từ giao diện nhưng không được lưu.
- Giá trị đọc lại luôn rỗng hoặc không đúng mong đợi.
- Widget bỏ qua biểu mẫu thông tin và đăng ký khách ngẫu nhiên.
- Hai tùy chọn bắt buộc email và điện thoại chỉ có tác dụng khi cờ tổng được bật, nên cũng có thể mất tác dụng.
Đây là lỗi triển khai cần được sửa trước khi dựa vào tính năng thu thập thông tin.
Loại hồ sơ chưa chỉnh sửa được
Màn hình danh sách hỗ trợ lọc theo loại, nhưng:
- Form không có trường loại.
- Request lưu không có loại.
- Hồ sơ mới luôn dùng
CHAT_WIDGET. - Không thể tạo
CHATBOTtừ màn hình hiện tại.
Không thể thay hoặc thu hồi khóa nhúng
Khóa chỉ được sinh khi tạo và không có chức năng:
- Tạo lại khóa.
- Thu hồi khóa cũ.
- Dùng song song nhiều khóa.
- Đặt thời hạn cho khóa.
Nếu khóa bị lạm dụng, biện pháp hiện tại là vô hiệu hóa hoặc xóa hồ sơ.
Xóa hồ sơ có nguy cơ để lại quan hệ mồ côi
Luồng xóa không thể hiện việc xử lý thành viên và kênh đang tham chiếu. Tùy ràng buộc cơ sở dữ liệu, thao tác có thể:
- Bị từ chối.
- Để lại dữ liệu tham chiếu tới ID không còn tồn tại.
- Làm các kênh rơi về cấu hình chatbot mặc định.
Chưa kiểm tra dữ liệu cấu hình chuyên biệt
Trong luồng lưu hồ sơ chưa thấy validator chuyên biệt bảo đảm:
- Tên không rỗng.
- URL website hợp lệ.
- Màu đúng định dạng.
- Dịch vụ chatbot tồn tại.
- Trạng thái thuộc tập cho phép.
- Kiểu nút, vị trí và kích thước hợp lệ.
- ID nội dung trang trí tồn tại.
- Quan hệ hợp lệ giữa “yêu cầu thông tin” và “bắt buộc email/điện thoại”.
Giao diện giới hạn một phần lựa chọn, nhưng API vẫn nên kiểm tra độc lập.
Thông tin đăng nhập được cấu hình chưa đầy đủ
Entity và model có trường yêu cầu mật khẩu khi chat, nhưng:
- Request quản trị không có trường tương ứng.
- Biểu mẫu không có tùy chọn này.
- Converter không lưu giá trị này.
- Response widget cũng không trả cấu hình đó.
Widget vẫn hiển thị mật khẩu dưới dạng tùy chọn khi thu thập thông tin.
Các trường AI chưa được quản lý
Entity có các trường AI mở rộng nhưng biểu mẫu, request lưu và response quản trị không hỗ trợ. Chúng hiện không thể được cấu hình qua màn hình hồ sơ.
Dịch vụ bot trống trên hồ sơ hoạt động
Khi kênh gắn với một hồ sơ đang hoạt động, dịch vụ bot được lấy trực tiếp từ hồ sơ. Nếu trường này trống nhưng bot vẫn được bật trong kênh, cần kiểm tra cách bộ quản lý dịch vụ xử lý tên dịch vụ trống; luồng fallback mặc định chủ yếu áp dụng khi không tìm được hồ sơ đang hoạt động.
Thành viên chỉ được sao chép lúc tạo kênh
Thêm, vô hiệu hóa hoặc xóa thành viên hồ sơ không cập nhật tự động các kênh cũ. Nếu cần đồng bộ quyền, hệ thống phải có tác vụ riêng để cập nhật thành viên kênh.
Khuyến nghị vận hành
Khi tạo hồ sơ mới:
- Đặt tên thể hiện rõ website hoặc nhóm nghiệp vụ.
- Chọn dịch vụ chatbot nếu cần.
- Cấu hình system message theo phạm vi sử dụng.
- Chọn giao diện launcher phù hợp.
- Quyết định dùng HTTP hay socket.
- Cấu hình yêu cầu thông tin khách hàng.
- Quyết định có cho phép tải tệp không.
- Kích hoạt hồ sơ.
- Thêm thành viên phụ trách.
- Cấu hình allowlist origin trước khi công khai khóa.
- Sao chép mã nhúng và thử trên môi trường kiểm thử.
- Kiểm tra kênh mới được gắn đúng hồ sơ và thành viên.
Khi ngừng sử dụng:
- Chuyển hồ sơ sang
INACTIVATED. - Gỡ mã nhúng khỏi website.
- Kiểm tra các kênh đang hoạt động.
- Thu hồi thành viên kênh nếu cần.
- Chỉ xóa vật lý sau khi xử lý các quan hệ liên quan.
Kết luận
Hồ sơ chat là lớp cấu hình kết nối giữa website, widget, chatbot, đội hỗ trợ và kênh hội thoại. Nó cho phép mỗi nguồn chat có:
- Khóa nhúng riêng.
- Giao diện riêng.
- Phương thức truyền tin riêng.
- Chatbot và system message riêng.
- Quy tắc thu thập thông tin riêng.
- Chính sách đính kèm tệp riêng.
- Danh sách nhân viên phụ trách riêng.
Thiết kế này phù hợp với hệ thống đa website hoặc đa thương hiệu. Những phần cần hoàn thiện đáng chú ý nhất là giao diện quản lý origin, khả năng quản lý loại hồ sơ, lưu cờ yêu cầu thông tin người dùng, kiểm tra dữ liệu đầu vào và quy trình an toàn khi xóa hồ sơ.