छोटी चेन के लिए बहु‑लोकेशन सेटअप: शाखाएँ, स्टाफ और ग्राहक

बहु‑लोकेशन सेटअप में आमतौर पर क्या गलत होता है

एक छोटे चैन के लिए बहु‑लोकेशन सेटअप अक्सर एक सरल विचार से शुरू होता है: एक ही सिस्टम सबके लिए। समस्याएँ तब शुरू होती हैं जब हर शाखा एक ही स्क्रीन, एक ही लिस्ट और एक ही बटन इस्तेमाल करती है, जबकि उनकी जिम्मेदारियाँ अलग‑अलग हैं।

सबसे आम विफलता मिश्रित दृश्यता है। लोकेशन A का फ्रंट‑डेस्क कर्मचारी लोकेशन B की अपॉइंटमेंट, नोट्स या इनवॉइस देख सकता है। या कोई मैनेजर लोकल इश्यू ठीक करते हुए गलती से कोई ग्लोबल सेटिंग बदल देता है जो सभी शाखाओं को प्रभावित करे। पहले सुविधाजनक लगता है, पर जल्दी ही ये शोर और जोखिम बन जाता है।

"हर स्थान वही देखे जो उसे देखना चाहिए" सीधा है: स्टाफ को सिर्फ वही ग्राहक, ऑर्डर, शेड्यूल, इन्वेंटरी और रिपोर्ट दिखनी चाहिए जो उनके काम और उनके लोकेशन से मेल खाती हों। कोई व्यक्ति अगर दो शाखाओं में काम करता है तो उसे दोनों दिखाई दें। अगर कोई रीजनल एडमिन है तो उसे सब कुछ दिखाई दे, पर सिर्फ इसलिए क्योंकि आपने जानबूझकर ऐसा चुना है।

जब आप कुछ नहीं करते (या अनौपचारिक नियमों पर भरोसा करते हैं), तो कुछ अनुमानित समस्याएँ सामने आती हैं:

• स्टाफ गलत रिकॉर्ड एडिट कर देता है क्योंकि लिस्ट में दूसरी शाखाएँ भी शामिल हैं।
• ग्राहक विवरण, नोट्स या भुगतान की स्थिति शाखाओं में लीक हो जाती है।
• रिपोर्ट्स गलत दिखती हैं क्योंकि टोटल्स बिना स्पष्ट फ़िल्टर के मिक्स हो जाते हैं।
• सपोर्ट दिन भर "मुझे यह क्यों दिख रहा है?" और "मुझे यह नहीं मिल रहा" जैसे सवालों का जवाब देता रहता है।

लक्ष्य सब कुछ लॉक करना नहीं है। उद्देश्य यह तय करना है कि क्या साझा होगा और क्या अलग रहेगा। कई चैन एक साझा ग्राहक डेटाबेस चाहते हैं (ताकि कोई लौटने वाला ग्राहक किसी भी जगह पहचाना जाए), जबकि ब्रांच‑ओनली डेटा जैसे लोकल शेड्यूल, आंतरिक नोट्स और स्टाफ प्रदर्शन अलग रखना चाहते हैं।

यदि आप नो‑कोड बिल्डर इस्तेमाल कर रहे हैं, तो स्क्रीन और वर्कफ्लो बनाने से पहले ये नियम तय कर लें। वरना लोग सिस्टम इस्तेमाल करने लगेगे और आप बाद में परमिशन्स पैच करेंगे।

पहले किन मुख्य हिस्सों को परिभाषित करना चाहिए

बहु‑लोकेशन सेटअप तब बेहतर काम करता है जब आप स्क्रीन, फॉर्म या रिपोर्ट बनाते समय पहले कुछ बुनियादी बातों पर सहमति कर लें। अगर आप इसे छोड़ देंगे तो परमिशन्स गड़बड़ हो जाएँगी और डेटा पर भरोसा करना कठिन हो जाएगा।

शुरू करें अपने बिल्डिंग‑ब्लॉक्स को नाम देने से। अधिकतर छोटे चैन को शाखाएँ (branches/locations), यूजर्स (स्टाफ अकाउंट्स), रोल्स (जॉब टाइप), ग्राहक (साझा पहचान) और ट्रांज़ैक्शंस (ऑर्डर, अपॉइंटमेंट, टिकट, रिटर्न) चाहिए होते हैं।

