الملكية ودورة الحياة

🌐 متاح أيضًا بـ28 لغة

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

صورة مولّدة بالذكاء الاصطناعي

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

الوحدة 8 من 10 في فصل معمارية بيانات Salesforce، الفصل 3 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: للعلاقات عواقب · التالي: الحفاظ على اتساق البيانات

السؤال الذي تجيب عنه هذه الوحدة: من يملك السجل، وما الذي يحدث له طوال حياته؟

عندما أنظر إلى نموذج بيانات، لا أريد أن أعرف فقط ما هي الكائنات وكيف تترابط. أريد أن أعرف ما الذي يحدث للسجلات بمرور الوقت. من يُنشئها؟ من يملكها؟ من يستطيع إعادة إسنادها؟ ما الذي يحدث حين تتغير العلاقة التجارية، وحين لا تعود نشطة؟ هل ينبغي حذفها يومًا، وكم مدة الاحتفاظ بها؟ لا شيء من ذلك يظهر على ERD، أي مخطط الكيانات والعلاقات: صناديق نموذج البيانات وخطوطه في الفصل 2. وكله معمارية بيانات. وعلى Salesforce، الملكية هي المكان الذي يصطدم فيه نموذج البيانات بنموذج الأمان.

الملكية أكثر من اسم في حقل

يرى المسؤولون Owner (المالك) على السجل ويقرؤونه كتسمية: Bart يملك هذا الحساب، وLisa تملك تلك الحالة. قد يعني ذلك. لكن على Salesforce، الملكية أيضًا آلية من آليات المنصة. على الكائنات التي لها مالك، يحدد المالك من يستطيع رؤية السجل عبر التسلسل الهرمي للأدوار، وقواعد المشاركة، وقوائم الانتظار، وإعادة الإسناد. لذا عندما أسأل «من يملك هذا السجل؟» فأنا لا أسأل اسم من يظهر على الصفحة. بل أسأل أي سلوك أمني وسلوك دورة حياة نربطه به. يمكن أن يكون المالك مستخدمًا، أو بالنسبة لبعض الكائنات، ومنها الكائنات المخصصة والحالات والعملاء المحتملون، قائمة انتظار (queue)، وفي الحالتين يحصل المالك على وصول كامل إلى السجل (Understanding Sharing (opens in a new tab)).

لهذا أفصل المسؤولية التجارية عن ملكية السجل. أحيانًا يكونان الشخص نفسه. وأحيانًا لا. إذا قال العمل إن المرسِل (dispatcher) مسؤول عن توصيلة، فهذا لا يجعل المرسِل تلقائيًا هو المالك. يمكن أن تعيش المسؤولية في حقل خاص بها بينما تُضبط الملكية لدعم الأمان والحجم. لا تدع الاثنين يختلطان لمجرد أن كليهما يستخدم كلمة «مالك».

جدول المشاركة: حيث تصبح الملكية وصولًا

بعض الناس لا يعرفون حتى ما هو جدول المشاركة. وكل معماري بيانات ينبغي أن يعرفه.

معظم المشاركة الخاصة بسجل تُحفظ في كائن مشاركة (share object) مرتبط، وهو نسخة Salesforce من قائمة التحكم في الوصول (Understanding Sharing (opens in a new tab)). للحساب AccountShare، ولجهة الاتصال ContactShare، والكائن المخصص يحصل على كائنه الخاص: لـ Truck__c كائن Truck__Share (Sharing a Record Using Apex (opens in a new tab)). وكل صف فيه يقول أربعة أشياء:

• أي سجل: معرّف الأب.
• من: مستخدم، أو مجموعة (مجموعة عامة، أو مجموعة دور، أو منطقة (territory)).
• كم: Read، أو Edit، أو All (وصول كامل).
• لماذا: سبب الصف (row cause). Owner للمالك، وRule لقاعدة مشاركة، وManual لمشاركة يدوية، وTeam، والأسباب الضمنية التي تضيفها Salesforce بين الحساب وأبنائه، وأسباب يعرّفها المطوّر لمشاركة Apex.

