हायरार्की और दोतरफ़ा डेटा

🌐 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)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 5 (कुल 6 में से) — अध्याय मास्टर डेटा और पहचान, Data Architect कोर्स का अध्याय 6। हर मॉड्यूल अपने आप में पूरा है। पिछला: नक्शा कोई फ़ैसला नहीं है · अगला: चेकपॉइंट 1: Steve Trucking

यह मॉड्यूल किस सवाल का जवाब देता है: जिस डेटा को एक से ज़्यादा सिस्टम संभालते हैं, उसे कैसे मैनेज करें?

आसान आर्किटेक्चर: ग्राहक का मालिक ERP, Salesforce को एक कॉपी, काम खत्म। असली एंटरप्राइज़ इतने साफ़-सुथरे नहीं होते। कानूनी ग्राहक का मालिक ERP है और सेल्स संबंध का Salesforce; एक डिवीज़न SAP में रहती है, खरीदी गई दूसरी डिवीज़न किसी और ERP में; prospects सिर्फ़ Salesforce में मौजूद हैं। फिर कोई चाहता है कि Salesforce यूज़र ERP से नियंत्रित किसी फ़ील्ड को अपडेट करें, और तीर दोनों तरफ़ इशारा करने लगते हैं। जैसा मैं यह पढ़ाते हुए कहता हूँ: “सबसे मुश्किल चीज़ bi-directionals हैं।” इसलिए नहीं कि डेटा दोनों तरफ़ भेजना तकनीकी रूप से मुश्किल है, बल्कि इसलिए कि जब दोनों सिस्टम बदलाव में हिस्सा लेते हैं, तो आपको अधिकार को लेकर बेहद सटीक होना पड़ता है।

दोतरफ़ा डेटा का मतलब दो मास्टर नहीं

बिलिंग पते का मालिक ERP है, और वह Salesforce में कॉपी होता है। एक rep को ग्राहक से पता चलता है कि पता बदल गया है, और बिज़नेस चाहता है कि वह Salesforce छोड़े बिना उसे अपडेट करे। जायज़ बात है। अब डेटा ERP → Salesforce और Salesforce → ERP बहता है। क्या अब बिलिंग पते में Salesforce की भी हिस्सेदारी है? नहीं। इंटीग्रेशन की दिशा अधिकार तय नहीं करती। Rep Salesforce की कॉपी नहीं बदल रहा। आर्किटेक्चर के लिहाज़ से, वह आधिकारिक मान बदलने का अनुरोध कर रहा है। आप ERP का फ़ील्ड नहीं बदल रहे; आप उसे बदलने का अनुरोध कर रहे हैं। Salesforce इंटरफ़ेस है; मास्टर अब भी ERP है।

इससे डिज़ाइन बदल जाता है। अगर फ़ील्ड का मालिक Salesforce होता, तो save और काम खत्म। अगर मालिक ERP है, तो “save” का मतलब है कि Salesforce प्रस्तावित पता भेजता है, ERP उसे जाँचता और स्वीकार करता है, अपना मास्टर अपडेट करता है, और आधिकारिक मान वापस भेजता है। तभी नियंत्रित मान बदला है: अनुरोध → जाँच → स्वीकृति → प्रकाशन, न कि “दोनों सिस्टम अपडेट कर दो और उम्मीद करो कि वे सिंक में रहेंगे।”

Click to enlarge

दोतरफ़ा इंटीग्रेशन से दोतरफ़ा अधिकार पैदा नहीं होता।

जब मास्टर मना कर दे

ERP बदलाव को अस्वीकार कर देता है: ग्राहक निष्क्रिय है, पता ERP का कोई नियम तोड़ता है, यूज़र कानूनी पते नहीं बदल सकता, ERP बंद है, या इस बीच किसी और ने ग्राहक को बदल दिया। अगर Salesforce पहले ही नया पता दिखा चुका है, तो अब हमारे पास दो सच हैं, और मॉड्यूल 1 पहले ही बता चुका है कि कौन जीतता है: ERP का। इसलिए आर्किटेक्चर को अनुरोध किया गया, अभी स्वीकार नहीं हुआ वाली एक स्थिति चाहिए: एक अलग प्रस्तावित मान, एक “pending change” flag, या दिखाने से पहले पुष्टि का इंतज़ार। तरीका use case पर निर्भर करता है। नियम नहीं: अस्वीकार हुए अनुरोध को कभी प्रतिद्वंद्वी सच न बनने दें।

