استكشاف الأخطاءالوصول إلى السجلاتالأخطاء

حل خطأ "insufficient access rights on cross-reference id"

ما معنى خطأ Salesforce ‏"insufficient access rights on cross-reference id" والأسباب الخمسة وراءه وطريقة إصلاحه خطوة بخطوة.

AgentForceAccess 3 دقيقة قراءة
أيقونتا سجلّين متصلتان بشعاع ضوئي مكسور ومتشظٍّ مع رمز تحذير وقفل

INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id هو واحد من أكثر الأخطاء التي يُساء فهمها في Salesforce. الغريزة تدفعك إلى فحص الأذونات على السجلّ الذي تحفظه — لكن الخطأ لا يتعلق بذلك السجلّ تقريبًا أبدًا. إنه يتعلق بـسجلّ آخر يشير إليه.

يشرح هذا الدليل ما تعنيه الرسالة ويمنحك طريقة قابلة للتكرار لإصلاحها.

ماذا يعني الخطأ فعليًا

عند إدراج سجلّ أو تحديثه، يفحص Salesforce أيضًا كل سجلّ يشير إليه — عبر حقول lookup أو master-detail، أو الملكية، أو عمليات القوائم المرتبطة. إذا تعذّر على المستخدم المنفِّذ الوصول إلى أحد تلك السجلات المُشار إليها، تُرفض العملية بأكملها مع الرسالة insufficient access rights on cross-reference id: <id>.

الـ <id> هو المعرّف المكوّن من 15 أو 18 حرفًا للسجلّ الذي لا يستطيع المستخدم الوصول إليه — وليس السجلّ الذي يجري حفظه. هذا التمييز هو المفتاح الكامل لإصلاح المشكلة.

اقرأ الرسالة هكذا: “المستخدم المنفِّذ لهذا الإجراء لا يستطيع الوصول إلى السجلّ المرتبط <id> الذي يشير إليه هذا السجلّ.”

الخطوة 0 — حدِّد سجلّ الإحالة المتقاطعة

انسخ المعرّف من الخطأ وافتحه مباشرةً:

https://yourdomain.my.salesforce.com/<id>

الآن تعرف أيّ كائن وسجلّ يحجبك (Account أصل، أو Contact على حقل lookup، أو مالك، أو Case مرتبط، إلخ). كل خطوة أدناه تستهدف ذلك السجلّ.

الأسباب الخمسة، مرتّبة بحسب الاحتمال

1. إذن كائن مفقود

يفتقر ملف تعريف المستخدم أو مجموعات الأذونات إلى Read (أو Create/Edit) على الكائن المُشار إليه. أذونات الكائن هي البوابة قبل أن تُقيَّم المشاركة على الإطلاق — راجع أذونات الكائن مقابل مشاركة السجلات. امنح صلاحيات CRUD اللازمة عبر مجموعة أذونات.

2. الأمن على مستوى الحقل لحقل الـ lookup

لا يستطيع المستخدم رؤية أو تحرير الحقل الذي يحمل الإحالة. إذا أخفى الـ FLS حقل الـ lookup، فستفشل الكتابة إليه. تحقّق من الأمن على مستوى الحقل لذلك الحقل في ملف تعريف المستخدم/مجموعات الأذونات.

3. عدم الوصول إلى السجلّ المُشار إليه (المشاركة)

يملك المستخدم الوصول إلى الكائن لكن ليس الوصول إلى السجلّ لذلك السجلّ المرتبط تحديدًا. الأسباب: إعداد افتراضي على مستوى المؤسسة من نوع Private بلا قاعدة مشاركة، أو أن المستخدم ليس أعلى من المالك في تسلسل الأدوار. تأكّد عبر زرّ Sharing على السجلّ المرتبط، ثم وسِّع الوصول بقاعدة مشاركة، أو فريق، أو مشاركة يدوية.

4. أتمتة تعمل في سياق المستخدم

الـ Flows المُعدّة للتشغيل عبر “How to run the flow → in user context”، أو Apex المُعلَن بصيغة with sharing، تفرض أذونات المستخدم المنفِّذ. إذا تعذّر على ذلك المستخدم الوصول إلى السجلّ المرتبط، فستفشل الأتمتة بهذا الخطأ حتى لو اختبرها المسؤول بنجاح.

  • الحل أ (المُوصى به عند الاقتضاء): شغّل الـ Flow في سياق النظام / Apex بصيغة without sharing، بحيث لا تتقيّد الأتمتة بالمستخدم المنفِّذ — استخدمه فقط عندما لا يُفترض بالمستخدم بحقّ أن يحتاج إلى وصول مباشر.
  • الحل ب: امنح المستخدم فعليًا الوصول إلى السجلّ المرتبط (الأسباب 1–3).

