"Insufficient access rights on cross-reference id" को कैसे ठीक करें

INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: insufficient access rights on cross-reference id Salesforce की सबसे गलत समझी जाने वाली त्रुटियों में से एक है। पहली प्रवृत्ति होती है उस रिकॉर्ड पर permissions जाँचने की जिसे आप सेव कर रहे हैं — पर यह त्रुटि लगभग कभी उस रिकॉर्ड के बारे में होती ही नहीं। यह उस दूसरे रिकॉर्ड के बारे में होती है जिसकी ओर वह इशारा करता है।

यह गाइड बताती है कि इस संदेश का क्या अर्थ है और आपको इसे ठीक करने का एक दोहराने योग्य तरीका देती है।

इस त्रुटि का असल मतलब क्या है

जब आप कोई रिकॉर्ड insert या update करते हैं, तो Salesforce उन हर रिकॉर्ड की भी जाँच करता है जिनका वह संदर्भ देता है — lookup या master-detail फ़ील्ड्स, ownership, या related-list ऑपरेशनों के ज़रिए। यदि चल रहा यूज़र उन संदर्भित रिकॉर्ड्स में से किसी एक तक नहीं पहुँच सकता, तो पूरा ऑपरेशन insufficient access rights on cross-reference id: <id> के साथ अस्वीकार हो जाता है।

<id> उस रिकॉर्ड की 15- या 18-अक्षरों वाली ID है जहाँ तक यूज़र नहीं पहुँच सकता — न कि उस रिकॉर्ड की जो सेव हो रहा है। यही अंतर इसे ठीक करने की पूरी कुंजी है।

इस संदेश को ऐसे पढ़ें: “इस क्रिया को चला रहा यूज़र उस संबंधित रिकॉर्ड <id> तक नहीं पहुँच सकता जिसकी ओर यह रिकॉर्ड इशारा करता है।“

चरण 0 — cross-reference रिकॉर्ड को पहचानें

त्रुटि से ID कॉपी करें और उसे सीधे खोलें:

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

अब आपको पता है कि कौन-सा object और रिकॉर्ड आपको रोक रहा है (कोई parent Account, किसी lookup पर कोई Contact, एक owner, एक संबंधित Case, इत्यादि)। नीचे दिया गया हर चरण उसी रिकॉर्ड को लक्ष्य बनाता है।

पाँच कारण, संभावना के क्रम में

1. object permission न होना

यूज़र के profile या permission sets में संदर्भित object पर Read (या Create/Edit) नहीं है। sharing के मूल्यांकन से पहले object permissions ही पहला द्वार होती हैं — देखें object permissions बनाम record sharing। ज़रूरी CRUD को किसी permission set के ज़रिए प्रदान करें।

2. lookup फ़ील्ड पर field-level security

यूज़र उस फ़ील्ड को देख या संपादित नहीं कर सकता जो संदर्भ रखती है। यदि FLS उस lookup फ़ील्ड को छिपा देती है, तो उसमें लिखने की क्रिया विफल हो जाती है। यूज़र के profile/permission sets पर उस फ़ील्ड के लिए field-level security जाँचें।

यूज़र के पास object access तो है पर उस विशिष्ट संबंधित रिकॉर्ड तक record access नहीं है। कारण: कोई sharing rule न होने के साथ एक Private org-wide default, या यूज़र role hierarchy में owner से ऊपर नहीं है। संबंधित रिकॉर्ड पर Sharing बटन से पुष्टि करें, फिर किसी sharing rule, team, या manual share से पहुँच बढ़ाएँ।

4. automation का यूज़र के context में चलना

ऐसे Flows जो “How to run the flow → in user context” पर सेट हैं, या with sharing घोषित किया गया Apex, चल रहे यूज़र की permissions को लागू करते हैं। यदि वह यूज़र संबंधित रिकॉर्ड तक नहीं पहुँच सकता, तो automation इसी त्रुटि के साथ विफल हो जाता है — भले ही एडमिन ने इसे ठीक से जाँचा हो।

समाधान A (उपयुक्त होने पर अनुशंसित): Flow को system context में / Apex को without sharing के साथ चलाएँ, ताकि automation चल रहे यूज़र से सीमित न हो — इसका उपयोग केवल तभी करें जब यूज़र को वास्तव में सीधी पहुँच की ज़रूरत न होनी चाहिए।
समाधान B: यूज़र को संबंधित रिकॉर्ड तक वास्तविक पहुँच प्रदान करें (कारण 1–3)।