في الصف أفتح Workbench وأستعلم عن جدول المشاركة بينما أشارك سجلًا، فترى الصفوف تظهر وتختفي. وعندما يسأل أحدهم «لماذا يستطيع هذا الشخص رؤية ذلك؟»، فالإجابة غالبًا موجودة في صف، مع سببه.

لكن ليس كل شيء موجودًا فيه. الإعداد الافتراضي على مستوى المؤسسة ليس صفًا. والتسلسل الهرمي للأدوار لا يُخزَّن هناك أيضًا: فوصول الأشخاص الأعلى من المالك يُحسب حين الحاجة إليه. وView All وModify All وView All Data وModify All Data تتخطى جدول المشاركة تمامًا (Sharing a Record Using Apex (opens in a new tab)). وكما أقولها في الصف: حدّد View All وتكون قد تجاوزت جدول المشاركة.

وتشارك Salesforce أيضًا بعض السجلات نيابةً عنك، بسبب طريقة ارتباطها. هذه هي المشاركة الضمنية (implicit sharing)، وهي تعمل بين الحساب وأبنائه. إذا كنت تستطيع رؤية جهة اتصال أو حالة أو فرصة، فيمكنك أيضًا قراءة الحساب الذي تنتمي إليه. ويحصل مالك الحساب على وصول إلى جهات اتصال الحساب وحالاته وفرصه، بمستوى يحدده دور المالك (Implicit Sharing (opens in a new tab)). وفي الإصدارات الأخيرة تحسب Salesforce بعض وصول الأبناء هذا حين الحاجة إليه بدلًا من تخزينه كصفوف، لذا لا تتفاجأ حين لا يُظهره استعلام لجدول المشاركة. أنا أعطيك هنا تلميحًا فقط؛ والتفاصيل في العلاقات والمشاركة المدمجة.

استثناء آخر، لحين يكون لديك عدد كبير من المستخدمين الخارجيين. مستخدمو المجتمع ذوو الحجم الكبير (High-volume community users)، أي تراخيص Customer Community المصممة لآلاف العملاء إلى ملايينهم، ليس لهم دور، ولا يمكن أن يكونوا في مجموعات عامة، ولا يمكن منحهم سجلات عبر قواعد المشاركة أو المشاركات اليدوية (About High-Volume Community or Site Users (opens in a new tab)؛ Sharing Rule Considerations (opens in a new tab)). بالنسبة لهم، جدول المشاركة ليس هو الحل: فهم يصلون إلى السجلات عبر مجموعات المشاركة (sharing sets)، التي تطابق حساب السجل أو جهة اتصاله مع حساب المستخدم أو جهة اتصاله. وهذا أحد أسباب قابلية تلك التراخيص للتوسع. وتغطي دورة Sharing and Visibility ذلك في المشاركة مع المستخدمين الخارجيين.

وتذكّر الوحدة 7: الكائن التفصيلي ليس له كائن مشاركة على الإطلاق. فوصوله يأتي من كائن مشاركة الرئيسي ومن Sharing Setting على حقل رئيسي-تفصيلي.

لماذا يهتم معماري البيانات؟ لأن الملكية تُكتب في هذا الجدول. كل تغيير في المالك، وكل قاعدة مشاركة جديدة، وكل مستخدم ينتقل بين الأدوار أو المجموعات، يعني أن Salesforce تضيف صفوفًا وتزيل أخرى. مع بضعة آلاف من السجلات لا يلاحظ أحد. ومع عشرة ملايين، ومستخدم واحد يملك معظمها، تلك هي إعادة الحساب التي سنقابلها بعد قليل.

معلومة للاختبار. كائن المشاركة لكائن مخصص اسمه Object__Share، مثل Truck__Share. الكائن التفصيلي ليس له كائن مشاركة: فوصوله يأتي من الرئيسي. وعندما يتغير مالك السجل، تُزال مشاركاته اليدوية، بينما تبقى مشاركة Apex ذات السبب الذي يعرّفه المطوّر.

هنا يسلّم نموذج البيانات الراية لنموذج الأمان، وأنا أُدرّس البقية في دورة Sharing and Visibility Architect: «22 طريقة لمشاركة سجل» عند Steve، والإعدادات الافتراضية على مستوى المؤسسة، والملكية، وقوائم الانتظار، والتسلسل الهرمي للأدوار، والعلاقات والمشاركة المدمجة للمشاركات الضمنية، والمشاركة البرمجية والشيفرة الآمنة لأسباب مشاركة Apex. وفي هذه الدورة، يجمع الفصل 12 ذلك كله للبشر والتطبيقات والوكلاء.