इसके बाद तय करें कौन से रिकॉर्ड ग्लोबल हैं और कौन से लोकेशन‑ओन्ड। ग्लोबल रिकॉर्ड कंपनी भर में साझा होते हैं, जैसे ग्राहक प्रोफाइल, प्रोडक्ट कैटलॉग या कॉर्पोरेट प्राइसिंग नियम। लोकेशन‑ओन्ड रिकॉर्ड किसी एक शाखा के होते हैं, जैसे डेली कैश रिपोर्ट, लोकल शेड्यूल, या शाखा‑विशिष्ट इन्वेंटरी काउंट।

परमिशन्स में दो आयाम होने चाहिए, सिर्फ एक नहीं:

• स्कोप: कोई व्यक्ति किस शाखा या शाखाओं को देख सकता है।
• एक्शन: वह रिकॉर्ड्स के साथ क्या कर सकता है जिन्हें वह देखता है।

रीड और एडिट एक्सेस अलग होने चाहिए। एक रीजनल मैनेजर सभी शाखाएँ पढ़ सकता है पर शायद सिर्फ अपनी शाखा के स्टाफ रोस्टर को ही एडिट कर सकता है। एक फ्रंट‑डेस्क कर्मचारी ग्राहक प्रोफाइल पढ़ सकता है पर केवल अपनी लोकेशन के अपॉइंटमेंट बना/एडिट कर सकता है।

अंत में, तय करें कि रिपोर्टिंग कैसे काम करेगी। अधिकांश टीमों को रोज़मर्रा के प्रबंधन के लिए प्रति‑लोकेशन प्रदर्शन चाहिए और ओनर्स/फाइनेंस के लिए क्रॉस‑लोकेशन रिपोर्टिंग चाहिए। इसे पहले से तय कर लें ताकि आप ऐसी रिपोर्ट न बनायें जो डेटा को उलझन में डाल दे।

शाखाओं को मॉडल कैसे करें ताकि आप फंसें नहीं

एक बहु‑लोकेशन सेटअप एक फैसले से शुरू होता है: आपके बिजनेस में "शाखा" का क्या मतलब है? कुछ के लिए यह रिटेल स्टोर है, कुछ के लिए क्लिनिक, वेयरहाउस, या फ्रैंचाइज़ यूनिट जो अलग रहनी चाहिए।

स्पष्ट परिभाषा से शुरू करें

एक मतलब चुनें और अपने डेटा मॉडल में उसी पर टिके रहें। अगर बाद में आपको डिपार्टमेंट्स या सर्विस एरियाज चाहिए तो उन्हें अलग कॉन्सेप्ट के रूप में जोड़ें, न कि ब्रांच रिकॉर्ड को ओवरलोड करके।

हर शाखा को एक स्थिर पहचान (identifier) दें जो नाम बदलने पर भी न बदले। एक छोटा कोड (जैसे "NYC-01") आमतौर पर पते या नाम की तुलना में बेहतर होता है।

वह जानकारी स्टोर करें जिस पर आपका रोज़ का काम निर्भर करता है: ब्रांच कोड और डिस्प्ले नाम, पता, टाइमज़ोन (घंटे, बुकिंग, रिपोर्ट के लिए महत्वपूर्ण), बिजनेस घंटे (जरूरत पड़े तो छुट्टियों के ओवरराइड के साथ), और स्टेटस जैसे active, temporarily closed, या archived।

अब तय करें स्टाफ का ब्रांच से संबंध कैसे होगा। कुछ व्यवसाय सख्त होते हैं (एक व्यक्ति, एक शाखा)। कुछ स्टाफ को शाखाओं के बीच शिफ्ट करते हैं। दोनों तरीके काम कर सकते हैं पर यह बदलता है कि आप काम कैसे असाइन करते हैं और रिकॉर्ड्स कैसे फ़िल्टर होते हैं।

