Quyền sở hữu và vòng đời

🌐 Cũng có bằng 28 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 8 trong 10 của chương Kiến trúc dữ liệu Salesforce, chương 3 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Quan hệ có hệ quả · Tiếp theo: Giữ dữ liệu nhất quán

Câu hỏi mô-đun này trả lời: Ai sở hữu bản ghi, và chuyện gì xảy ra với nó trong suốt cuộc đời của nó?

Khi nhìn vào một mô hình dữ liệu, tôi không chỉ muốn biết các đối tượng là gì và chúng nối với nhau thế nào. Tôi muốn biết chuyện gì xảy ra với các bản ghi theo thời gian. Ai tạo ra chúng? Ai sở hữu chúng? Ai có thể giao lại chúng? Chuyện gì xảy ra khi quan hệ nghiệp vụ thay đổi, khi chúng không còn hoạt động? Chúng có bao giờ nên bị xóa không, và chúng ta giữ chúng bao lâu? Không điều nào trong số đó hiện lên trên một ERD, sơ đồ quan hệ thực thể (entity relationship diagram): các hộp và đường nối trong mô hình dữ liệu của chương 2. Tất cả đều là kiến trúc dữ liệu. Và trên Salesforce, quyền sở hữu là nơi mô hình dữ liệu và mô hình bảo mật va vào nhau.

Quyền sở hữu không chỉ là một cái tên trong một trường

Quản trị viên thấy Owner trên một bản ghi và đọc nó như một nhãn: Bart sở hữu tài khoản này, Lisa sở hữu trường hợp kia. Nó có thể mang nghĩa đó. Nhưng trên Salesforce, quyền sở hữu còn là một cơ chế của nền tảng. Trên các đối tượng có chủ sở hữu, chủ sở hữu quyết định ai thấy được bản ghi thông qua phân cấp vai trò, quy tắc chia sẻ, hàng đợi và việc giao lại. Vì vậy khi tôi hỏi “ai sở hữu bản ghi này?”, tôi không hỏi tên ai hiện trên trang. Tôi hỏi chúng ta đang gắn hành vi bảo mật và vòng đời nào vào nó. Chủ sở hữu có thể là một người dùng, hoặc với một số đối tượng, trong đó có đối tượng tùy chỉnh, trường hợp và khách hàng tiềm năng, là một hàng đợi, và dù là gì thì chủ sở hữu cũng có toàn quyền truy cập bản ghi (Understanding Sharing (opens in a new tab)).

Đó là lý do tôi tách trách nhiệm nghiệp vụ khỏi quyền sở hữu bản ghi. Đôi khi chúng là cùng một người. Đôi khi không. Nếu nghiệp vụ nói một điều phối viên chịu trách nhiệm cho một lần giao hàng, điều đó không tự động biến điều phối viên thành chủ sở hữu. Trách nhiệm có thể nằm trong một trường riêng trong khi quyền sở hữu được đặt để hỗ trợ bảo mật và quy mô. Đừng để hai thứ bị lẫn lộn chỉ vì cả hai đều dùng từ “chủ sở hữu”.

Bảng chia sẻ: nơi quyền sở hữu trở thành quyền truy cập

Có người thậm chí không biết bảng chia sẻ là gì. Mọi kiến trúc sư dữ liệu đều nên biết.

Phần lớn việc chia sẻ của một bản ghi được giữ trong một đối tượng chia sẻ (share object) liên quan, phiên bản danh sách kiểm soát truy cập (access control list) của Salesforce (Understanding Sharing (opens in a new tab)). Tài khoản có AccountShare, Liên hệ có ContactShare, và một đối tượng tùy chỉnh có đối tượng riêng của nó: Truck__c có Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Mỗi dòng trong đó nói bốn điều:

• Bản ghi nào: ID của bản ghi cha.
• Ai: một người dùng, hoặc một nhóm (một nhóm công khai, nhóm của một vai trò, một lãnh thổ).
• Bao nhiêu: Read, Edit, hoặc All (toàn quyền truy cập).
• Vì sao: lý do của dòng (row cause). Owner cho chủ sở hữu, Rule cho một quy tắc chia sẻ, Manual cho một lần chia sẻ thủ công, Team, các lý do ngầm định mà Salesforce thêm vào giữa một tài khoản và các bản ghi con của nó, và các lý do mà lập trình viên tự định nghĩa cho chia sẻ bằng Apex.