أحيانًا تكون الملكية موروثة

في الوحدة السابقة رأينا أن الابن في علاقة رئيسي-تفصيلي ليس له مالك خاص به؛ بل يتبع أباه. وهذا غالبًا صحيح تمامًا. هل يحتاج العمل إلى مالك مختلف لكل بند في توصيلة؟ لا. التوصيلة تملك دورة الحياة والبند ينتمي إليها. لهذا يحدث تصميم العلاقات وتصميم الملكية معًا: حين اخترت رئيسي-تفصيلي، كنت قد اتخذت بالفعل جزءًا من قرار الملكية.

من يملك السجلات التي تُنشئها الأنظمة؟

والآن يصبح الأمر مثيرًا للاهتمام. شخص يُنشئ حسابًا، وربما يصبح هو المالك. لكن نظام ERP يرسل 100,000 معاملة خلال الليل. من يملكها؟ مستخدم التكامل؟ قائمة انتظار؟ مالك إقليمي يُستنتج من البيانات؟ حساب نظام لم يفكر فيه أحد منذ خمس سنوات؟ والآن يُنشئ الوكلاء سجلات أيضًا.

موقفي: الأمر يعتمد على ما إذا كانت الملكية مهمة للمشاركة. مستخدم التكامل، أو مستخدم الوكيل، مستخدم صالح، ويمكنه أن يملك السجلات. إذا كانت الملكية تقود الوصول في ذلك الكائن (عبر التسلسل الهرمي للأدوار أو قواعد المشاركة)، فأسند السجلات إلى المالك الصحيح: مستخدم حقيقي، أو قائمة انتظار، أو مستخدم مخصص للملكية. وإذا لم تكن كذلك، فقد يكون إبقاء مستخدم النظام مالكًا هو الخيار الأفضل، لأن سجل التدقيق عندئذ يقود مباشرة إلى ما أنشأ السجل.

وفي الحالتين، قرّر ذلك عن قصد. حساب تكامل يملك كل شيء صار بهدوء جزءًا من معمارية الأمان لديك، ويجب أن يعرف أحد ما الذي يحدث إذا عُطّل يومًا.

الملكية قد تصبح مشكلة حجم

التوزيع مهم أيضًا. عشرة ملايين سجل موزعة على آلاف المالكين شكل. وعشرة ملايين سجل يملكها مستخدم واحد شكل مختلف جدًا. تسمي Salesforce ذلك انحراف بيانات الملكية (ownership data skew) حين يملك مستخدم واحد أكثر من 10,000 سجل من كائن ما (Ownership Data Skew (opens in a new tab)). ويحدث عادةً حين يركن أحدهم كل شيء على مستخدم واحد أو قائمة انتظار واحدة: كل العملاء المحتملين غير المُسندين على مستخدم مؤقت، وكل سجل تكامل على مستخدم التكامل. ولا ضرر منه حتى ينتقل ذلك المستخدم في التسلسل الهرمي للأدوار، أو يدخل مجموعة تعتمد عليها قاعدة مشاركة أو يخرج منها. عندها يجب على Salesforce تعديل عدد هائل من مدخلات المشاركة، فتحصل على عمليات إعادة حساب طويلة.

والإرشادات عملية. وزّع الملكية على مستخدمين أكثر حيث تستطيع. وإذا كان لا بد لمستخدم واحد أن يملك الكثير، فأبقِه خارج التسلسل الهرمي للأدوار؛ وإذا احتاج إلى دور، فضعه في دور خاص به في القمة ولا تنقله، وأبقِه خارج المجموعات العامة التي تستخدمها قواعد المشاركة (Ownership Data Skew (opens in a new tab)). والتفكير نفسه ينطبق على الأب ذي الأبناء الكثيرين جدًا من الوحدة السابقة، انحراف الأب والابن (parent-child skew).