लूप और टक्करें

यह एक क्लासिक मामला है। ERP Salesforce को अपडेट करता है; Salesforce का इंटीग्रेशन एक बदलाव देखता है और उसे ERP को भेजता है; ERP एक अपडेट देखता है और उसे वापस भेजता है। आपने एक बहुत महँगा लूप बना दिया। अच्छा दोतरफ़ा डिज़ाइन जानता है कि बदलाव कहाँ से शुरू हुआ, क्या मास्टर ने उसे स्वीकार किया है, और क्या यह एक नया बिज़नेस बदलाव है या पहले से प्रोसेस हो चुके बदलाव की बस गूँज: स्रोत ID, timestamps, इंटीग्रेशन मेटाडेटा, idempotent प्रोसेसिंग। इंटीग्रेशन वाला अध्याय इसमें गहराई से जाता है। मास्टर डेटा का सिद्धांत सरल है: जानें कि आप बदलाव शुरू कर रहे हैं या किसी बदलाव को दोहरा रहे हैं।

फिर टक्करें। एक आप अध्याय 5 में देख चुके हैं: एक rep Steve’s Plumbing LLC माँगता है जबकि ERP में कोई Steve’s Plumbing L.L.C. टाइप करता है (गवर्न किए गए रिकॉर्ड की रक्षा करें)। यह रही एक और। Salesforce 125 Main Street प्रस्तावित करता है; लगभग उसी पल ERP का एक यूज़र उसे 130 कर देता है। कौन जीतता है? कोई सार्वभौमिक तकनीकी जवाब नहीं है। शायद ERP हमेशा जीतता है क्योंकि फ़ील्ड का मालिक वही है; शायद Salesforce का अनुरोध एक review queue में जाता है; शायद बाद में स्वीकार हुआ बदलाव जीतता है; शायद ERP हर उस अपडेट को अस्वीकार कर देता है जिसका शुरुआती मान बदल चुका है। यह concurrency है, लेकिन इसके नीचे अधिकार का फ़ैसला है, और अगर किसी ने यह तय नहीं किया कि आधिकारिक बदलाव कौन कर सकता है, तो कोई इंटीग्रेशन पैटर्न आपको नहीं बचा सकता।

और एक अकेला फ़ील्ड तो आसान मामला है। पता एक गली, एक शहर, एक पोस्टल कोड है। Salesforce नई गली भेजता है जबकि ERP ने अभी-अभी शहर बदला है। क्या आप गली को अकेले आगे जाने देते हैं? या आप पते को एक ट्रांज़ैक्शन मानते हैं, ताकि सारे फ़ील्ड साथ जाएँ या कोई न जाए, और पूरे बदलाव को अस्वीकार कर देते हैं? कौन-से फ़ील्ड एक समूह की तरह चलेंगे, यह पहली टक्कर से पहले तय करें, बाद में नहीं।

जब भी मैं कोई दोतरफ़ा इंटीग्रेशन देखता हूँ, तो पूछता हूँ: जब दोनों तरफ़ एक ही डेटा बदलें तो क्या होता है? अगर जवाब है “ऐसा शायद नहीं होगा,” तो हमारा काम पूरा नहीं हुआ। कौन जीतता है, क्या हम अस्वीकार करते हैं, queue में डालते हैं, संस्करणों की तुलना करते हैं, समीक्षा करते हैं? क्या फ़ील्ड को दोनों जगह एडिट होना भी चाहिए? कभी-कभी सबसे अच्छा दोतरफ़ा डिज़ाइन किसी एट्रिब्यूट के लिए एक दिशा हटा देता है: Salesforce अनुरोध कर सकता है; स्वीकार किया गया मान सिर्फ़ ERP प्रकाशित करता है। डेटा अब भी दोनों तरफ़ चलता है, लेकिन फ़ील्ड को सिर्फ़ एक सिस्टम मास्टर करता है। यही अंतर सब कुछ है।

हायरार्की भी मास्टर डेटा है