5. हटाया गया, खाली, या गलत-स्वरूप वाला संदर्भ

lookup किसी ऐसे रिकॉर्ड की ओर इशारा करता है जो हटा दिया गया था, कभी अस्तित्व में था ही नहीं, या ID खाली/गलत है (data loads और integrations में आम)। Salesforce गुम रिकॉर्ड्स को insufficient access के रूप में बताता है। सेव करने से पहले पुष्टि करें कि ID किसी जीवित रिकॉर्ड तक पहुँचती है।

एक दोहराने योग्य फ़िक्स चेकलिस्ट

त्रुटि से <id> निकालें और उसे खोलें — object और रिकॉर्ड को पहचानें।
क्या यूज़र के पास उस object पर object Read/Edit है? → profile/permission set ठीक करें।
क्या यूज़र के पास lookup फ़ील्ड पर field-level security है? → FLS ठीक करें।
क्या यूज़र के पास उस विशिष्ट रिकॉर्ड तक record access है? → Sharing बटन जाँचें; एक share जोड़ें।
क्या कोई automation user context में चल रहा है? → system context बनाम पहुँच प्रदान करने में से तय करें।
क्या संदर्भित ID अब भी किसी जीवित रिकॉर्ड तक पहुँचती है? → data/integration ठीक करें।

पहली विफल होने वाली जाँच ही आपका मूल कारण है।

यह त्रुटि असल में एक access-tracing समस्या क्यों है

ऊपर दिया गया हर कारण एक ही अंतर्निहित प्रश्न है: क्या इस यूज़र के पास वास्तव में उस संबंधित रिकॉर्ड तक पहुँच है, और किस तंत्र के ज़रिए? CRUD, FLS, और छह sharing तंत्रों के पार इसका उत्तर हाथ से देना थकाऊ है।

AgentForceAccess इसका उत्तर सरल भाषा में देता है — यूज़र और रिकॉर्ड पेस्ट करें, और यह ठीक-ठीक ट्रेस करता है कि कौन-सी permission या share पहुँच प्रदान करती (या रोकती) है, ताकि आप अनुमान लगाना बंद करें कि पाँच कारणों में से किसे आप देख रहे हैं।

अक्सर पूछे जाने वाले सवाल

"cross-reference id" असल में किसका संदर्भ देती है?

यह उस *संबंधित* रिकॉर्ड की Salesforce रिकॉर्ड ID है जिसकी ओर आपकी क्रिया किसी lookup या master-detail फ़ील्ड के ज़रिए इशारा करती है। चल रहे यूज़र के पास उस रिकॉर्ड तक पहुँच नहीं है, इसलिए सेव अस्वीकार हो जाता है। इसे पहचानने के लिए ID को अपने org URL (https://yourdomain.my.salesforce.com/<id>) के अंत में जोड़ें।

एक ही क्रिया एडमिन के लिए क्यों काम करती है पर सामान्य यूज़र के लिए विफल हो जाती है?

एडमिन के पास आमतौर पर "View All"/"Modify All" या "Modify All Data" होता है, जो sharing मॉडल को दरकिनार कर देता है। सामान्य यूज़र को संबंधित रिकॉर्ड पर object permissions, field-level security, या record-level sharing रोक देती है। इसे अलग करके पहचानने के लिए वही क्रिया प्रभावित यूज़र के रूप में दोहराएँ।

क्या किसी Flow को system context में चलाने से कोई असली permission समस्या छिप जाती है?

ऐसा हो सकता है। System context चल रहे यूज़र की sharing और CRUD/FLS को अनदेखा कर देता है, जिससे त्रुटि तो ठीक हो जाती है पर यूज़र को ऐसी पहुँच मिल सकती है जो UI के ज़रिए उसे नहीं मिलनी चाहिए। इसका उपयोग सोच-समझकर करें, और पुष्टि करें कि यूज़र को सचमुच उस संबंधित रिकॉर्ड तक पहुँचने का अधिकार है।

क्या यह त्रुटि किसी हटाए गए या गुम रिकॉर्ड से आ सकती है?

हाँ। यदि lookup किसी ऐसे रिकॉर्ड की ओर इशारा करता है जो हटा दिया गया था, कभी अस्तित्व में था ही नहीं, या ID खाली/गलत-स्वरूप वाली है, तो Salesforce इसे "not found" के बजाय insufficient access के रूप में बताता है। सत्यापित करें कि संदर्भित ID अब भी किसी जीवित रिकॉर्ड तक पहुँचती है।