إذن التوزيع جزء من النموذج المادي. لا تسأل فقط كم عدد السجلات؛ بل اسأل كيف تتوزع. هذه نسخة أخرى من «عدد الأصفار» عند Steve: ليس فقط كم صفرًا، بل أين تتركز الأصفار. يتعمق الجزء 2 في الانحراف؛ وهنا أريدك أن تراه قادمًا. وتعود إليه دورة Sharing and Visibility في المشاركة على نطاق واسع.

«المالك الافتراضي» يصبح معمارية

إليك نمطًا أراه طوال الوقت. لا أحد يعرف من ينبغي أن يملك شيئًا ما، فيقول أحدهم: «أسندها كلها إلى مستخدم التكامل فحسب»، أو «أنشئ مستخدمًا عامًا اسمه System». ربما يكون ذلك صحيحًا. لكن لا تفعله عن طريق الصدفة. للافتراضي المؤقت عادة أن يصبح دائمًا: بعد عامين ينتمي كل سجل إلى integration@company.com، ولا أحد يتذكر السبب، وتغييره يصبح مشروعًا. هذا هو اختبار قابلية التراجع من الفصل 1: قبل أن تعطي مليون سجل لمالك واحد، اسأل ما الذي يتطلبه تغيير ذلك لاحقًا.

إعادة الإسناد حدث في دورة الحياة

المالكون يتغيرون. المندوبون يغادرون، والمناطق تنتقل، والفرق يُعاد تنظيمها، والمناطق الإقليمية يُعاد توازنها. ما الذي يعتمد على المالك: المشاركة، والأتمتة، والتقارير، وقوائم الانتظار، والتصعيدات، والتكاملات؟ إذا كان تغيير المالك يغيّر من يستطيع رؤية السجل، فإعادة الإسناد ليست تنظيفًا إداريًا. إنها حدث أمني، ومع مليون سجل فهي حدث تشغيلي أيضًا. راقب جدول المشاركة حين يحدث ذلك: تُزال المشاركات اليدوية حين يتغير المالك، بينما تنجو مشاركة Apex ذات السبب الذي يعرّفه المطوّر من التغيير (Understanding Sharing (opens in a new tab)). في الصف أشارك سجلًا مع شخص ما، ثم أغيّر المالك، فيفقد الشخص الوصول. والقاعة تتفاجأ دائمًا.

وتذكّر أن الملكية ليست هي الوصول. المالك ليس الشخص الوحيد الذي يحتاج إلى رؤية السجل، ولدى Salesforce طرق كثيرة لمنح الوصول: التسلسل الهرمي للأدوار، وقواعد المشاركة، والفرق، والمناطق، والمشاركة اليدوية والبرمجية. تتعمق دورة Sharing and Visibility في ذلك، بدءًا من «22 طريقة لمشاركة سجل» عند Steve. أما نقطة المعماري فأبسط: لا تستخدم الملكية لحل كل مشكلة وصول. إذا كنت تنقل المالكين هنا وهناك فقط ليتمكن أحدهم من رؤية سجل، فأنت على الأرجح تحل المشكلة الخطأ.

الإنشاء ليس إلا البداية

كثير من نمذجة البيانات يتوقف عند الإنشاء: الحقول، والكائن، والعلاقة، وانتهى. لكن السجل قد يعيش عشر سنوات. يُحدَّث، ويغيّر مالكيه، ويغيّر حالته وعلاقاته، ويصبح غير نشط، ويصير تاريخًا، وقد يحتاج إلى أرشفة، وربما يومًا ما إلى حذف. المعمارية ليست فقط كيف يولد السجل. بل ما الذي يحدث من الولادة إلى الموت.

Click to enlarge

لا تحذف لمجرد أن الشيء قديم

يتوقف شريك تجزئة عن إرسال العمل. هل تحذف الحساب؟ ليس تلقائيًا: فتوصيلاته ومطالباته وتاريخ فوترته ما زالت مهمة. تتقاعد شاحنة. هل تحذفها، ومعها تاريخ توصيلاتها ومطالبات الأضرار؟ قد لا يعود الشيء نشطًا، لكن بياناته ما زالت كذلك. لذا أفصل غير النشط عن الزائل. الشاحنة المتقاعدة يمكن أن تبقى في النموذج؛ والموظف السابق يمكن أن يظل يظهر في تاريخ التدقيق. يجب أن تحتفظ المعمارية بالحقائق المهمة بعد انتهاء العلاقة التشغيلية.

