Record level-access in Salesforce

Record-Level Access
Đằng sau quyền truy cập dữ liệu trong Salesforce

Mục lục
1. Sơ lược quyền truy cập dữ liệu trong Salesforce
2. Đằng sau cách Salesforce tính toán quyền truy cập
3. Một chút về tính năng mới: Restriction Rules (Beta)
4. Q&A

Sơ lược quyền truy cập dữ liệu
trong Salesforce

Sơ lược quyền truy cập dữ liệu trong Salesforce
2 loại: Object-Level (bao gồm Field-Level) và Record-Level.
Object-Level:
• User có quyền truy cập dữ liệu của một Object hay không,
thấy Field nào trên Object đấy, có thể thực hiện hành động
nào (CRUD).
• Quản lý thông qua Profile và Permission Set. Thường dùng
Profile để đặt giới hạn tiêu chuẩn, Permission Set để mở rộng
nếu cần.

2 loại: Object-Level (bao gồm Field-Level) và
Record-Level.
Record-Level:
• Chủ sở hữu của Record có quyền tối cao
• Who can Delete a record?
• Các công cụ chia sẻ chỉ áp dụng trên các
Record do User khác sở hữu.
• Organization-Wide Defaults
• Role Hierarchy
• Sharing Rules
• Manual Sharing
• Programmatic sharing
• Teams
• Territory Hierarchy

• Xác định quyền truy cập của một User nhất định có thể trở nên tương đối phức tạp.
• Thay đổi trên một Record có thể kích hoạt tính toán quyền truy cập gây ảnh hưởng đến
toàn bộ Org.
⇒ Cần hiểu cách Salesforce tính toán và cấp quyền truy cập ở mức CSDL để thiết kế quyền
truy cập sao cho hiệu quả.
Ngoài ra sẽ hiểu được nguyên lý của hiện tượng Data and Ownership Skews -
Lệch quyền sở hữu...

Đằng sau cách Salesforce tính
toán quyền truy cập

Đằng sau cách Salesforce tính toán quyền truy cập
Thời điểm tính toán quyền truy cập
• Mỗi khi User xem một Record, chạy Report, mở List View hoặc search dữ liệu thông
qua giao diện hay API, Salesforce phải kiểm tra quyền truy cập của User.
• Khó khăn: đối với Org có rất nhiều dữ liệu (hàng trăm Role, hàng nghìn Sharing
Rules, hàng triệu row dữ liệu...) thì thực hiện tính toán quyền truy cập sẽ vô cùng
tốn thời gian, không khả thi khi mà User cần truy cập dữ liệu thời gian thực.

Thời điểm tính toán quyền truy cập
• Mỗi khi User xem một Record, chạy Report, mở List View hoặc search dữ liệu thông
qua giao diện hay API, Salesforce phải kiểm tra quyền truy cập của User.
• Khó khăn: đối với Org có rất nhiều dữ liệu (hàng trăm Role, hàng nghìn Sharing
Rules, hàng triệu row dữ liệu...) thì thực hiện tính toán quyền truy cập sẽ vô cùng
tốn thời gian, không khả thi khi mà User cần truy cập dữ liệu thời gian thực.
⇒ Giải pháp:
• Thực hiện tính toán quyền truy cập khi dữ liệu thay đổi, lưu kết quả vào CSDL
• Duyệt kết quả khi cần xác định quyền truy cập.

Các loại Access Grants - Quyền truy cập
Access Grants Table Sharing Tool
Explicit Grants (quyền tường
minh)
Object Sharing Tables Ownership, Sharing Rules,
Assignment Rules, Teams,
Territory Assignment Rules,
Manual Sharings, Programmatic
Sharings
Group Membership Grants
(quyền thành viên nhóm)
Group Maintenance Tables Public Groups, Queues, Roles,
Territory Member
Inherited Grants (quyền thừa kế) Group Maintenance Tables Roles Hierarchy, Territories
Hierarchy, Group Hierarchy
Implicit Grants (quyền ngầm
định)
Object Sharing Tables Salesforce Built-in Sharing:
Account-
Opportunity/Case/Contact

3 loại Access Grants Table
• Object Record Tables: Đơn giản là Object như Account hoặc CustomObject__c,
chứa dữ liệu bản ghi và thông tin chủ sở hữu.
• Object Sharing Tables: Chứa thông tin Explicit/Implicit grants. Thực tế là các Object
mà cuối tên có từ Share: AccountShare, CustomObject__Share. Đặc biệt hay dùng
trong Apex sharing.
• Group Maintenance Tables: Chứa thông tin Inherited grants. Thực tế lưu thông tin
ai là thành viên nhóm nào trong 2 Object Group và GroupMember.
Xem thêm: https://mohan-chinnappan-n.gitbooks.io/salesforce-sharing/content/access_grants_tables.html

Kịch bản mẫu
• OWD của mọi Object là Private, cấu trúc
Role như hình dưới.

Kịch bản 1
• Maria tạo Account Record A1
• Marc đứng trên Maria trên cây Role
nên Marc có quyền truy cập A1
• Maria: Owner
• Marc: Inherited grant

Kịch bản 2
• Maria share thủ công record A1 cho
Bob.
• Maria và Marc nằm trong role East
Sales Rep
• Bob: Explicit grant
• Maria: Owner, Inherited grant từ
role East Sales Rep
• Marc: Inherited grant từ role Sales
Executive

Kịch bản 3
• Một Admin tạo Sharing rule để
share record của Sales Executive
cho các User thuộc Role Services
Executive và cấp dưới.
• Bob: Explicit grant
• Maria: Owner, Inherited grant từ
role East Sales Rep
Executive
• Frank và Sam: Explicit grant từ
Sharing rule

Kịch bản 4
• Maria chuyển quyền sở hữu cho
Wendy.
• Khi quyền sử hữu bị thay đổi,
Salesforce tự động xoá Explicit
grant nên Bob mất quyền truy cập.
• Sharing rule từ kịch bản 3 cũng mất
tác dụng do chủ sở hữu - Wendy
không nằm trong role Sales
Executive.
• Wendy: Owner
• Maria: Inherited grant từ role West
Sales Rep

Một chút về tính năng mới:
Restriction Rules (Beta)

Một chút về tính năng mới: Restriction Rules (Beta)
Cách giới hạn quyền truy cập đầu tiên?
https://developer.salesforce.com/docs/atlas.en-us.restriction_rules.meta/restriction_rules/restriction_rules_about.htm

Q&A
Tản mạn...
• “View All” và “Modify All” là setting thuộc object level nhưng thực chất đè lên quyền
record-level, cho phép user thấy mọi bản ghi của object
• "View/Modify All Data" cũng tương tự nhưng áp dụng cho mọi object
• Delete/Manual Sharing: cần full access
• Apex Managed Sharing: cần Modify All Data
• Muốn xoá record nhưng ko có full access?
• Modify All -> mở rộng quá...
• Gắn quyền Transfer Records vào profile, chuyển owner sang cho bản thân rồi xoá -> áp
dụng cho mọi object mà user có quyền Edit nên ko hay lắm...
• Dùng apex without sharing -> bị salesforce security scan kêu, phải tự cài đặt check quyền
• Recommended readings: https://engineering.salesforce.com/tagged/architecture-files

Record level-access in Salesforce

Record level-access in Salesforce

Recommended

More Related Content

More from furuCRM株式会社 CEO/Dreamforce Vietnam Founder (20)

Record level-access in Salesforce

Editor's Notes