استكشاف الأخطاء وإصلاحهاالوصول إلى السجلاتمسؤول Salesforce

مستخدم يرى سجلاً لا يحق له رؤيته: كيف تكتشف السبب

طريقة خطوة بخطوة لتشخيص سبب رؤية مستخدم Salesforce لسجل لا يحق له، عبر الإعدادات الافتراضية للمؤسسة وهرمية الأدوار وقواعد المشاركة والمشاركات.

AgentForceAccess 3 دقيقة قراءة
حزم ضوئية كثيرة متقاربة من ظل مستخدم نحو سجل واحد، مع عدسة مكبّرة

Why can this person see that record? هو السؤال الأكثر شيوعاً حول الوصول في Salesforce — وأصعبها إجابةً بالعين المجرّدة، لأن المنصة لا تقرّر الرؤية في مكان واحد أبداً. فهي تمنح اتحاد عدة آليات. يمنحك هذا الدليل ترتيباً قابلاً للتكرار للعثور على الآلية التي فتحت الوصول.

أولاً، النموذج الذهني

المشاركة في Salesforce تراكمية، والأكثر تساهلاً يفوز. أنت لا تبحث عن قاعدة تسمح بالوصول و قاعدة تحظره. أنت تبحث عن أي منحة واحدة، لأن واحدة تكفي. (للاطّلاع على الطبقات الكاملة، انظر من يستطيع رؤية سجل في Salesforce.)

إذا منحت آلية واحدة فقط الوصول، فإن المستخدم يملكه. مهمتك هي معرفة أيٌّ منها.

الخطوة 1 — اقرأ زر Sharing

على السجل، انقر على Sharing (المتاح للكائنات التي لا يكون الإعداد الافتراضي للمؤسسة فيها عاماً بالكامل). تُظهر القائمة المستخدمين الذين يملكون الوصول وعمود Reason — Owner، Role Hierarchy، Sharing Rule، Manual Share، Team، وهكذا. وفي معظم الحالات يسمّي هذا المتسبّب فوراً.

إذا لم يكن المستخدم مدرجاً هناك أصلاً لكنه ما زال يرى السجل، فاشتبه في تجاوز على مستوى ملف التعريف — انتقل إلى الخطوة 2.

الخطوة 2 — استبعد التجاوزات على مستوى الأذونات

هذه تتجاهل نموذج المشاركة بالكامل:

  • View All Data / Modify All Data (أذونات النظام، مثلاً على ملف تعريف System Administrator).
  • View All / Modify All على مستوى الكائن لذلك الكائن المحدّد.

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

الخطوة 3 — اعبر طبقات المشاركة، من الأعلى إلى الأسفل

إذا كانت منحة مشاركة حقيقية، فحدّد أي طبقة:

الإعداد الافتراضي للمؤسسة مفتوح أكثر من اللازم

إذا كان OWD للكائن هو Public Read Only أو Public Read/Write، فإن الجميع ممّن لديهم وصول إلى الكائن يرون كل سجل. الحل بنيوي — شدّد الإعداد الافتراضي للمؤسسة وامنح الوصول من جديد عن قصد.

هرمية الأدوار تُصعّد الوصول إلى الأعلى

إذا كان المستخدم يعلو مالك السجل في هرمية الأدوار وكان “Grant Access Using Hierarchies” مُفعّلاً، فإنه يرث وصول المالك تلقائياً. وهذه أكثر المفاجآت شيوعاً.

قاعدة مشاركة أوسع من اللازم

قاعدة قائمة على معايير مثل Region = EMEA → share with role X قد تشمل أشخاصاً أكثر بكثير ممّا هو مقصود، خصوصاً بعد تغييرات البيانات أو الأدوار. راجع القواعد التي تستهدف دور المستخدم أو المجموعات العامة أو الإقليم.

مشاركة يدوية أو ضمنية

  • المشاركة اليدوية: استخدم أحدهم زر Share الخاص بالسجل.
  • المشاركة الضمنية: الوصول إلى Account أب يمنح وصول قراءة محدوداً لما يتبعه من Cases وContacts. ينسى الناس هذه باستمرار — وهي دائماً للقراءة فقط.
  • مشاركة Apex المُدارة: أنشأت شيفرة مخصصة المشاركة؛ يُظهرها زر Sharing لكن منشأها في الشيفرة.