Trong lớp, tôi mở Workbench và truy vấn bảng chia sẻ trong lúc chia sẻ một bản ghi, và bạn nhìn các dòng xuất hiện rồi biến mất. Khi ai đó hỏi “vì sao người này thấy được cái kia?”, câu trả lời thường nằm sẵn trong một dòng, kèm lý do của nó.

Nhưng không phải mọi thứ đều nằm trong đó. Mặc định toàn tổ chức không phải là một dòng. Phân cấp vai trò cũng không được lưu ở đó: quyền truy cập của những người ở trên chủ sở hữu được tính ra khi cần. Và View All, Modify All, View All Data và Modify All Data bỏ qua bảng chia sẻ hoàn toàn (Sharing a Record Using Apex (opens in a new tab)). Như tôi nói trong lớp: đánh dấu View All là bạn đã đi vòng qua bảng chia sẻ.

Salesforce cũng tự chia sẻ một số bản ghi cho bạn, vì cách chúng liên quan với nhau. Đây là chia sẻ ngầm định, và nó hoạt động giữa một tài khoản và các bản ghi con của nó. Nếu bạn thấy được một liên hệ, trường hợp hay cơ hội, bạn cũng đọc được tài khoản mà nó thuộc về. Và chủ sở hữu tài khoản có quyền truy cập vào các liên hệ, trường hợp và cơ hội của tài khoản, ở mức do vai trò của chủ sở hữu quy định (Implicit Sharing (opens in a new tab)). Trong các bản phát hành gần đây, Salesforce tính một phần quyền truy cập vào bản ghi con đó khi cần thay vì lưu thành các dòng, nên đừng ngạc nhiên khi truy vấn bảng chia sẻ không thấy nó. Ở đây tôi chỉ gợi ý cho bạn; chi tiết nằm trong Relationships and Built-In Sharing.

Thêm một ngoại lệ nữa, cho khi bạn có rất nhiều người dùng bên ngoài. Người dùng cộng đồng khối lượng lớn (high-volume community users), các giấy phép Customer Community được xây cho hàng nghìn đến hàng triệu khách hàng, không có vai trò, không thể nằm trong nhóm công khai, và không thể được trao bản ghi qua quy tắc chia sẻ hay chia sẻ thủ công (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). Với họ, bảng chia sẻ không phải là câu trả lời: họ đến được bản ghi qua bộ chia sẻ (sharing sets), vốn khớp tài khoản hay liên hệ của một bản ghi với tài khoản hay liên hệ của chính người dùng. Đó là một trong những lý do các giấy phép này mở rộng được quy mô. Khóa Sharing and Visibility đề cập điều này trong Sharing with External Users.

Và hãy nhớ mô-đun 7: một đối tượng chi tiết hoàn toàn không có đối tượng chia sẻ. Quyền truy cập của nó đến từ đối tượng chia sẻ của master và thiết lập Sharing Setting trên trường chính-chi tiết.

Vì sao kiến trúc sư dữ liệu phải quan tâm? Vì quyền sở hữu được ghi vào bảng này. Mỗi lần đổi chủ sở hữu, mỗi quy tắc chia sẻ mới, mỗi người dùng chuyển vai trò hay nhóm đều có nghĩa là Salesforce thêm và xóa các dòng. Với vài nghìn bản ghi thì không ai để ý. Với mười triệu, khi một người dùng sở hữu phần lớn số đó, đó chính là lần tính lại mà chúng ta sẽ gặp ngay sau đây.

Kiến thức hay ra thi. Đối tượng chia sẻ của một đối tượng tùy chỉnh có tên Object__Share, như Truck__Share. Một đối tượng chi tiết không có đối tượng chia sẻ: quyền truy cập của nó đến từ master. Và khi chủ sở hữu của một bản ghi thay đổi, các chia sẻ thủ công của nó bị xóa, trong khi chia sẻ bằng Apex với lý do riêng của lập trình viên vẫn được giữ.

Đây là nơi mô hình dữ liệu chuyển giao cho mô hình bảo mật, và phần còn lại tôi dạy trong khóa Sharing and Visibility Architect: Steve’s 22 Ways to Share a Record, Org-Wide Defaults, Ownership, Queues and the Role Hierarchy, Relationships and Built-In Sharing cho các chia sẻ ngầm định, và Programmatic Sharing and Secure Code cho các lý do chia sẻ bằng Apex. Trong khóa này, chương 12 gom tất cả lại cho con người, ứng dụng và tác tử.

