English
日本語Phân quyền Salesforce không phải là bật hoặc tắt quyền truy cập cho từng người một cách thủ công. Đây là một hệ thống nhiều lớp, cho phép công ty kiểm soát chính xác ai được xem gì, ai được sửa gì, và ai không nên thấy gì cả, ngay cả khi mọi người cùng dùng chung một hệ thống.
Với nhiều SMB, nỗi lo lớn nhất khi triển khai CRM không phải là chi phí, mà là việc dữ liệu nhạy cảm bị lộ ra ngoài phạm vi cần thiết. Bài viết này đi qua từng cơ chế phân quyền Salesforce thực tế, từ cơ bản đến chi tiết, để bạn hiểu rõ công cụ nào dùng cho việc gì.
Phân quyền Salesforce gồm nhiều lớp, không chỉ một công tắc bật tắt duy nhấtNhân viên mới có cần xem toàn bộ dữ liệu khách hàng của cả công ty không? Câu trả lời gần như luôn là không, và phân quyền Salesforce chính là công cụ để đảm bảo điều đó.
Vì sao quan trọng
Vì sao phân quyền Salesforce quan trọng hơn nhiều người nghĩ
Rủi ro không đến từ việc ai đó cố tình đánh cắp dữ liệu. Phần lớn sự cố liên quan đến quyền truy cập đến từ việc cấp quyền quá rộng ngay từ đầu, rồi không ai xem lại sau đó.
Theo báo cáo State of Identity & Data Security 2026 của Lepide, khoảng 80% tổ chức được khảo sát xác nhận có tình trạng cấp quyền truy cập dữ liệu nhạy cảm vượt quá mức cần thiết cho vai trò công việc thực tế. Con số này cho thấy vấn đề không phải là thiếu công cụ phân quyền, mà là thiếu thói quen thiết lập và rà soát đúng cách ngay từ đầu.
Lớp nền tảng
Profile: lớp phân quyền cơ bản nhất
Mỗi người dùng Salesforce được gán đúng một Profile, quy định những chức năng cơ bản họ được phép làm: có được tạo Opportunity không, có được xóa Contact không, có được xem báo cáo tài chính không. Profile giống như một bộ đồng phục chức danh, xác định phạm vi công việc chung của một nhóm vai trò.
Vấn đề của Profile là nó khá cứng nhắc: nếu hai nhân viên cùng Profile nhưng cần một quyền khác biệt nhỏ, công ty thường buộc phải tạo hẳn một Profile mới, dẫn đến số lượng Profile phình to và khó quản lý theo thời gian.
Lớp mở rộng
Permission Set: thêm quyền linh hoạt mà không cần đổi Profile
Đây là cách giải quyết đúng vấn đề cứng nhắc của Profile. Permission Set cho phép cấp thêm quyền cụ thể cho một hoặc vài người, mà không cần tạo Profile riêng cho họ. Ví dụ, một sales bình thường không được xem báo cáo doanh thu toàn công ty, nhưng một sales cụ thể đang kiêm nhiệm vai trò phân tích có thể được gán thêm Permission Set để xem đúng phần đó, trong khi Profile gốc của họ không đổi.
Cách tiếp cận này giúp giữ số lượng Profile ở mức tối thiểu, đồng thời vẫn linh hoạt xử lý các trường hợp ngoại lệ mà không phá vỡ cấu trúc phân quyền chung.
Ai xem được record nào
Role Hierarchy và Organization-Wide Defaults
Profile và Permission Set quyết định người dùng được làm những hành động gì, nhưng chưa quyết định họ được xem những bản ghi dữ liệu cụ thể nào. Đây là vai trò của hai cơ chế khác: Organization-Wide Defaults, viết tắt là OWD, thiết lập mức chia sẻ mặc định cho mỗi loại dữ liệu, ví dụ mặc định một sales chỉ xem được khách hàng do chính mình phụ trách.
Role Hierarchy sau đó cho phép cấp quản lý tự động xem được dữ liệu của cấp dưới mình, theo đúng sơ đồ tổ chức công ty, mà không cần cấp quyền thủ công cho từng quản lý.
Trong trường hợp cần chia sẻ dữ liệu ra ngoài phạm vi mặc định, ví dụ một nhóm dự án liên phòng ban cần cùng xem một tập khách hàng, Sharing Rules được dùng để tạo ngoại lệ có kiểm soát, thay vì hạ thấp mức bảo mật chung của toàn hệ thống.
Chi tiết nhất
Field-Level Security: ẩn từng trường thông tin cụ thể
Đôi khi vấn đề không nằm ở việc ai được xem một khách hàng, mà là ai được xem một trường thông tin cụ thể trong hồ sơ khách hàng đó. Ví dụ, cả sales và kế toán đều cần xem hồ sơ cùng một khách hàng, nhưng chỉ kế toán mới cần thấy trường công nợ hoặc điều khoản thanh toán chi tiết.
Field-Level Security giải quyết đúng mức độ chi tiết này, cho phép ẩn hoặc hiện từng trường dữ liệu theo Profile hoặc Permission Set, độc lập với việc người đó có quyền xem toàn bộ record hay không.
Bắt đầu từ đâu
Nên bắt đầu thiết lập phân quyền Salesforce như thế nào
Với hầu hết SMB, nguyên tắc thực dụng nhất là bắt đầu từ mức hạn chế nhất, sau đó mở rộng dần khi thực sự cần, thay vì mở rộng hết rồi mới siết lại. Thiết lập OWD ở mức riêng tư nhất cho các đối tượng dữ liệu nhạy cảm, dùng Role Hierarchy để tự động mở quyền cho cấp quản lý, và chỉ dùng Sharing Rules cho những ngoại lệ thực sự cần thiết.
Đây cũng là một phần quan trọng trong câu hỏi rộng hơn về quyền sở hữu dữ liệu khách hàng mà nhiều công ty chỉ nghĩ đến khi đã quá muộn. Phân quyền đúng ngay từ đầu là cách rẻ nhất để tránh phải xử lý hậu quả sau này.
Muốn được tư vấn cách phân quyền phù hợp với cơ cấu công ty bạn?
Đặt lịch tư vấn miễn phí, đội ngũ Sonix sẽ giúp bạn thiết kế mô hình phân quyền đúng ngay từ đầu, không cần sửa lại sau khi đã có dữ liệu.
Sonix: Your success is our happiness.
Để lại lời nhắn cho chúng tôi