Một nhân viên sales xóa nhầm công ty trong CRM. Bản ghi đó đang gắn với liên hệ, báo giá và lịch follow-up. Nếu hệ thống xóa ngay, đội kỹ thuật có thể phải phục hồi từ bản sao lưu, còn báo cáo doanh thu vẫn có nguy cơ sai. Chức năng xóa vì thế bắt đầu ở quy tắc dữ liệu và quyền chịu trách nhiệm.
Với MVP, đội ngũ chưa cần xây một trung tâm quản trị phức tạp. Nhưng từng loại bản ghi phải có câu trả lời rõ: người dùng đang ẩn khỏi màn hình, chuyển sang vùng có thể khôi phục hay yêu cầu xóa vĩnh viễn?
Phân biệt ẩn, lưu trữ và xóa vĩnh viễn
Ẩn chỉ thay đổi cách bản ghi xuất hiện trong một màn hình hoặc với một nhóm người dùng. Dữ liệu vẫn tồn tại và có thể tiếp tục ảnh hưởng đến báo cáo. Lưu trữ đưa bản ghi ra khỏi quy trình đang hoạt động nhưng giữ lại để tra cứu. Xóa có thể là xóa mềm, bản ghi được đánh dấu đã xóa và còn thời hạn khôi phục, hoặc xóa vĩnh viễn khỏi hệ thống theo chính sách đã duyệt.
Sự khác biệt này cần xuất hiện trong giao diện. Nếu thao tác chỉ chuyển dự án sang trạng thái ngừng hoạt động, nút nên ghi “Lưu trữ”, không phải “Xóa”.
Dữ liệu liên quan quyết định mức độ rủi ro của thao tác
Trước khi chọn cách xóa, hãy vẽ quan hệ quanh bản ghi. Một khách hàng có thể liên kết với người liên hệ, hợp đồng, hóa đơn, tệp đính kèm và tác vụ. Xóa tất cả theo dây chuyền thường nguy hiểm. Giữ mọi thứ nhưng bỏ bản ghi gốc cũng có thể tạo dữ liệu không còn ngữ cảnh.
Mỗi liên kết cần một quy tắc. Hóa đơn đã phát hành có thể phải được giữ. Tác vụ chưa hoàn tất nên chặn xóa hoặc yêu cầu chuyển người phụ trách. Với dữ liệu dùng chung, hệ thống chỉ nên gỡ liên kết.
Cách làm này liên quan trực tiếp tới thiết kế phân quyền cho MVP nội bộ. Quyền xem một bản ghi không mặc nhiên bao gồm quyền xóa nó.
Quy trình thiết kế chức năng xóa dữ liệu
Bước 1: Lập danh sách loại dữ liệu và quan hệ
Ghi rõ bản ghi chính, dữ liệu phụ thuộc, dữ liệu dùng chung và thông tin cần giữ theo yêu cầu nghiệp vụ.
Bước 2: Chọn hành động phù hợp cho từng loại
Quyết định trường hợp nào dùng ẩn, lưu trữ, xóa mềm hoặc xóa vĩnh viễn. Nêu điều kiện chặn và ngoại lệ.
Bước 3: Gắn quyền với mức rủi ro
Xác định ai được gửi yêu cầu, ai được xác nhận, ai được khôi phục và khi nào cần hai người tham gia.
Bước 4: Thiết kế trạng thái và thời hạn
Một yêu cầu có thể đi qua các trạng thái chờ xác nhận, đã xóa mềm, đã khôi phục hoặc đã xóa vĩnh viễn. Hệ thống cần biết thời điểm hết hạn.
Bước 5: Kiểm thử toàn bộ tác động
Kiểm tra danh sách, tìm kiếm, báo cáo, tích hợp, tệp đính kèm và thao tác chạy lại khi kết nối bị gián đoạn.
Hộp thoại xác nhận cần cung cấp thông tin gì?
Một câu “Bạn có chắc không?” chưa đủ. Hộp thoại cần gọi đúng đối tượng, nêu dữ liệu bị ảnh hưởng, khả năng khôi phục và thời hạn. Với thao tác rủi ro cao, có thể yêu cầu nhập lại tên bản ghi.
Nếu tác vụ đang được xử lý ở nền, giao diện phải cho biết yêu cầu đã được tiếp nhận chứ chưa hoàn tất. Người dùng không nên gửi lặp lại vì tưởng nút không hoạt động. Cơ chế chạy lại an toàn có thể áp dụng nguyên tắc trong bài retry và idempotency cho quy trình tự động.
Khi nào MVP cần bước duyệt riêng?
Không phải thao tác nào cũng cần quản lý duyệt. Xóa bản nháp cá nhân chưa chia sẻ có thể thực hiện ngay và cho phép hoàn tác ngắn. Xóa khách hàng, cấu hình thanh toán hoặc dữ liệu ảnh hưởng nhiều người nên có quyền riêng và lý do bắt buộc.
Chọn xóa trực tiếp hay yêu cầu xác nhận
Có thể cho phép xóa trực tiếp khi
- Bản ghi chưa phát sinh dữ liệu liên quan quan trọng.
- Người thao tác là người tạo và bản ghi chưa được chia sẻ.
- Hệ thống có thể khôi phục trong thời hạn đã công bố.
- Tác động được hiển thị rõ trước khi xác nhận.
Nên có quyền hoặc bước duyệt riêng khi
- Bản ghi ảnh hưởng đến báo cáo, hợp đồng, thanh toán hoặc nhiều người dùng.
- Thao tác kéo theo xóa tệp hoặc dữ liệu ở hệ thống khác.
- Khôi phục cần can thiệp kỹ thuật hoặc có thể không đầy đủ.
- Có nghĩa vụ giữ dữ liệu trong một khoảng thời gian nhất định.
Khôi phục cần được kiểm thử như một chức năng độc lập
Nhiều sản phẩm có cờ xóa mềm nhưng chưa kiểm tra đường khôi phục. Khi phục hồi khách hàng, các liên hệ và quyền truy cập có trở lại không? Nếu mã hoặc email đã được bản ghi mới sử dụng, hệ thống xử lý xung đột thế nào?
Lịch sử thao tác tối thiểu nên ghi loại đối tượng, mã bản ghi, người yêu cầu, người xác nhận, thời điểm, lý do và kết quả. Không sao chép toàn bộ nội dung nhạy cảm vào lịch sử chỉ để chứng minh rằng thao tác đã xảy ra. Bài quản lý dữ liệu nhạy cảm trong quy trình AI nêu các nguyên tắc giảm dữ liệu lưu dư thừa, cũng áp dụng cho tính năng này.
Tiêu chí nghiệm thu phải bao gồm trường hợp xóa thành công, bị chặn vì còn dữ liệu liên quan, thiếu quyền, gửi lặp, thất bại giữa chừng, khôi phục trong hạn và yêu cầu đã hết hạn. Đội sản phẩm cũng cần kiểm tra kết quả trên báo cáo, tích hợp và trang danh sách.
Nếu chức năng xóa chạm tới nhiều bảng dữ liệu hoặc yêu cầu nghiệp vụ chưa thống nhất, dịch vụ phát triển sản phẩm của Auranium có thể hỗ trợ chốt quan hệ dữ liệu, quyền thao tác và bộ test case trước khi xây.