संबंध भी मास्टर डेटा हो सकते हैं। एक ग्लोबल parent, जिसके उत्तरी अमेरिकी और यूरोपीय क्षेत्र हैं, और हर एक की देश-स्तर की सहायक कंपनियाँ: हायरार्की अपने आप में अर्थ रखती है। Parent कौन है? कौन-सी सहायक कंपनी किस कानूनी इकाई के नीचे है? कौन-से accounts ग्लोबल ग्राहक तक roll up होते हैं? इसी से रिपोर्टिंग, territories, कीमतें, कॉन्ट्रैक्ट, क्रेडिट जोखिम, सर्विस, डेटा access और एनालिटिक्स चलते हैं। एक हायरार्की उतनी ही मायने रख सकती है जितने उसके अंदर के रिकॉर्ड, और उसे भी वैसी ही गवर्नेंस चाहिए। (परीक्षा hierarchy management का नाम लेती है; इसे भूल जाना आसान है।)

Salesforce पर account हायरार्की Parent Account फ़ील्ड से बनती है। Lightning की हायरार्की व्यू 2,000 accounts तक दिखाती है, और सिर्फ़ वे जिन्हें यूज़र देख सकता है; हायरार्की में person accounts सपोर्ट नहीं होते; और Account Site किसी कंपनी की अलग-अलग जगहों में फ़र्क़ करता है (Considerations for Using Account Hierarchy (opens in a new tab))। लेकिन Parent Account फ़ील्ड आर्किटेक्चर के सवाल का जवाब नहीं देता: हायरार्की का मालिक कौन है?

परीक्षा-ज्ञान। Account हायरार्की की बुनियादी बातें जानें: यह Parent Account से बनती है; Lightning व्यू 2,000 accounts तक दिखाती है, सिर्फ़ वे जिन्हें यूज़र देख सकता है; person accounts सपोर्ट नहीं होते; और Account Site किसी कंपनी की अलग-अलग जगहों में फ़र्क़ करता है।

एक हायरार्की, कई मास्टर

मेरे अनुभव में, हायरार्की का मास्टर बँटा होता है। उत्तरी अमेरिकी इकाइयाँ SAP से आती हैं, यूरोपीय किसी दूसरे ERP से, नए prospects Salesforce में बनते हैं, और खरीदी गई एक सहायक कंपनी अभी माइग्रेट नहीं हुई। हायरार्की का मालिक कौन है? यह शाखा पर निर्भर है। हर ERP अपनी शाखा नियंत्रित करता है; Salesforce prospect संबंधों को उनके convert होने तक नियंत्रित करता है। यह एक जायज़ आर्किटेक्चर है, जब तक सबको पता हो कि सीमाएँ कहाँ हैं। शाखा-दर-शाखा तय करें।

Click to enlarge

हायरार्की का अधिकार शाखा-दर-शाखा तय किया जा सकता है।

इसलिए Parent Account फ़ील्ड को अधिकार छिपाने न दें। एक यूज़र Salesforce में किसी सहायक कंपनी का parent बदल देता है। तकनीकी रूप से मामूली बात। आर्किटेक्चर के लिहाज़ से, क्या उसने अभी-अभी कंपनी की कानूनी संरचना बदल दी? अगर उस शाखा को ERP मास्टर करता है, तो शायद नहीं, इसलिए Salesforce को इसे रोकना चाहिए, या इसे एक बदलाव-अनुरोध में बदल देना चाहिए। या शायद Salesforce जायज़ तौर पर एक कमर्शियल हायरार्की रखता है जबकि ERP कानूनी हायरार्की रखता है। तब शायद उन्हें एक ही संबंध होना ही नहीं चाहिए।

एक कंपनी की कई जायज़ हायरार्की हो सकती हैं: कानूनी, बिलिंग, सेल्स, सर्विस, भौगोलिक। ग्लोबल parent कॉन्ट्रैक्ट पर हस्ताक्षर करता है, क्षेत्रों को अपने-आप सर्विस मिलती है, बिलिंग एक साझा फ़ाइनेंस इकाई से होती है, सेल्स क्षेत्र के हिसाब से मैनेज होती है। असली हायरार्की कौन-सी है? सभी; वे अलग-अलग सवालों के जवाब देती हैं। गलती यह मान लेना है कि एक ही होनी चाहिए। हर तरह के संबंध के लिए साफ़ अधिकार होना चाहिए: मॉड्यूल 1 का एट्रिब्यूट वाला सिद्धांत, संबंधों पर लागू।