Đôi khi quyền sở hữu được thừa hưởng

Ở mô-đun trước chúng ta đã thấy một bản ghi con chính-chi tiết không có chủ sở hữu riêng; nó theo bản ghi cha. Điều đó thường hoàn toàn đúng. Nghiệp vụ có cần một chủ sở hữu khác nhau cho mỗi mặt hàng trên một lần giao hàng không? Không. Lần giao hàng sở hữu vòng đời và mặt hàng thuộc về nó. Đây là lý do thiết kế quan hệ và thiết kế quyền sở hữu diễn ra cùng nhau: khi chọn chính-chi tiết, bạn đã đưa ra một phần quyết định về quyền sở hữu rồi.

Ai sở hữu các bản ghi do hệ thống tạo ra?

Giờ thì thú vị rồi. Một người tạo một tài khoản, và có thể họ trở thành chủ sở hữu. Nhưng một ERP gửi 100.000 giao dịch qua đêm. Ai sở hữu chúng? Người dùng tích hợp? Một hàng đợi? Một chủ sở hữu theo vùng được suy ra từ dữ liệu? Một tài khoản hệ thống mà năm năm nay không ai nghĩ tới? Và giờ tác tử cũng tạo bản ghi.

Lập trường của tôi: còn tùy vào việc quyền sở hữu có quan trọng cho chia sẻ hay không. Người dùng tích hợp, hay người dùng tác tử, là một người dùng hợp lệ, và nó có thể sở hữu các bản ghi. Nếu quyền sở hữu quyết định quyền truy cập trên đối tượng đó (qua phân cấp vai trò hay quy tắc chia sẻ), hãy giao bản ghi cho đúng chủ sở hữu: một người dùng thật, một hàng đợi, hay một người dùng chuyên làm chủ sở hữu. Nếu không, giữ người dùng hệ thống làm chủ sở hữu có thể là lựa chọn tốt hơn, vì khi đó dấu vết kiểm toán dẫn thẳng về thứ đã tạo ra bản ghi.

Dù theo cách nào, hãy quyết định có chủ ý. Một tài khoản tích hợp sở hữu mọi thứ đã lặng lẽ trở thành một phần của kiến trúc bảo mật của bạn, và cần có ai đó biết chuyện gì xảy ra nếu nó từng bị vô hiệu hóa.

Quyền sở hữu có thể trở thành vấn đề quy mô

Sự phân bố cũng quan trọng. Mười triệu bản ghi trải ra cho hàng nghìn chủ sở hữu là một hình dáng. Mười triệu bản ghi do một người dùng sở hữu là một hình dáng rất khác. Salesforce gọi đó là lệch dữ liệu sở hữu (ownership data skew) khi một người dùng sở hữu hơn 10.000 bản ghi của một đối tượng (Ownership Data Skew (opens in a new tab), tiếng Anh). Nó thường xảy ra khi ai đó dồn mọi thứ cho một người dùng hay hàng đợi: mọi khách hàng tiềm năng chưa được giao cho một người dùng giữ chỗ, mọi bản ghi tích hợp cho người dùng tích hợp. Nó vô hại cho đến khi người dùng đó di chuyển trong phân cấp vai trò, hoặc vào hay ra một nhóm mà quy tắc chia sẻ phụ thuộc vào. Khi đó Salesforce phải điều chỉnh một số lượng khổng lồ mục chia sẻ, và bạn gặp những lần tính toán lại kéo dài.

Hướng dẫn rất thực tế. Hãy phân tán quyền sở hữu cho nhiều người dùng hơn khi có thể. Nếu một người dùng buộc phải sở hữu nhiều, hãy giữ họ ngoài phân cấp vai trò; nếu họ cần một vai trò, hãy đặt họ vào vai trò riêng ở trên cùng và đừng di chuyển họ, và giữ họ ngoài các nhóm công khai mà quy tắc chia sẻ dùng đến (Ownership Data Skew (opens in a new tab), tiếng Anh). Cách nghĩ tương tự áp dụng cho bản ghi cha có quá nhiều con ở mô-đun trước, lệch dữ liệu cha-con.