الفرق والأقاليم

عضوية فريق الـ Account/Opportunity/Case، أو إقليم مطابق ضمن Enterprise Territory Management، كلٌّ منها يمنح الوصول بشكل مستقل.

الخطوة 4 — تأكّد أنها ليست تأخّر إعادة الاحتساب

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

قائمة تحقّق للتشخيص

  1. زر Sharing ← اقرأ Reason لذلك المستخدم.
  2. ملف التعريف + مجموعات الأذونات ← أي View All / Modify All؟
  3. OWD مفتوح أكثر من اللازم لهذا الكائن؟
  4. المستخدم يعلو المالك في هرمية الأدوار؟
  5. أي قاعدة مشاركة (خصوصاً القائمة على معايير) تشمله؟
  6. مشاركة يدوية أو ضمنية أو Apex؟
  7. عضو فريق أو إقليم مطابق؟
  8. تغيير حديث ← انتظر إعادة الاحتساب.

أول “نعم” هو جوابك — وقد يكون هناك أكثر من مسار يمنح الوصول نفسه. وللمشكلة المعاكسة — مستخدم لا يستطيع رؤية سجل يحق له — انظر قائمة تحقّق تشخيص الوصول المفقود.

القيام بهذا في ثوانٍ بدلاً من فترة ما بعد الظهر

عبور ثماني طبقات لكل زوج مستخدم-سجل، عبر ملفات التعريف ومجموعات الأذونات وست آليات مشاركة، هو بالضبط الكدّ اليدوي الذي يُخفي التعرّض الحقيقي. يقوم AgentForceAccess بذلك نيابةً عنك: اسأل بالإنجليزية البسيطة لماذا يستطيع مستخدم رؤية سجل، فيتتبّع كل طبقة ويستشهد بالمنحة الدقيقة — لتذهب مباشرةً إلى الحل.

الأسئلة الأكثر تكراراً

ما هو أسرع فحص أولي؟

افتح السجل، وانقر على زر Sharing، واقرأ عمود "Reason" لذلك المستخدم. فهو يسمّي الآلية المانحة للوصول — Owner، Role Hierarchy، Sharing Rule، Manual، وهكذا — لمعظم الكائنات القياسية. وتأكّد أيضاً من أن المستخدم لا يملك ببساطة "View All Data" أو "View All" على مستوى الكائن.

زر Sharing يقول "Role Hierarchy" — وماذا الآن؟

شخص يعلو المستخدم في هرمية الأدوار يملك السجل (أو تمّت مشاركته معه)، و"Grant Access Using Hierarchies" مُفعّل لهذا الكائن. لإزالة ذلك الوصول عليك تغيير الهرمية أو الملكية أو تعطيل وصول الهرمية للكائنات المخصصة — وليس أيٌّ منها بالأمر الهيّن.

هل يمكن أن يكون السبب إذن ملف تعريف، لا المشاركة؟

نعم. تتجاوز أذونات "View All Data"/"Modify All Data" و"View All"/"Modify All" على مستوى الكائن نموذج المشاركة بالكامل. إذا كان المستخدم يملك أياً منها، فلن يُخفي أي تغيير في المشاركة السجل — بل يجب عليك إزالة الإذن بدلاً من ذلك.

لماذا يظهر الوصول ويختفي بشكل متقطّع؟

إعادة احتساب المشاركة. بعد تغييرات الملكية أو نقل الأدوار أو تعديل القواعد، يعيد Salesforce معالجة المشاركات بشكل غير متزامن. خلال تلك الفترة قد يبدو الوصول غير متّسق. دع إعادة الاحتساب تكتمل قبل أن تستنتج وجود خطأ في الإعداد.

شاهده على مؤسستك أنت

يشرح AgentForceAccess بلغة واضحة وبسيطة لماذا يستطيع أي مستخدم رؤية أي سجل أو ملف — عبر كل آلية مشاركة في Salesforce.

اطلب وصولاً مبكراً