الاحتفاظ متطلب تجاري

والجانب الآخر: الاحتفاظ بكل شيء إلى الأبد ليس معمارية أيضًا. التخزين ينمو، والتقارير تتباطأ، والبحث يصبح أكثر ضجيجًا، وقانون الخصوصية قد يقول إن بعض البيانات يجب أن تذهب. لذا أريد إجابة صريحة عن كم مدة احتفاظنا بهذا؟ «Salesforce تحتفظ به» ليست سياسة احتفاظ.

وفي الغالب، هذا سؤال عن بيانات المعاملات. البيانات المرجعية، المنتجات وأنواع الخدمات ومراكز التوزيع، لا تصبح ضخمة، وتشير إليها سجلات أخرى، لذا فهي تبقى عادةً. وبيانات العملاء في المنتصف: قد يأتي يوم تُنهي فيه حياة عميل، خاصة حين تحتفظ ببيانات شخصية وينتهي سبب الاحتفاظ بها. لكن الحجم في المعاملات: التوصيلات، والطلبات، والحالات، والمواعيد، التي تُنشأ كل يوم، إلى الأبد. هذا ما ينمو إلى مئات الملايين من الصفوف، وهنا يجب أن يكون الاحتفاظ صريحًا: ربما سنتان من البيانات التشغيلية في المؤسسة، وسبع سنوات من السجلات المالية في مكان ما، وتسعون يومًا لبعض الصور. هذه قواعد عمل، وإذا لم يسأل أحد، فينبغي أن يسأل المعماري.

أقولها في الصف منذ سنوات: إذا لم تكن تؤرشف اليوم، فهل ستؤرشف يومًا ما؟ لعبارة «سنتعامل مع الأمر لاحقًا» طريقة في أن تصبح مشروع طوارئ عند ثلاثمئة مليون سجل. وفي الجزء 2 وحدة كاملة عن الأرشفة والإزالة، مبنية على السؤال نفسه.

Steve Trucking: من يملك التوصيلة؟

تُنشأ التوصيلة من بيان شحنة شريك التجزئة، بواسطة تكامل، نحو 3,300 مرة في اليوم. من يملكها؟ ليس شريك التجزئة؛ فتلك علاقة تجارية. وليس المستلم. الطاقم ينفّذها، لكن هل ينبغي أن يتغير مالك السجل في كل مرة تتبادل فيها الطواقم الشاحنات؟ المرسِل؟ مركز التوزيع؟ قائمة انتظار؟ مستخدم التكامل الذي أنشأها؟

والآن طبّق هذه الوحدة، بدءًا من السؤال الذي يحسم الأمر: هل تقود الملكية وصول أي أحد إلى التوصيلات؟ في Steve Trucking لا. يرى المرسِلون التوصيلات الخاصة بمركز توزيعهم، وترى الطواقم تلك التي على مساراتها، ويرى كل تاجر تجزئة توصيلاته في بوابة الشركاء. ولا شيء من ذلك يعتمد على من يملك السجل؛ بل يأتي من مركز التوزيع، والمسار، والشريك.

لذا إجابتي: مستخدم التكامل يملك التوصيلات. إنه مثال جيد على مستخدم نظام يملك سجلات عن قصد:

• سجل التدقيق صادق. مالك كل توصيلة يقول من أين أتت: تكامل بيان الشحنة.
• الوصول يأتي من المشاركة، لا من الملكية. قواعد المشاركة القائمة على المعايير على مركز التوزيع تعطي فريق كل مركز توصيلاته؛ ويصل الشركاء إلى توصيلاتهم عبر البوابة.
• الانحراف مستبعد بالتصميم. بمعدل 3,300 في اليوم، يتجاوز مستخدم التكامل 10,000 توصيلة في ثلاثة أيام، لذا فهو انحراف ملكية من اليوم الأول، ولا بأس بذلك إذا خططنا له. مستخدم التكامل ليس له دور، لذا لا شيء فوقه في تسلسل هرمي يحتاج إلى إعادة حساب، ويبقى خارج المجموعات العامة التي تستخدمها قواعد المشاركة لدينا.
• لا أحد يعيد إسناد التوصيلات. تتبادل الطواقم الشاحنات ويغيّر المرسِلون نوباتهم، والمالك لا يتحرك أبدًا، لذا لا عاصفة إعادة إسناد ولا مشاركات يدوية تضيع.