Vì vậy sự phân bố là một phần của mô hình vật lý. Đừng chỉ hỏi bao nhiêu bản ghi; hãy hỏi chúng được phân bố thế nào. Đó là một phiên bản khác của Số chữ số 0: không chỉ bao nhiêu chữ số 0, mà các chữ số 0 tập trung ở đâu. Phần 2 đi sâu vào lệch dữ liệu; ở đây tôi muốn bạn thấy nó đang đến. Khóa Sharing and Visibility quay lại chủ đề này trong Sharing at Scale.

“Chủ sở hữu mặc định” trở thành kiến trúc

Đây là một khuôn mẫu tôi gặp suốt. Không ai biết ai nên sở hữu một thứ gì đó, nên ai đó nói: “Cứ giao hết cho người dùng tích hợp,” hoặc “tạo một người dùng chung tên là System.” Có thể điều đó đúng. Nhưng đừng làm nó một cách vô tình. Một giá trị mặc định tạm thời có thói quen trở thành vĩnh viễn: hai năm sau mọi bản ghi thuộc về integration@company.com, không ai nhớ tại sao, và thay đổi nó là cả một dự án. Đó là Phép thử khả năng đảo ngược của chương 1: trước khi giao một triệu bản ghi cho một chủ sở hữu, hãy hỏi sau này thay đổi điều đó sẽ tốn những gì.

Giao lại là một sự kiện vòng đời

Chủ sở hữu thay đổi. Nhân viên kinh doanh nghỉ việc, lãnh thổ dịch chuyển, đội ngũ tái cơ cấu, khu vực được cân bằng lại. Những gì phụ thuộc vào chủ sở hữu: chia sẻ, tự động hóa, báo cáo, hàng đợi, leo thang, tích hợp? Nếu đổi chủ sở hữu làm thay đổi ai thấy được bản ghi, việc giao lại không phải là dọn dẹp quản trị. Đó là một sự kiện bảo mật, và với một triệu bản ghi thì còn là một sự kiện vận hành. Hãy theo dõi bảng chia sẻ khi việc đó xảy ra: các chia sẻ thủ công bị xóa khi chủ sở hữu thay đổi, trong khi chia sẻ bằng Apex với lý do riêng của lập trình viên vẫn tồn tại qua thay đổi (Understanding Sharing (opens in a new tab)). Trong lớp, tôi chia sẻ một bản ghi với một người, đổi chủ sở hữu, và người đó mất quyền truy cập. Cả lớp lúc nào cũng ngạc nhiên.

Và hãy nhớ rằng quyền sở hữu không giống quyền truy cập. Chủ sở hữu không phải là người duy nhất cần thấy một bản ghi, và Salesforce có nhiều cách để cấp quyền truy cập: phân cấp vai trò, quy tắc chia sẻ, đội, lãnh thổ, chia sẻ thủ công và bằng lập trình. Khóa Sharing and Visibility đi sâu vào những thứ đó, bắt đầu với Steve’s 22 Ways to Share a Record. Điểm của kiến trúc sư đơn giản hơn: đừng dùng quyền sở hữu để giải mọi bài toán truy cập. Nếu bạn đang chuyển chủ sở hữu qua lại chỉ để ai đó thấy được một bản ghi, có lẽ bạn đang giải sai bài toán.

Tạo ra chỉ là khởi đầu

Rất nhiều việc mô hình hóa dữ liệu dừng lại ở việc tạo: các trường, đối tượng, quan hệ, xong. Nhưng bản ghi có thể sống mười năm. Nó được cập nhật, đổi chủ sở hữu, đổi trạng thái và quan hệ, ngừng hoạt động, trở thành lịch sử, có thể cần lưu trữ, và một ngày nào đó có thể bị xóa. Kiến trúc không chỉ là cách bản ghi được sinh ra. Mà là những gì xảy ra từ lúc sinh ra đến lúc mất đi.

Click to enlarge

Đừng xóa chỉ vì một thứ đã cũ

Một Đối tác bán lẻ ngừng gửi việc. Xóa tài khoản? Không tự động: các lần giao hàng, khiếu nại và lịch sử thanh toán của họ vẫn quan trọng. Một chiếc xe tải nghỉ hưu. Xóa nó, cùng lịch sử giao hàng và các khiếu nại hư hỏng của nó? Thứ đó có thể không còn hoạt động, nhưng dữ liệu của nó thì vẫn còn. Vì vậy tôi tách không hoạt động khỏi đã biến mất. Một chiếc xe tải nghỉ hưu có thể ở lại trong mô hình; một nhân viên cũ vẫn có thể xuất hiện trong lịch sử kiểm toán. Kiến trúc phải giữ những sự thật quan trọng sau khi quan hệ vận hành kết thúc.