एक व्यवहारिक तरीका यह है कि Staff‑Branch असाइनमेंट को अलग मॉडल करें ताकि आप एक‑से‑कई सपोर्ट कर सकें बिना बाद में सब कुछ बदले।

ग्रोथ को साधारण रखें

नए लोकेशन्स को विशेष मामलों की तरह न देखें—उन्हें डेटा मानें। सरल टेस्ट: "क्या हम ब्रांच #7 जोड़ सकते हैं बिना लॉजिक बदले?" आदर्श रूप में, नई लोकेशन जोड़ना मतलब एक नया ब्रांच रिकॉर्ड बनाना, टाइमज़ोन और घंटे सेट करना, और स्टाफ असाइन करना होना चाहिए। अगर आप कई नियम बदल रहे हैं तो मॉडल बहुत जाड़ा कपरल हो गया है।

स्टाफ एक्सेस: रोल्स, स्कोप और कौन क्या कर सकता है

एक साफ़ परमिशन सेटअप एक विचार से शुरू होता है: किसी का क्या करने का अधिकार है (रोल) अलग रखें कि वह क्या देख सकता है (स्कोप)। यदि आप इन्हें मिला देंगे तो अंततः "सहायता करने वाला" एक्सेस ओवरशेयरिंग में बदल जाएगा।

अधिकांश छोटे चैन सरल रोल रख सकते हैं: owner, regional manager, branch manager, staff, और support. प्रत्येक रोल के लिए डिफ़ॉल्ट परमिशन्स परिभाषित करें और उन्हें बोरिंग रखें। हर एरिया (ग्राहक, अपॉइंटमेंट/ऑर्डर, इन्वेंटरी, नोट्स, रिपोर्ट्स) के लिए तय करें कि view, create और edit का क्या मतलब है। फिर उन कार्रवाइयों को चिह्नित करें जो डिफ़ॉल्ट कभी नहीं होंगी, जैसे एक्सपोर्ट्स या एडमिन बदलाव।

एक चेकलिस्ट जो भ्रम रोकती है:

• रिकॉर्ड देखना
• नए रिकॉर्ड बनाना
• मौजूदा रिकॉर्ड एडिट करना
• डेटा एक्सपोर्ट या डाउनलोड करना
• एडमिन क्रियाएँ (यूज़र्स मैनेज करना, नियम बदलना, डिलीट)

स्कोप लॉक का दूसरा हिस्सा है। ज्यादातर टीमों को सिर्फ तीन स्कोप चाहिए: अपनी शाखा ही, असाइन की हुई शाखाएँ, या सभी शाखाएँ। एक ब्रांच मैनेजर के पास एडिट परमिशन हो सकती है पर सिर्फ अपनी शाखा में। एक रीजनल मैनेजर कई शाखाएँ देख सकता है पर केवल स्टाफिंग और शेड्यूल्स ही एडिट कर सकता है।

अपवादों की योजना पहले से बनाएं। अस्थायी एक्सेस अपने आप एक्सपायर हो जाना चाहिए, किसी के याद रखने पर निर्भर न रहें। ट्रेनिंग अकाउंट्स पर नकली डेटा या सीमित सैंडबॉक्स रखें। कॉन्ट्रैक्टर्स को सबसे छोटा स्कोप दें, और एक्सपोर्ट्स को डिफ़ॉल्ट रूप से रोके रखें।

साझा ग्राहक बिना ओवरशेयरिंग के

साझा ग्राहक डेटाबेस अक्सर बहु‑लोकेशन सेटअप का उद्देश्य होता है, पर यह शाखाओं के बीच डेटा लीक करने का सबसे तेज़ रास्ता भी हो सकता है। तय करें वास्तव में "एक ग्राहक, हर जगह" क्या है और क्या लोकल ही रहना चाहिए।

साझा डेटा में सामान्यतः ग्राहक प्रोफ़ाइल (नाम, संपर्क), लॉयल्टी स्टेटस, और व्यापक प्राथमिकताएँ जैसे "न कॉल" या "ईमेल पसंद" शामिल होते हैं। ये किसी भी शाखा को व्यक्ति को पहचानने और लगातार सेवा देने में मदद करते हैं।