5. إحالة محذوفة أو فارغة أو مشوّهة

يشير الـ lookup إلى سجلّ تم حذفه، أو لم يكن موجودًا قطّ، أو أن المعرّف فارغ/خاطئ (وهو شائع مع عمليات تحميل البيانات والتكاملات). يُبلغ Salesforce عن السجلات المفقودة بوصفها نقص صلاحيات وصول. تحقّق من أن المعرّف يُفضي إلى سجلّ حيّ قبل الحفظ.

قائمة فحص قابلة للتكرار للإصلاح

  1. استخرج <id> من الخطأ وافتحه — حدِّد الكائن والسجلّ.
  2. هل يملك المستخدم صلاحية Read/Edit للكائن على ذلك الكائن؟ ← أصلح ملف التعريف/مجموعة الأذونات.
  3. هل يملك المستخدم الأمن على مستوى الحقل لحقل الـ lookup؟ ← أصلح الـ FLS.
  4. هل يملك المستخدم الوصول إلى السجلّ لذلك السجلّ تحديدًا؟ ← تحقّق من زرّ Sharing؛ أضِف مشاركة.
  5. هل تعمل أتمتة في سياق المستخدم؟ ← اختر بين سياق النظام أو منح الوصول.
  6. هل ما زال المعرّف المُشار إليه يُفضي إلى سجلّ حيّ؟ ← أصلح البيانات/التكامل.

أول فحص يفشل هو السبب الجذري لديك.

لماذا هذا الخطأ هو في الحقيقة مشكلة تتبُّع وصول

كل سبب أعلاه هو السؤال الكامن نفسه: هل يملك هذا المستخدم فعلًا الوصول إلى ذلك السجلّ المرتبط، وعبر أيّ آلية؟ الإجابة عن ذلك يدويًا عبر CRUD وFLS وستّ آليات مشاركة أمرٌ مُضنٍ.

يجيب AgentForceAccess عن ذلك بلغة واضحة — الصق المستخدم والسجلّ، وسيتتبّع بدقّة أيّ إذن أو مشاركة يمنح (أو يحجب) الوصول، فتتوقّف عن التخمين بشأن أيّ من الأسباب الخمسة تنظر إليه.

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

إلامَ يشير "cross-reference id" فعليًا؟

إنه معرّف سجلّ Salesforce للسجلّ *المرتبط* الذي يشير إليه إجراؤك عبر حقل lookup أو master-detail. المستخدم المنفِّذ لا يملك الوصول إلى ذلك السجلّ، لذا يُرفض الحفظ. أضِف المعرّف إلى عنوان مؤسستك (https://yourdomain.my.salesforce.com/<id>) لتحديده.

لماذا ينجح الإجراء ذاته لدى المسؤول ويفشل لدى مستخدم عادي؟

عادةً ما يملك المسؤولون "View All"/"Modify All" أو "Modify All Data"، وهي تتجاوز نموذج المشاركة. أما المستخدم العادي فيُحجب بسبب أذونات الكائن، أو الأمن على مستوى الحقل، أو المشاركة على مستوى السجلّ للسجلّ المرتبط. أعِد تنفيذ الإجراء بصفتك المستخدم المتأثر لعزل المشكلة.

هل تشغيل الـ Flow في سياق النظام يُخفي مشكلة أذونات حقيقية؟

قد يفعل ذلك. سياق النظام يتجاهل مشاركة المستخدم المنفِّذ وأذونات CRUD/FLS الخاصة به، ما يصلح الخطأ لكنه قد يمنح وصولًا لا يُفترض أن يحظى به المستخدم عبر الواجهة. استخدمه عن قصد، وتأكد أن المستخدم ينبغي له فعلًا أن يصل إلى السجلّ المرتبط.

هل يمكن أن ينشأ هذا الخطأ عن سجلّ محذوف أو مفقود؟

نعم. إذا أشار الـ lookup إلى سجلّ تم حذفه، أو لم يكن موجودًا قطّ، أو كان المعرّف فارغًا/مشوّهًا، فإن Salesforce يُبلغ عنه بوصفه نقص صلاحيات وصول وليس "غير موجود". تحقّق من أن المعرّف المُشار إليه ما زال يُفضي إلى سجلّ حيّ.

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

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

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