حل خطأ "insufficient access rights on object id"

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id يبدو شبه مطابق لقريبه الخاص بالإحالة المتقاطعة، لكنه يشير إلى مشكلة مختلفة. هذا الخطأ يتعلق بـالسجلّ الذي تتعامل معه مباشرةً — المستخدم ببساطة لا يستطيع الكتابة إليه.

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

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

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

INSUFFICIENT_ACCESS_OR_READONLY: insufficient access rights on object id: <id>

الـ <id> هو المعرّف المكوّن من 15 أو 18 حرفًا لـالسجلّ الذي حاولت حفظه — وليس سجلًّا مرتبطًا. يستطيع المستخدم المنفِّذ رؤيته، أو حتى قراءته، لكنه لا يملك وصول الكتابة إليه.

اقرأ الرسالة هكذا: “المستخدم المنفِّذ لهذا الإجراء لا يستطيع تحرير (أو حذف) السجلّ <id> الذي ينفِّذ الإجراء عليه."

"object id” مقابل “cross-reference id” — لا تخلط بينهما

هذان الخطآن شقيقان ويُخلط بينهما باستمرار:

	insufficient access rights on object id	insufficient access rights on cross-reference id
أيّ سجلّ يحجبك؟	السجلّ الذي تحفظه	سجلّ مرتبط يشير إليه (lookup / master-detail)
رمز الخطأ المعتاد	INSUFFICIENT_ACCESS_OR_READONLY	INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY
أول ما تُصلحه	وصول التحرير/الحذف لـ هذا السجلّ	وصول القراءة للسجلّ المرتبط

إذا كان المعرّف في الرسالة هو السجلّ الذي نقرت Save عليه، فأنت تقرأ المقال الصحيح. أما إذا كان أصلًا أو مالكًا أو سجلًّا مُشارًا إليه عبر lookup، فراجع بدلًا من ذلك insufficient access rights on cross-reference id.

الخطوة 0 — حدِّد السجلّ

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

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

تأكّد أنه الكائن والسجلّ اللذان توقّعت حفظهما. كل ما يلي يستهدف وصول الكتابة إلى ذلك السجلّ.

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

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

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

2. وصول للقراءة فقط أو لا وصول للسجلّ (المشاركة)

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

• إعداد افتراضي على مستوى المؤسسة من نوع Private بلا قاعدة مشاركة تصل إلى المستخدم.
• المستخدم ليس أعلى من المالك في تسلسل الأدوار.
• السجلّ مُشارَك بصفة Read Only (قاعدة مشاركة، أو فريق، أو مشاركة يدوية)، ما يتيح الفتح لكن ليس الحفظ.

تأكّد عبر زرّ Sharing على السجلّ، ثم وسِّع الوصول إلى Read/Write بقاعدة مشاركة، أو فريق، أو مشاركة يدوية. الفرق بين القراءة والقراءة-الكتابة هنا هو بالضبط ما يفصل “يستطيع الفتح” عن “يستطيع الحفظ”.

3. عدم الوصول للتحرير إلى أصل master-detail

إذا كان السجلّ هو الطرف detail في علاقة master-detail، فإن تحريره يتطلب الوصول إلى أصله. المستخدم الذي يستطيع قراءة الأصل فقط (أو لا يستطيع رؤيته على الإطلاق) لا يستطيع حفظ السجلّ الفرعي — ويُبلغ Salesforce عن ذلك بوصفه نقص صلاحيات وصول على object id الخاص بالسجلّ الفرعي. امنح المستخدم وصول قراءة-كتابة لسجلّ الأصل.

4. سجلّ مقفل أو قيد الموافقة

السجلّ المقفل بعملية موافقة نشطة — أو بـ lock من Apex — لا يستطيع أحد تحريره (باستثناء المسؤولين) حتى تتمّ الموافقة عليه أو سحبه أو فكّ قفله. وهذا يُنتج الخطأ نفسه حتى للمستخدمين الذين يملكون وصول التحرير فعلًا. تحقّق من سجلّ موافقات السجلّ قبل المساس بالأذونات.

سبب إضافي — أتمتة في سياق المستخدم. الـ Flow المُعدّ للتشغيل “في سياق المستخدم” أو Apex المُعلَن بصيغة with sharing يفرض وصول المستخدم المنفِّذ. إذا تعذّر على ذلك المستخدم الكتابة إلى السجلّ، فستفشل الأتمتة بهذا الخطأ حتى لو اختبرها المسؤول بنجاح. إما أن تُشغّل الأتمتة في سياق النظام، أو تمنح المستخدم وصولًا حقيقيًا (الأسباب 1–3).

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

1. استخرج <id> من الخطأ وافتحه — تأكّد أيّ سجلّ فشل.
2. هل السجلّ في عملية موافقة / مقفل؟ ← احسم ذلك أولًا.
3. هل يملك المستخدم صلاحية Edit/Delete للكائن على ذلك الكائن؟ ← أصلح ملف التعريف/مجموعة الأذونات.
4. هل يملك المستخدم وصول قراءة-كتابة للسجلّ (وليس القراءة فقط)؟ ← تحقّق من زرّ Sharing؛ أضِف مشاركة قراءة-كتابة.
5. هل هو سجلّ فرعي في master-detail؟ ← امنح وصول قراءة-كتابة على الأصل.
6. هل تعمل أتمتة في سياق المستخدم؟ ← اختر بين سياق النظام ومنح الوصول.

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

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

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

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

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

ما الفرق بين "insufficient access rights on object id" و"on cross-reference id"؟

‏"On object id" يتعلق بالسجلّ الذي تُدرجه أو تحدّثه أو تحذفه مباشرةً — المستخدم يفتقر إلى صلاحية تحرير/حذف *ذلك* السجلّ. أما "on cross-reference id" فيتعلق بسجلّ *مرتبط* يُوصَل إليه عبر حقل lookup أو master-detail. العائلة نفسها من الأخطاء، لكنّ الهدف معاكس. إذا كان المعرّف في الرسالة هو السجلّ الذي نقرت Save عليه، فهذه هي نسخة object-id.

لماذا يستطيع المسؤول تحرير السجلّ بينما يحصل المستخدم العادي على هذا الخطأ؟

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

المستخدم يملك صلاحية Read للسجلّ — فلماذا ما زال نقص الوصول يظهر عند الحفظ؟

صلاحية القراءة لا تكفي للكتابة. يتطلب التحرير أو الحذف إذن كائن Edit/Delete *إضافةً إلى* وصول قراءة-كتابة للسجلّ. السجلّ المُشارَك بصفة "Read Only" (عبر قاعدة مشاركة، أو تسلسل أدوار، أو مشاركة يدوية) يتيح للمستخدم فتحه لكن ليس حفظ التغييرات، فيظهر ذلك بوصفه نقص صلاحيات وصول عند التحديث.

هل يمكن لسجلّ مقفل أو قيد الموافقة أن يسبّب هذا الخطأ؟

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