लोकेशन‑विशिष्ट डेटा ब्रांच से जुड़ा होना चाहिए: विज़िट्स, खरीद, अपॉइंटमेंट्स, सर्विस नोट्स और लोकल टैग्स जैसे "Branch A के लिए VIP" या "आगामी सप्ताह में फॉलो‑अप चाहिए"। इन्हें लोकल रखने से शोर कम होता है और स्टाफ अनावश्यक विवरण नहीं देखता।

स्पष्ट देखने के नियम तय करें

सरल नीति यह है: हर कोई ग्राहक ढूँढ सकता है, पर हर कोई सब कुछ नहीं देखेगा।

फ्रंट‑डेस्क स्टाफ प्रोफाइल विवरण और संपर्क प्राथमिकताएँ देख सकता है, साथ ही अपनी शाखा के विज़िट्स। मैनेजर्स क्रॉस‑ब्रांच टोटल्स (जैसे लाइफटाइम स्पेंड) देख सकते हैं बिना दूसरी शाखाओं के विस्तृत नोट्स देखे। HQ या सपोर्ट रोल्स पूरी हिस्ट्री आवश्यकता होने पर देख सकते हैं। मार्केटिंग केवल ऑप‑इन स्टेटस और सेगमेंट्स देख सकती है, निजी सर्विस नोट्स नहीं।

इससे साझा ग्राहक डेटाबेस उपयोगी रहेगा बिना इसे साझा डायरी में बदलने के।

संवेदनशील फील्ड्स को डिजाइन के अनुसार सुरक्षित रखें

संवेदनशील डेटा (निजी नोट्स, दस्तावेज़, शिकायतें, मेडिकल या कानूनी विवरण) सामान्य नोट्स से अलग होना चाहिए और कड़े परमिशन्स के पीछे लॉक होना चाहिए। अगर आप दस्तावेज़ स्टोर करते हैं तो एक्सेस स्पष्ट रखें: कौन अपलोड कर सकता है, कौन देख सकता है, और क्या देखना उसी शाखा तक सीमित होगा।

उदाहरण: ग्राहक ब्रांच 1 में हेयरकट के लिए आया और ब्रांच 2 में प्रोडक्ट खरीदा। ब्रांच 2 का स्टाफ लॉयल्टी टियर और "परफ्यूम से एलर्जी" जैसी प्राथमिकता देख सकता है, पर ब्रांच 1 की विस्तृत शिकायत नोट नहीं।

सरल रखने वाले डेटा पृथक्करण पैटर्न

मुख्य फैसला यह है कि आप टैग करके डेटा अलग रखेंगे या भौतिक रूप से अलग‑अलग। अधिकांश छोटे चैन एक ही डेटाबेस और स्पष्ट नियमों के साथ सरल रह सकते हैं।

पैटर्न 1: एक डेटाबेस, हर रिकॉर्ड में BranchID

यह सामान्य विकल्प है। ऑर्डर, अपॉइंटमेंट, इन्वेंटरी काउंट और स्टाफ एक्टिविटी एक ही टेबल में रहती हैं, पर हर रो में BranchID (या LocationID) होता है। यह साझा ग्राहकों, क्रॉस‑लोकेशन रिपोर्टिंग और शाखाओं के बीच फ्लेक्सिबल स्टाफ कवरेज को सपोर्ट करता है।

पैटर्न 2: हर शाखा के लिए अलग‑अलग डेटाबेस

यह "ज़्यादा सुरक्षित" महसूस कर सकता है, पर यह रोज़मर्रा की लागत बढ़ा देता है। माइग्रेशन कई बार करनी पड़ती है, रिपोर्ट्स मुश्किल होती हैं, और साझा ग्राहक सिंकिंग की समस्या बन जाते हैं।

एक व्यवहारिक नियम:

• एक डेटाबेस और BranchID तब उपयोग करें जब आप साझा ग्राहक, साझा रिपोर्टिंग और फ्लेक्सिबल स्टाफ कवरेज चाहते हों।
• अलग डेटाबेस केवल तब चुनें जब कानूनी या कॉन्ट्रैक्ट सीमाएँ अलगाव मजबूर करें।