और हर parent-child संबंध मास्टर डेटा नहीं होता। आज की डिलीवरी को एक रूट पर समूह में रखना एक संबंध है, लेकिन यह ट्रांज़ैक्शनल है, एक ऑपरेशनल घटना। ग्राहक की हायरार्की एक टिकाऊ बिज़नेस संबंध बताती है। मॉडल में दोनों parent-child जैसे दिखते हैं; उनका जीवनचक्र एक नहीं है। पूछें कि संबंध का मतलब क्या है और वह मतलब कितने समय तक रहता है।

एक ग्राहक, दो ERP

जब मैं यह पढ़ाता हूँ तो कमरे से पूछता हूँ: किसने ऐसे क्लाइंट के साथ काम किया है जिसके पास एक Salesforce और एक से ज़्यादा ERP हैं? हर बार हाथ उठते हैं। वजह पूछिए, तो पता चलता है कि ERP क्षेत्र के हिसाब से बँटे हैं (एक उत्तरी अमेरिका के लिए, एक यूरोप के लिए), काम के हिसाब से (एक प्लंबिंग कंपनी एक इलेक्ट्रिकल कंपनी खरीदती है, और हर एक अपना ERP रखती है), या बस इतिहास की वजह से: बिज़नेस खरीदा गया था, और किसी ने अब तक उसे माइग्रेट नहीं किया।

Steve’s Plumbing को ग्राहक मान लीजिए। यह उत्तरी अमेरिका में बिज़नेस करता है, इसलिए उत्तरी अमेरिकी ERP में इसका एक ग्राहक रिकॉर्ड है। फिर यह Munich में एक दफ़्तर खोलता है, और यूरोपीय ERP अपना अलग ग्राहक रिकॉर्ड बनाता है, अपने ग्राहक नंबर के साथ। एक ही कंपनी, दो रिकॉर्ड, दो ID। मैं इसे एक Salesforce org में कैसे दिखाऊँ? मैंने तीन तरीके देखे हैं।

एक account हायरार्की। Steve’s Plumbing parent है, और Steve’s Plumbing North America और Steve’s Plumbing Europe child accounts हैं, हर child एक ERP के रिकॉर्ड के लिए। पेच यह है: children असल में अब Steve’s Plumbing नहीं रहे। वे किसी क्षेत्र में बिज़नेस करती हुई Steve’s Plumbing हैं, और जैसा हमने अभी देखा, हायरार्की अपने साथ अर्थ लेकर चलती है।

बराबरी वाले (peer) accounts। दो accounts अगल-बगल, हर एक में एक फ़ील्ड जो बताता है कि वह किस ERP का है: एक company code, एक क्षेत्र। कुछ भी छिपा नहीं है। कीमत रिपोर्टिंग में दिखती है: पूरी दुनिया में Steve’s Plumbing को देखने के लिए आपको कुछ ऐसा चाहिए जो बताए कि ये दोनों accounts एक ही कंपनी हैं।

एक account, हर ERP के लिए एक child के साथ। एक Steve’s Plumbing, और एक child ऑब्जेक्ट जिसमें हर ERP के लिए एक रिकॉर्ड हो, जो उस ERP का ग्राहक ID रखे। दो ERP हों या दस। सेल्स के लोग एक ग्राहक देखते हैं और एक ऑर्डर देते हैं; पर्दे के पीछे, flows तय करते हैं कि हर लाइन किस ERP में जाए: इलेक्ट्रिकल काम इलेक्ट्रिकल ERP में, प्लंबिंग प्लंबिंग ERP में। लेकिन अब आपको तय करना होगा कि नाम और पते जैसे साझा मानों के लिए कौन-सा ERP प्राथमिक है, और तब क्या होता है जब ग्राहक एक ERP में हो और दूसरे में नहीं।

Click to enlarge

एक ग्राहक, दो ERP: Salesforce में इसे दिखाने के तीन तरीके।

पूछें कि वे ERP को सिंक में कैसे रखते हैं