ودوّن ما الذي يحدث إذا عُطّل ذلك المستخدم أو استُبدل يومًا، لأنه يملك الآن ملايين السجلات. هذا هو القرار الذي سيحتاج الفريق التالي إلى العثور عليه.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. يُنشئ الوكلاء السجلات ويغيّرونها بسرعة الآلة. إذا أنشأ وكيل 100,000 سجل تحت مستخدمه الخاص، فإن «سنصلح المالك لاحقًا» تصبح انحرافًا، وإعادة حساب للمشاركة، ومشروع تنظيف. قرّر قاعدة ملكية الوكيل قبل أن ينطلق، مستخدمًا السؤال نفسه: هل الملكية مهمة للمشاركة هنا؟

ما الذي يقرره المعماري هنا

• هل تمثّل الملكية مسؤولية تجارية، أم آلية أمان، أم كليهما، وأين تعيش المسؤولية إن لم تكن في Owner.
• هل تحتاج السجلات إلى مالك خاص بها أم ينبغي أن ترثه من أب.
• من يملك السجلات التي تُنشئها التكاملات والوكلاء، بحسب ما إذا كانت الملكية تقود المشاركة.
• كيف تتوزع الملكية، وكيف نتجنب انحراف الملكية حين يتعين على مستخدم واحد أن يملك الكثير.
• متى تصبح السجلات غير نشطة، ومتى تُؤرشف، وكم مدة الاحتفاظ بها، ومتى يكون الحذف صائبًا.

عندما تنظر إلى نموذج مادي، لا تسأل فقط أين تُخزَّن البيانات. اسأل من يملكها اليوم، ومن قد يملكها غدًا، وما الذي يحدث حين لا نعود نحتاج إليها. التالي: حتى مع الكائن والحقول والعلاقات والمالك الصحيحة، ما زال على البيانات أن تبقى جديرة بالثقة.

للاستزادة

• Apex Developer Guide، Understanding Sharing (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-13): المالكون (مستخدم، أو قائمة انتظار للكائنات المخصصة والحالات والعملاء المحتملين) يحصلون على وصول كامل؛ معظم المشاركة تعيش في كائن مشاركة مرتبط؛ التسلسل الهرمي للأدوار يُشتق أثناء التشغيل؛ تُزال المشاركات اليدوية حين يتغير المالك، وتبقى المشاركة المُدارة عبر Apex؛ وقيم سبب الصف.
• Apex Developer Guide، Sharing a Record Using Apex (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-13): AccountShare، MyCustomObject__Share؛ الكائنات التفصيلية ليس لها كائن مشاركة؛ وما لا يتتبعه كائن المشاركة (OWD، والتسلسل الهرمي للأدوار، وView All وModify All).
• Salesforce Help، Implicit Sharing (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-13): الوصول بين الحساب وجهات اتصاله وحالاته وفرصه.
• Salesforce Help، About High-Volume Community or Site Users (opens in a new tab) وSharing Rule Considerations (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-13): لا أدوار، ولا قواعد مشاركة أو مشاركات يدوية؛ بل مجموعات المشاركة بدلًا منها.
• دورة Sharing and Visibility Architect: «22 طريقة لمشاركة سجل» عند Steve، الإعدادات الافتراضية على مستوى المؤسسة، والملكية، وقوائم الانتظار، والتسلسل الهرمي للأدوار، العلاقات والمشاركة المدمجة، المشاركة البرمجية والشيفرة الآمنة، المشاركة مع المستخدمين الخارجيين، المشاركة على نطاق واسع.
• Salesforce Developers، Designing Record Access for Enterprise Scale، Ownership Data Skew (opens in a new tab) وParent-Child Data Skew (opens in a new tab)، (بالإنجليزية، تم التحقق في 2026-10-02).