जो भी पैटर्न चुनें, ब्रांच फ़िल्टरिंग ऑटोमैटिक बनाएं। हर स्क्रीन या रिपोर्ट पर फ़िल्टर याद रखने पर निर्भर न रहें। लोकेशन को यूज़र सेशन का हिस्सा मानें और उसे एक जगह लागू करें ताकि हर लिस्ट और कार्रवाई डिफ़ॉल्ट रूप से स्कोप्ड हो।

ग्लोबल आइटम्स बनाम लोकल ओवरराइड के लिए भी योजना बनाएं। परिभाषाएँ ग्लोबल रखें (कैटलॉग आइटम्स, सर्विस टेम्पलेट्स, प्राइसिंग नियम), फिर ज़रूरत पर प्रति‑ब्रांच ओवरराइड फील्ड्स जोड़ें (ब्रांच‑विशेष कीमत, स्टॉक थ्रेशोल्ड, ओपनिंग ऑवर्स)। इससे पूरा कैटलॉग प्रति‑लोकेशन कॉपी करने से बचता है।

शुरू में ऑडिट ट्रेल्स जोड़ें। आपको जवाब देना होगा "किसने इसे बदला और कहाँ?" कम से कम यूज़र ID, ब्रांच ID, टाइमस्टैम्प, कार्रवाई (create, update, delete) और संवेदनशील फील्ड्स के लिए पहले‑बाद के मान कैप्चर करें।

कदम‑दर‑कदम: शाखाएँ, परमिशन्स और विजिबिलिटी नियम सेट करना

लक्ष्य सरल है: लोगों को सिर्फ वही दिखे जो उनका काम करने के लिए चाहिए, और कुछ भी अतिरिक्त न दिखे। सबसे आसान तरीका यह है कि तय करें क्या ब्रांच को 属 है, क्या साझा है, और स्टाफ स्क्रीन पर कैसे नेविगेट करेगा।

एक व्यवहारिक सेटअप अनुक्रम

डेटाबेस या ऐप बिल्डर छूने से पहले कागज पर (या साधारण स्प्रैडशीट) शुरू करें।

1. आप जो भी डेटा आइटम स्टोर करते हैं (अपॉइंटमेंट, ऑर्डर, इन्वेंटरी, स्टाफ नोट्स, ग्राहक प्रोफाइल) उनकी सूची बनाएं। हर एक को ग्लोबल (साझा) या ब्रांच‑ओन्ड के रूप में मार्क करें।
2. रोल्स को सादे शब्दों में परिभाषित करें (फ्रंट‑डेस्क, टेक्नीशियन, स्टोर मैनेजर, हेड ऑफिस)। हर रोल के लिए ब्रांच स्कोप लिखें: एक ही शाखा, असाइन की हुई शाखाएँ, या सभी शाखाएँ।
3. साझा ग्राहकों के नियम सेट करें: ब्रांचों के बीच क्या दिखाई देगा और क्या लोकल रहेगा। यह तय करें कि साझा फील्ड्स को कौन एडिट कर सकता है।
4. स्टाफ वर्सेस मैनेजर के लिए अलग स्क्रीन और रिपोर्ट डिज़ाइन करें। स्टाफ व्यू डिफ़ॉल्ट रूप से "मेरी शाखा" पर होना चाहिए। मैनेजर व्यू में फ़िल्टर और तुलनाएँ शामिल हों।
5. अलग‑अलग शाखाओं के नमूना अकाउंट्स से टेस्ट करें। असली कार्यों को आज़माएँ (बुकिंग बनाना, रिफंड, ग्राहक अपडेट, रिपोर्ट देखना) और जांचें कि सिस्टम ने वे कार्य ब्लॉक कर दिए जिन्हें रोकना चाहिए।

टेस्ट न छोड़ें। अधिकांश परमिशन समस्याएँ तभी दिखाई देती हैं जब आप वास्तविक रोल में लॉग इन करके रोज़मर्रा का काम जल्दी‑जल्दी करने की कोशिश करते हैं।

आम गलतियाँ और उनसे कैसे बचें