तो कौन-सा? पहले: सेल्स के लोगों को ERP की संरचना कितनी दिखनी चाहिए? अगर वे हमेशा से जानते आए हैं कि उत्तरी अमेरिका और यूरोप अलग बिज़नेस हैं, क्योंकि वे एक या दूसरे ERP में लॉग इन करते हैं, तो इसे उनसे न छिपाएँ। उस संरचना को Salesforce में बराबरी वाले accounts के रूप में ले आएँ। अगर बिज़नेस चाहता है कि सेल्स के सामने एक ही Steve’s Plumbing हो, तो आप हर ERP के लिए एक child वाले एक account की ओर देख रहे हैं।

फिर वह सवाल जो असल में फ़ैसला करता है, और यह Salesforce में तय नहीं होता। मैं क्लाइंट से पूछता हूँ: आप अपने ERP के बीच उन दो रिकॉर्ड को सिंक में कैसे रखते हैं? हर ERP की लोकल चीज़ें नहीं, जैसे बैलेंस; वह ट्रांज़ैक्शनल है। मेरा मतलब मास्टर डेटा से है: कानूनी नाम, पते। अगर उनके पास एक टीम है जो दोनों ERP को सिंक में रखती है, तो हम उन्हें एक account के रूप में एक साथ ला सकते हैं। अगर वे अपने ही ERP में उन्हें सिंक में नहीं रख पाते, तो वे हमसे Salesforce में उन्हें सिंक में रखने की उम्मीद कैसे करेंगे? तब बराबरी वाले accounts, या एक हायरार्की।

याद रखें कि ERP क्या होता है। ये विशाल सिस्टम हैं जिन्हें लगाने में सालों लगते हैं, और मास्टर डेटा मैनेज करने का इनका अपना तरीका होता है। Salesforce इन्हें नहीं चलाएगा। ERP हमारे नियंत्रण में नहीं हैं। हमारे नियंत्रण में यह है कि हम उन्हें Salesforce में कैसे दिखाते हैं।

बीच में MDM

कुछ क्लाइंट हमारे आने से पहले ही इसे हल कर चुके होते हैं। एक बड़ी कंपनी, कई सालों से बिज़नेस में, कई ERP: वे Salesforce से बहुत पहले इस समस्या से टकराए और ERP के बीच मध्यस्थता के लिए बीच में एक समर्पित MDM प्रोडक्ट लगा दिया। यह मॉड्यूल 2 का को-एग्ज़िस्टेंस या सेंट्रलाइज़्ड MDM है। अब Salesforce ख़ुद को हर ERP से नहीं जोड़ता। वह एक जगह की ओर इशारा करता है, MDM हब, और ग्राहक का एक ही रूप पाता है। फिर भी, इससे अक्सर सामना होने की उम्मीद न करें। ये अपने आप में बड़े इम्प्लीमेंटेशन हैं; इतने सालों में मैंने सिर्फ़ दो-तीन बार इनके साथ काम किया है। और हब के साथ भी, आपको शायद वह child ऑब्जेक्ट चाहिए होगा, ताकि हर ऑर्डर को पता हो कि वह किस ERP में जा रहा है।

Click to enlarge

बीच में MDM: Salesforce एक जगह की ओर इशारा करता है।

Steve Trucking: हायरार्की किसकी है?

एक रिटेल पार्टनर की अपनी संरचना है: कॉर्पोरेट parent, क्षेत्रीय डिवीज़न, डिस्ट्रिब्यूशन सेंटर, स्टोर। क्या उस हायरार्की का मालिक Steve Trucking है? नहीं; अपने संगठन का अधिकारी पार्टनर ख़ुद है। लेकिन Steve Trucking को उन्हीं जगहों की अपनी कमर्शियल नज़र चाहिए हो सकती है, कॉन्ट्रैक्ट, account मैनेजमेंट, सर्विस और रिपोर्टिंग के लिए, शायद पार्टनर के नीचे हर DC के लिए एक child account। दो जायज़ हायरार्की, दो अधिकार। उन्हें नाम दें, और यह दिखावा न करें कि एक पेड़ हर संबंध को दर्शाता है।

सीमाओं को दिखने लायक बनाएँ