Lưu giữ là một yêu cầu nghiệp vụ

Mặt kia: giữ mọi thứ mãi mãi cũng không phải là kiến trúc. Dung lượng lưu trữ tăng, báo cáo chậm đi, tìm kiếm nhiễu hơn, và luật về quyền riêng tư có thể yêu cầu một số dữ liệu phải bị xóa. Vì vậy tôi muốn một câu trả lời rõ ràng cho chúng ta giữ cái này bao lâu? “Salesforce giữ nó” không phải là một chính sách lưu giữ.

Và phần lớn, đây là câu hỏi về dữ liệu giao dịch. Dữ liệu tham chiếu, như sản phẩm, loại dịch vụ, trung tâm phân phối, không trở nên khổng lồ, và các bản ghi khác trỏ đến nó, nên nó thường được giữ lại. Dữ liệu khách hàng nằm ở giữa: có thể đến một ngày bạn cho một khách hàng “hết vòng đời”, nhất là khi bạn đang giữ dữ liệu cá nhân và lý do để giữ nó không còn. Nhưng khối lượng nằm ở các giao dịch: các lần giao hàng, đơn hàng, trường hợp, cuộc hẹn, được tạo ra mỗi ngày, mãi mãi. Đó là thứ phình lên hàng trăm triệu dòng, và đó là nơi việc lưu giữ phải được nói rõ: có thể hai năm dữ liệu vận hành trong org, bảy năm hồ sơ tài chính ở đâu đó, chín mươi ngày cho một số ảnh. Đó là các quy tắc nghiệp vụ, và nếu chưa ai hỏi, kiến trúc sư nên hỏi.

Tôi đã nói điều này trong lớp nhiều năm: nếu hôm nay bạn không lưu trữ, liệu bạn có bao giờ lưu trữ không? “Để sau tính” thường trở thành một dự án khẩn cấp ở mức ba trăm triệu bản ghi. Phần 2 có cả một mô-đun về lưu trữ và xóa bỏ dữ liệu, xây trên chính câu hỏi này.

Steve Trucking: ai sở hữu một lần giao hàng?

Một lần giao hàng được tạo từ bảng kê hàng của Đối tác bán lẻ, bởi một tích hợp, khoảng 3.300 lần mỗi ngày. Ai sở hữu nó? Không phải Đối tác bán lẻ; đó là một quan hệ nghiệp vụ. Không phải Người nhận. Tổ giao hàng thực hiện nó, nhưng bản ghi có nên đổi chủ sở hữu mỗi khi các tổ đổi xe tải không? Điều phối viên? Trung tâm phân phối? Một hàng đợi? Người dùng tích hợp đã tạo ra nó?

Giờ hãy áp dụng mô-đun này, bắt đầu với câu hỏi quyết định mọi thứ: quyền sở hữu có quyết định quyền truy cập của ai đó vào các lần giao hàng không? Ở Steve Trucking thì không. Điều phối viên thấy các lần giao hàng của trung tâm phân phối của họ, tổ giao hàng thấy các lần giao trên tuyến của mình, và mỗi nhà bán lẻ thấy các lần giao của riêng mình trong cổng thông tin đối tác. Không điều nào trong số đó phụ thuộc vào ai sở hữu bản ghi; nó đến từ trung tâm phân phối, tuyến và đối tác.

Vậy câu trả lời của tôi: người dùng tích hợp sở hữu các lần giao hàng. Đây là một ví dụ tốt về một người dùng hệ thống sở hữu bản ghi một cách có chủ ý:

• Dấu vết kiểm toán trung thực. Chủ sở hữu của mỗi lần giao hàng cho biết nó đến từ đâu: tích hợp bảng kê hàng.
• Quyền truy cập đến từ chia sẻ, không phải từ quyền sở hữu. Các quy tắc chia sẻ dựa trên tiêu chí theo trung tâm phân phối trao cho đội của mỗi DC các lần giao hàng của họ; các đối tác đến được lần giao của mình qua cổng thông tin.
• Lệch dữ liệu được loại bỏ ngay từ thiết kế. Với 3.300 mỗi ngày, người dùng tích hợp vượt 10.000 lần giao hàng trong ba ngày, nên đó là lệch dữ liệu sở hữu ngay từ ngày đầu, và điều đó không sao nếu chúng ta lên kế hoạch cho nó. Người dùng tích hợp không có vai trò, nên không có gì ở trên nó trong phân cấp phải tính lại, và nó nằm ngoài các nhóm công khai mà quy tắc chia sẻ của chúng ta dùng.
• Không ai giao lại các lần giao hàng. Các tổ đổi xe tải và điều phối viên đổi ca, còn chủ sở hữu không bao giờ thay đổi, nên không có cơn bão giao lại và không có chia sẻ thủ công nào bị mất.

Và hãy ghi lại chuyện gì xảy ra nếu người dùng đó có lúc bị vô hiệu hóa hay bị thay thế, vì giờ nó sở hữu hàng triệu bản ghi. Đó là quyết định mà nhóm tiếp theo sẽ cần tìm thấy.

Ngoài kỳ thi: AI thay đổi điều gì. Tác tử tạo và thay đổi bản ghi với tốc độ máy móc. Nếu một tác tử tạo 100.000 bản ghi dưới người dùng riêng của nó, “sửa chủ sở hữu sau” sẽ trở thành lệch dữ liệu, một lần tính lại chia sẻ và một dự án dọn dẹp. Hãy quyết định quy tắc sở hữu của tác tử trước khi nó đi vào hoạt động, với cùng câu hỏi: ở đây quyền sở hữu có quan trọng cho chia sẻ không?

Kiến trúc sư quyết định gì ở đây

• Quyền sở hữu đại diện cho trách nhiệm nghiệp vụ, một cơ chế bảo mật, hay cả hai, và trách nhiệm nằm ở đâu nếu không nằm trong Owner.
• Bản ghi cần chủ sở hữu riêng hay nên thừa hưởng nó từ bản ghi cha.
• Ai sở hữu các bản ghi do tích hợp và tác tử tạo ra, tùy vào việc quyền sở hữu có quyết định chia sẻ hay không.
• Quyền sở hữu được phân bố thế nào, và làm sao tránh lệch dữ liệu sở hữu khi một người dùng buộc phải sở hữu nhiều.
• Khi nào bản ghi ngừng hoạt động, khi nào chúng được lưu trữ, chúng được giữ bao lâu, và khi nào xóa là đúng.

Khi nhìn vào một mô hình vật lý, đừng chỉ hỏi dữ liệu được lưu ở đâu. Hãy hỏi hôm nay ai sở hữu nó, ngày mai ai có thể sở hữu nó, và chuyện gì xảy ra khi chúng ta không còn cần nó. Tiếp theo: ngay cả với đúng đối tượng, trường, quan hệ và chủ sở hữu, dữ liệu vẫn phải luôn đáng tin cậy.

Tìm hiểu thêm

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-13: chủ sở hữu (một người dùng, hoặc một hàng đợi với đối tượng tùy chỉnh, trường hợp và khách hàng tiềm năng) có toàn quyền truy cập; phần lớn việc chia sẻ nằm trong một đối tượng chia sẻ liên quan; phân cấp vai trò được tính ra lúc chạy; chia sẻ thủ công bị xóa khi chủ sở hữu thay đổi, chia sẻ do Apex quản lý được giữ lại; các giá trị lý do của dòng.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-13: AccountShare, MyCustomObject__Share; đối tượng chi tiết không có đối tượng chia sẻ; những gì đối tượng chia sẻ không theo dõi (OWD, phân cấp vai trò, View All và Modify All).
• Salesforce Help, Implicit Sharing (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-13: quyền truy cập giữa một tài khoản và các liên hệ, trường hợp và cơ hội của nó.
• Salesforce Help, About High-Volume Community or Site Users (opens in a new tab) và Sharing Rule Considerations (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-13: không có vai trò, không có quy tắc chia sẻ hay chia sẻ thủ công; thay vào đó là bộ chia sẻ.
• Khóa Sharing and Visibility Architect (tiếng Anh): Steve’s 22 Ways to Share a Record, Org-Wide Defaults, Ownership, Queues and the Role Hierarchy, Relationships and Built-In Sharing, Programmatic Sharing and Secure Code, Sharing with External Users, Sharing at Scale.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) và Parent-Child Data Skew (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-02.