अधिकांश बहु‑लोकेशन समस्याएँ बड़े फेलियर नहीं होतीं—यह छोटे डिफ़ॉल्ट्स होते हैं जो चुपचाप डेटा लीक कर देते हैं या लोगों को उनका काम करने से रोकते हैं। मानकर चलें कि हर स्क्रीन, रिपोर्ट और एक्सपोर्ट को लोकेशन नियम चाहिए।

रिपोर्ट्स और एक्सपोर्ट्स अक्सर छूट जाते हैं। टीम स्क्रीन पर सावधानी से ब्रांच के हिसाब से फ़िल्टर करती है, फिर एक्सपोर्ट करते समय "सभी ग्राहक" या "पिछले महीने की सेल्स" चुनकर गलती से दूसरी शाखाओं का डेटा भी निकाल लेती है। एक्सपोर्ट्स को अलग फीचर मानें जिनके अपने फ़िल्टर और टेस्ट हों। अगर किसी स्टाफ में ऐप में रिकॉर्ड दिखाई नहीं देता तो उसे एक्सपोर्ट करने का अधिकार भी नहीं होना चाहिए।

एक और समस्या है मैनेजर रोल जो चुपचाप एडमिन बन जाता है। यह तब होता है जब आप स्क्रीन के आधार पर कार्रवाइयों को ग्रुप करते हैं न कि रिस्क के आधार पर। मैनेजर्स को रिफंड, शिफ्ट एडिट्स या ग्राहक नोट्स की आवश्यकता हो सकती है, पर यूज़र क्रिएशन, परमिशन बदलाव या ब्रांच सेटअप नहीं। "ऑपरेशन्स मैनेज" और "सिस्टम मैनेज" को अलग करें।

साझा ग्राहकों में गड़बड़ी तब होती है जब सब कुछ एक सेट फील्ड्स में स्टोर करते हैं। अगर आप लोकल‑ओनली नोट्स (जैसे "यहाँ हमेशा डिस्काउंट मांगता है") को ग्लोबल नोट में डालते हैं तो ओवरशेयरिंग हो जाएगी। साझा ग्राहक फेक्ट्स को ब्रांच‑विशेष नोट्स और विज़िट हिस्ट्री से अलग रखें।

ऑडिट ट्रेल की कमी आरोप‑प्रत्यारोप और दोबारा काम का कारण बनती है। जब दो शाखाएँ एक ही ग्राहक को एडिट करती हैं तो आपको बुनियादी "किसने क्या और कब बदला" की जानकारी चाहिए। यहां तक कि साधारण created_by, updated_by और timestamps भी मदद करते हैं।

अंत में, फ्लोटिंग स्टाफ के लिए योजना बनाएं। अगर आप उन्हें शाखाओं के बीच "मूव" करेंगे बजाय मल्टी‑ब्रांच एक्सेस देने के, तो शेड्यूल्स और विजिबिलिटी टूट जाएगी।

शुरू में यह व्यावहारिक फिक्स बुनें:

• हर डेटा प्रकार के लिए नियम लिखें: ग्लोबल (साझा) बनाम ब्रांच‑ओनली।
• रोल्स को कार्रवाइयों के अनुसार परिभाषित करें, फिर लोकेशन स्कोप जोड़ें (एक शाखा बनाम कई)।
• हर लिस्ट, रिपोर्ट और एक्सपोर्ट में ब्रांच फ़िल्टर्स बनाएं।
• ब्रांच नोट्स और साझा ग्राहक डेटा अलग स्टोर करें।
• ग्राहक और ऑर्डर बदलावों के लिए एडिट रिकॉर्ड रखें (यूज़र + समय)।

लाइव जाने से पहले त्वरित जाँचें

हर लोकेशन को एक्सेस देने से पहले एक टेस्ट‑डे करें। हर शाखा के लिए कम से कम एक कर्मचारी बनाएं और एक रीजनल मैनेजर भी। फिर सामान्य काम करें: अपॉइंटमेंट बुक करें, ऑर्डर बनाएं, ग्राहक अपडेट करें, रिपोर्ट चलाएँ।

इस चेकलिस्ट का उपयोग करें ताकि सबसे ज्यादा उलझन पैदा करने वाली समस्याएँ पकड़ी जा सकें:

• ब्रांच कर्मचारी के रूप में लॉग इन करें और पुष्टि करें कि वे सिर्फ अपनी शाखा के ऑर्डर, अपॉइंटमेंट और कार्य ही देखते हैं। सर्च, फ़िल्टर और रीसेंट आइटम्स दूसरी शाखाएँ नहीं दिखाएँ।
• एक मैनेजर के रूप में लॉग इन करें जो एक से अधिक शाखाओं को ओवरसी करता है। उसे कई शाखाएँ दिखनी चाहिए पर एडिटिंग केवल असाइन की गई शाखाओं में सीमित हो।
• दो अलग शाखाओं से एक ही ग्राहक प्रोफाइल खोलें। नाम और संपर्क विवरण सभी जगह मेल खाने चाहिए, और अपडेट्स से डुप्लिकेट्स नहीं बनने चाहिए।
• एडमिन या रिपोर्टिंग व्यू में सक्रिय शाखा बदलें और टोटल्स की तुलना करें। कुछ दिनों का स्पॉट‑चेक करें: जब आप शाखा बदलें तो नंबर्स बदलने चाहिए और सभी‑शाखा व्यू उन नंबर्स का योग होना चाहिए।
• किसी स्टाफ अकाउंट को डिसेबल करें और पुष्टि करें कि एक्सेस तुरंत रद्द हो गया (ऐप एक्सेस और किसी भी एडमिन या API पाथ)।

फिर एक नाज़ुक स्थिति टेस्ट करें: ग्राहक Branch A में खरीदारी करता है, फिर Branch C में सपोर्ट के लिए कॉल करता है। Branch C का स्टाफ साझा ग्राहक प्रोफाइल देख सकते हैं पर Branch A के अंदरूनी नोट्स या प्रतिबंधित रिकॉर्ड नहीं।

उदाहरण परिदृश्य: एक ग्राहक, तीन शाखाएँ

एक छोटे सैलून चैन की कल्पना करें जिसमें तीन शाखाएँ हैं: Downtown, Riverside, और Mall। वे एक ही ग्राहक सूची साझा करते हैं ताकि कोई भी कहीं भी बुक कर सके, पर हर शाखा अपना शेड्यूल, स्टाफ और रोज़मर्रा के नोट्स रखती है।

Maya (Downtown की फ्रंट‑डेस्क) सिस्टम खोलती है। उसे सिर्फ Downtown का कैलेंडर, Downtown स्टाफ और आज की अपॉइंटमेंट दिखती है। वह सारे ब्रांचों में ग्राहकों को सर्च कर सकती है, पर उसे सिर्फ बुनियादी प्रोफ़ाइल जानकारी दिखती है: नाम, फोन, एलर्जी, और लॉयल्टी स्टेटस। उसे Riverside का शेड्यूल, स्टाफ प्रदर्शन या निजी नोट्स नहीं दिखते।

Alex (ओनर) लॉग इन करता है। Alex तीनों कैलेंडरों, शाखा‑वार राजस्व रिपोर्ट और स्टाफ रोल्स को मैनेज कर सकता है। Alex बड़े डिस्काउंट जैसी एक्सेप्शन्स को भी अप्रूव कर सकता है।

Jordan आमतौर पर Downtown जाता है, पर इस हफ्ते Mall में आखिरी‑मिनट कट बुक करता है। Mall में जब Jordan चेक‑इन करता है, उन्हें Jordan का मूल प्रोफ़ाइल और सर्विस हिस्ट्री दिखती है (क्या किया गया, कब और किसने)। अपॉइंटमेंट के बाद Mall ने नई सर्विस हिस्ट्री जोड़ दी। Downtown बाद में इसे देख सकता है ताकि वे बार‑बार वही सवाल न पूछें।

चेकआउट पर एक जिस्म स्थिति आती है। Jordan लंबी प्रतीक्षा के कारण 30% छूट मांगता है। Mall का फ्रंट‑डेस्क 10% से अधिक छूट सीधे लागू नहीं कर सकता; वह छूट अनुरोध Alex को भेजता है। Alex अप्रूव करता है, रसीद अपडेट होती है, और ऑडिट लॉग दर्शाता है किसने अनुरोध किया और किसने अप्रूव किया।