जब भी अधिकार बँटा हो, मैं चाहता हूँ कि सीमा दिखे: फ़ील्ड के नाम, रिकॉर्ड का मेटाडेटा, स्रोत सिस्टम के ID, permissions, इंटीग्रेशन का व्यवहार, दस्तावेज़। जो मैं नहीं चाहता, वह है एक डेवलपर का पाँच इंटीग्रेशन पढ़कर यह खोजना कि “ये Parent Account मान SAP से आते हैं, prospects को छोड़कर, यूरोप को छोड़कर।” यह कोई टिकाऊ अधिकार-मॉडल नहीं है। अगर हायरार्की का मास्टर बँटा है, तो बँटवारे को दर्ज करें। अगर conversion पर अधिकार बदलता है, तो बदलाव दर्ज करें। अगर Salesforce बदलाव का अनुरोध कर सकता है पर उसे कर नहीं सकता, तो यह अनुभव में साफ़ दिखाएँ।

Salesforce में इसकी शुरुआत एक फ़ील्ड से होती है। एक ऐसा फ़ील्ड होना चाहिए जो साफ़ बताए कि यह मास्टर डेटा है: ERP की key, या एक “is master data” flag। फ़ील्ड को एडिट किया जा सके या नहीं, यह उसी फ़ील्ड से तय करें, रिकॉर्ड टाइप से नहीं; Dynamic Forms के साथ अब ERP के फ़ील्ड को read-only दिखाने के लिए आपको रिकॉर्ड टाइप की ज़रूरत नहीं (अध्याय 5, हर फ़्लो के लिए एक रिकॉर्ड टाइप)। आप रिकॉर्ड को मास्टर के बाहर बनने दे सकते हैं, लेकिन एडिट पर नज़र रखें।

परीक्षा से आगे: AI क्या बदलता है। एक ग्राहक एक एजेंट से कहता है, “हमारा बिलिंग पता 125 Main Street कर दो।” फ़ील्ड वहीं Salesforce में है। क्या एजेंट को उसे अपडेट कर देना चाहिए? नहीं, अगर उसका मालिक ERP है। एजेंट को लिखने का अधिकार चाहिए, सिर्फ़ फ़ील्ड का access नहीं: उसके action में मंज़ूर रास्ता लिखा होना चाहिए, यानी बदलाव-अनुरोध भेजना और यह कहना कि “मैंने बदलाव प्रोसेसिंग के लिए भेज दिया है,” न कि झूठा बताना कि “मैंने आपका बिलिंग पता अपडेट कर दिया है।”

आर्किटेक्ट यहाँ क्या तय करता है

• Salesforce में किया गया एडिट आधिकारिक डेटा बदलता है या उसके मालिक सिस्टम से बदलाव का अनुरोध करता है।
• दोतरफ़ा flows शुरू हुए बदलावों को गूँजों से कैसे अलग करते हैं, और अस्वीकृति, टक्करों, latency और विफलता को कैसे संभालते हैं।
• हर हायरार्की का मालिक कौन है, ज़रूरत हो तो शाखा-दर-शाखा।
• कई ERP में रखे एक ग्राहक के लिए: एक हायरार्की, बराबरी वाले accounts, या हर ERP के लिए एक child वाला एक account, जो इससे तय हो कि क्लाइंट अपने ERP को कितनी अच्छी तरह सिंक में रखता है।
• क्या प्रतिस्पर्धी हायरार्की असल में अलग-अलग जायज़ संबंध हैं: कानूनी, बिलिंग, सेल्स, सर्विस।
• अधिकार की सीमाएँ और लिखने के मंज़ूर रास्ते यूज़र्स, इंटीग्रेशन, डेवलपर्स और एजेंटों को कैसे दिखाए जाते हैं।

साझा अधिकार समस्या नहीं है। अस्पष्ट अधिकार समस्या है। कई ERP अलग-अलग शाखाओं को मास्टर कर सकते हैं, Salesforce कुछ एट्रिब्यूट को मास्टर कर सकता है और दूसरों में बदलाव का अनुरोध कर सकता है, और कई हायरार्की एक एंटरप्राइज़ का वर्णन कर सकती हैं। यह सब काम करता है, जब तक हर अहम एट्रिब्यूट और संबंध के लिए आप बता सकें कि उसका मालिक कौन है, उसे कौन बदल सकता है, आधिकारिक बदलाव कहाँ होता है, और सिस्टमों के असहमत होने पर क्या होता है। अगर नहीं बता सकते, तो डायग्राम पर एक और दोतरफ़ा तीर इसे ठीक नहीं करेगा।

और जानें

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।