संवेदनशील नोट्स अलग तरह से हैंडल किए जाते हैं। अगर एक स्टाइलिस्ट निजी नोट जोड़ता है जैसे "क्लाइंट किसी मेडिकल स्थिति से गुजर रहा है, स्कैल्प ट्रीटमेंट में सावधानी बरतें", तो केवल स्टाइलिस्ट और ओनर इसे देख सकते हैं। फ्रंट‑डेस्क स्टाफ को सिर्फ "विशेष देखभाल आवश्यक" जैसा फ्लैग दिखेगा बिना डिटेल्स के।

जो काम करता है वह कुछ स्पष्ट नियमों का छोटा सेट है: ब्रांच‑स्कोप्ड शेड्यूल और स्टाफ, साझा ग्राहक बेसिक, संवेदनशील नोट्स पर सीमाएँ, और डिस्काउंट के लिए अप्रूवल सीमाएँ।

अगले कदम: नियमों को दस्तावेज़ करें, एक्सेस टेस्ट करें, फिर बनाना शुरू करें

बहु‑लोकेशन सेटअप तभी व्यवस्थित रहता है जब आपके नियम लिखे और फीचर की तरह टेस्ट किए जाएँ, न कि भावना की तरह छोड़े जाएँ। अपने "कौन क्या देख सकता है" निर्णयों को साधारण वाक्यों में बदलें।

दिन‑प्रतिदिन मामलों को कवर करने वाले 10–15 छोटे वाक्यों का लक्ष्य रखें: बुकिंग, ग्राहक प्रोफाइल, भुगतान, रिफंड, नोट्स और रिपोर्ट्स। उदाहरण के लिए:

• स्टाफ सदस्य अपनी शाखा के ग्राहक और ऑर्डर देख सकता है।
• ग्राहक के संपर्क विवरण सभी शाखाओं को दिखाई देंगे, पर नोट्स ब्रांच‑ओनली होंगे।
• मैनेजर्स शाखा रिपोर्ट देख सकते हैं; केवल ओनर्स सभी‑शाखा टोटल देख सकते हैं।
• रिफंड्स के लिए मैनेजर अप्रूवल चाहिए और यह उसी शाखा के अंदर होना चाहिए।
• केवल HQ प्राइस‑लिस्ट और ग्लोबल सेटिंग्स एडिट कर सकता है।

निर्णय लें कि कौन‑से स्क्रीन और रिपोर्ट हमेशा ब्रांच स्कोप पर डिफ़ॉल्ट हों। अगर कोई स्क्रीन सभी शाखाएँ दिखा सकती है, तो उसे स्पष्ट फ़िल्टर बनाइए, डिफ़ॉल्ट न बनाइए। एक अच्छा टेस्ट: क्या कैशियर बिना कोशिश किए गलती से दूसरी शाखा की दैनिक राजस्व रिपोर्ट खोल सकता है? अगर हाँ, तो डिफ़ॉल्ट सख्त करें।

रियल रोल्स से टेस्ट करें, न कि एडमिन अकाउंट्स। तीन टेस्ट यूज़र्स बनाएं (कैशियर, मैनेजर, HQ) और वास्तविक फ्लो चलाएं: ग्राहक Branch A को कॉल करता है, Branch B में जाता है, और Branch C में रिफंड माँगता है। पुष्टि करें कि हर व्यक्ति सिर्फ वही देखता है जो चाहिए।

महीने‑वार परमिशन चेक शेड्यूल करें ताकि ड्रिफ्ट न हो: नए रोल्स, नौकरी बदलाव, नई शाखाएँ, और रिपोर्ट एक्सेस क्रिप।

यदि आप कस्टम इन‑हाउस टूल बना रहे हैं, तो AppMaster (appmaster.io) जैसे प्लेटफ़ॉर्म आपकी शाखाएँ, रोल्स और बिज़नेस नियम एक जगह मॉडल करने में मदद कर सकते हैं, और बदलती आवश्यकताओं के साथ क्लीन कोड जेनरेट कर सकते हैं ताकि आपके परमिशन नियम बढ़ने पर भी सुसंगत रहें।