05 मार्च 2026·7 मिनट
उपयोगकर्ता भूमिकाएँ और अनुमतियाँ: ऐप बनाने से पहले इनकी योजना बनाएं
उपयोगकर्ता भूमिकाएँ और अनुमतियाँ ऐप जेनरेट करने से पहले मैप करें ताकि owner, staff, customer और admin को पहले दिन से सही एक्सेस मिल सके।
पहले भूमिकाएँ तय क्यों करें
उपयोगकर्ता भूमिकाएँ और अनुमतियाँ किसी एक स्क्रीन के बनने से पहले योजना बनाना आसान होती हैं।
शुरुआत में सबको एक ही तरह की पहुंच देना तेज़ लग सकता है। पर सामान्यत: यह फैसला तुरंत समस्याएँ पैदा कर देता है। एक owner, एक staff सदस्य, एक customer और एक admin को एक जैसे स्क्रीन, एक जैसे क्रियाएँ, या एक जैसे डेटा की जरूरत नहीं होती।
जब पहुंच बहुत व्यापक हो, तो लोग उन चीज़ों को भी देख लेते हैं जो उनके लिए उपयोगी नहीं हैं और कभी-कभी बिल्कुल भी दिखाई नहीं देनी चाहिए। एक ग्राहक आंतरिक नोट्स देख सकता है। एक कर्मचारी बिलिंग सेटिंग्स तक पहुँच सकता है। एक owner रिपोर्ट और कंट्रोल की उम्मीद कर सकता है, पर वही सीमित व्यू देखकर अटक सकता है जो फ्रंट-डेस्क कर्मचारी के लिए बनाया गया था। भले ही कोई निजी जानकारी उजागर न हो, ऐप फिर भी गडबड़ महसूस करता है क्योंकि हर स्क्रीन हर किसी की सेवा करने की कोशिश कर रही होती है।
यह समस्या जल्दी फैलती है। भूमिकाएँ मेनू, डैशबोर्ड, फॉर्म, अप्रूवल्स, रिपोर्ट, एक्सपोर्ट और संग्रहित डेटा के पीछे के नियमों को प्रभावित करती हैं। एक छोटी-सी नीति जैसे "staff ऑर्डर देख सकता है पर रिफंड नहीं कर सकता" अक्सर सिर्फ एक बटन से ज्यादा कुछ बदल देती है। यह वर्कफ़्लो, अलर्ट, लॉग और संपादन नियमों को प्रभावित कर सकती है।
देर से किए गए अनुमतियों के सुधार शायद ही कभी छोटे होते हैं। एक बार गलत पहुंच बन जाने पर आप सिर्फ सेटिंग्स नहीं बदल रहे होते — आप स्क्रीन फिर से डिज़ाइन कर रहे होते हैं, डेटा स्थानांतरित कर रहे होते हैं, वर्कफ़्लो का पुनःपरीक्षण कर रहे होते हैं, और उन असली उपयोगकर्ताओं को नए नियम समझा रहे होते हैं जो पुराने नियम सीख चुके हैं।
थोड़ी सी प्रारंभिक योजना अधिकांश समस्याओं से बचा लेती है। अगर शुरुआत से भूमिका स्पष्ट हों, तो ऐप पहले दिन से ही साफ़ संरचना के साथ आता है। Owners को बिज़नेस सेटिंग्स और हाई-लेवल रिपोर्ट्स मिलती हैं। Staff रोज़ाना काम कर सकें पर अकाउंट के नियंत्रणों को छू न सकें। Customers केवल अपनी जानकारी देख सकें। Admin पहुँच उन लोगों तक सीमित रहे जिन्हें वास्तव में इसकी ज़रूरत है।
यदि आप Koder.ai के साथ बना रहे हैं, तो यह और भी ज़्यादा मायने रखता है क्योंकि पहली वर्ज़न चैट से जल्दी जेनरेट हो सकती है। स्पष्ट भूमिका परिभाषाएँ प्लेटफ़ॉर्म को बेहतर निर्देश देती हैं, ताकि ऐप वही निकटतम रूप में शुरू हो जो बिज़नेस को चाहिए।
जल्दी में मैप करने के लिए चार भूमिकाएँ
ज़्यादातर पहले वर्ज़न में चार भूमिकाएँ काम देती हैं: owner, staff, customer और admin। ज़रूरत पड़ने पर आप बाद में इन्हें विभाजित कर सकते हैं, पर यहाँ से शुरू करना एक मजबूत आधार देता है।
Owner
Owner वह व्यक्ति होता है जो बिज़नेस अकाउंट के लिए ज़िम्मेदार है। यह भूमिका आमतौर पर बिलिंग, सब्सक्रिप्शन बदलाव, कानूनी सेटिंग्स, ओनरशिप ट्रांसफर और सबसे संवेदनशील अकाउंट फैसलों को नियंत्रित करती है।
इस भूमिका को स्पष्ट और जल्दी परिभाषित करें। यदि "owner" अस्पष्ट रहता है तो टीम अक्सर काम चलाने के लिए गलती से यह शक्ति अन्य उपयोगकर्ताओं को दे देती है।
Staff
Staff सदस्य रोज़ाना का काम संभालते हैं। वे रिकॉर्ड अपडेट करते हैं, ग्राहकों के जवाब देते हैं, ऑर्डर बनाते हैं, स्टेटस चेक करते हैं, कंटेंट प्रबंधित करते हैं या कार्य आगे बढ़ाते हैं।
उन्हें अपना काम तेज़ी से करने के लिए पर्याप्त पहुंच चाहिए, पर सामान्यत: उन्हें अकाउंट-व्यापी सेटिंग्स पर पूरा नियंत्रण नहीं चाहिए। एक अच्छा परीक्षण सरल है: यदि कोई गलती पूरे बिज़नेस अकाउंट को नुकसान पहुँचा सकती है, तो संभवतः वह क्रिया admin या owner की ही होनी चाहिए।
Customer
Customers का व्यू सबसे संकुचित होना चाहिए। अधिकांश ऐप्स में उन्हें केवल अपना डेटा दिखना चाहिए—जैसे प्रोफ़ाइल, बुकिंग, खरीद, संदेश या प्रोग्रेस।
यह वही जगह है जहाँ टीम अक्सर चूक करती है। वे यह तय करने में समय लगाते हैं कि ग्राहक क्या कर सकेंगे, पर भूल जाते हैं ये बताना कि ग्राहक क्या कभी नहीं देख पाएंगे।
Admin
Admin और owner को अक्सर एक ही माना जाता है, पर वे हमेशा एक जैसे नहीं होते।
Admin आमतौर पर ऐप के अंदर संचालन संभालता है। इसमें स्टाफ जोड़ना, अनुमतियाँ रीसेट करना, गतिविधि की समीक्षा करना या सपोर्ट मामलों को संभालना शामिल हो सकता है। कई उत्पादों में admin को बिलिंग, ओनरशिप ट्रांसफर या सबसे संवेदनशील बिज़नेस सेटिंग्स नियंत्रित नहीं करनी चाहिए।
चारों भूमिकाओं को अलग करने का एक सरल तरीका यह है:
- Owner बिज़नेस अकाउंट नियंत्रित करता है।
- Admin आंतरिक संचालन संभालता है।
- Staff रोज़ का काम करता है।
- Customer सेवा का उपयोग करता है।
यह बेसिक विभाजन बाद की निर्णय-प्रक्रियाओं को बहुत आसान बनाता है।
दिखाई देना और क्रियाएँ अलग हैं
एक भूमिका सिर्फ़ एक लेबल नहीं है। यह दो अलग सवालों का जवाब देती है:
- यह व्यक्ति क्या देख सकता है?
- यह व्यक्ति जो देखता है उसके बाद क्या कर सकता है?
ये दोनों एक जैसी बात नहीं हैं।
एक staff सदस्य ग्राहक के ऑर्डर देख सकता है पर उन्हें डिलीट नहीं कर सकता। एक admin रिफंड अप्रूव कर सकता है, जबकि ग्राहक केवल रिफंड का अनुरोध कर सकता है। यदि दृश्यता और क्रिया के अधिकार उलझ जाएँ तो लोग या तो काम में ब्लॉक हो जाते हैं या फिर उन्हें अनावश्यक पहुँच मिल जाती है।
ज़्यादातर ऐप्स अनुमति को कुछ सामान्य क्रियाओं से परिभाषित कर सकते हैं: view, create, edit, delete, approve और कभी-कभी export। ये क्रियाएँ सरल लगती हैं, पर स्क्रीन और जुड़े डेटा के अनुसार इनका मतलब बदल जाता है।
कोई व्यक्ति अपनी प्रोफ़ाइल एडिट कर सकता है पर कंपनी बिलिंग नहीं बदल सकता। वे सपोर्ट टिकट बना सकते हैं पर डिस्काउंट अप्रूव नहीं कर सकते। वे भुगतान कैप्चर होने से पहले ऑर्डर अपडेट कर सकते हैं पर बाद में नहीं।
यह भी मदद करता है कि अकाउंट सेटिंग्स को बिज़नेस डेटा से अलग रखा जाए। अकाउंट सेटिंग्स में आमतौर पर पासवर्ड, प्रोफ़ाइल, नोटिफ़िकेशन, बिलिंग, टीम मेंबर्स और लॉगिन सुरक्षा शामिल होती है। बिज़नेस डेटा ऐप के अंदर रोज़मर्रा की जानकारी है, जैसे ऑर्डर, प्रोजेक्ट, इनवॉइस, संदेश, अपॉइंटमेंट या स्टॉक।
यह फर्क मायने रखता है क्योंकि "एडिट एक्सेस" का मतलब दोनों मामलों में बहुत अलग होता है। अपना फोन नंबर एडिट करना पेरोल, ग्राहक रिकॉर्ड या सिस्टम नियम बदलने जैसा नहीं है।
एक सरल permission मैप बनाएं
एक अच्छा permission मैप नौकरी के टाइटल्स से नहीं बल्कि असली काम से शुरू होता है।
स्क्रीन या डेटाबेस जेनरेट करने से पहले, ऐप में लोग रोज़ क्या-क्या करने की ज़रूरत रखते हैं, उसे लिखें। कामों को क्रियाओं के रूप में सोचें: ऑर्डर बनाना, रिफंड अप्रूव करना, ग्राहक रिकॉर्ड अपडेट करना, रिपोर्ट देखना, बिलिंग सेटिंग बदलना। इससे अनुमति योजना वास्तविक उपयोग से जुड़ी रहती है न कि अनुमान से।
एक सरल प्रक्रिया अक्सर अच्छी तरह काम करती है:
- कोर वर्कफ़्लो को सादे भाषा में सूचीबद्ध करें।
- हर वर्कफ़्लो को चरणों में तोड़ें।
- हर चरण में देखें कौन view, create, edit, approve, delete, या export कर सकता है।
- किसी भी अपवाद को नोट करें, जैसे "staff ऑर्डर एडिट कर सकता है, पर भुगतान कैप्चर होने के बाद नहीं।"
तीन से पाँच वर्कफ़्लो से शुरू करें। एक छोटे बिज़नेस के लिए यह ग्राहक ऑनबोर्डिंग, पेमेंट लेना, सपोर्ट संभालना और प्रदर्शन चेक करना हो सकता है। फिर सोचें हर जगह कौन मुख्य निर्णय लेता है।
यह स्पष्ट होते ही स्क्रीन-दर-स्क्रीन आगे बढ़ें। हर पेज के लिए दो सवाल पूछें: कौन इसे देख सकता है, और वहाँ वे क्या कर सकते हैं?
एक डैशबोर्ड owner और staff दोनों के लिए दिखाई दे सकता है, पर केवल owner ही रेवेन्यू टोटल देखे। एक ग्राहक प्रोफ़ाइल पेज पर ग्राहक अपनी संपर्क जानकारी एडिट कर सकता है जबकि staff सिर्फ़ उसे देख सकता है। एक रिफंड स्क्रीन सपोर्ट स्टाफ को दिखाई दे सकती है, पर अप्रूवल अभी भी admin का अधिकार हो सकता है।
यहाँ एक भूमिका मैट्रिक्स उपयोगी हो जाता है। इसे भव्य बनाने की ज़रूरत नहीं—एक सादा तालिका या छोटा दस्तावेज़ भी पर्याप्त है यदि उसमें दिखता है कि कौन सी भूमिका किस हिस्से पर कौन सी क्रिया कर सकती है।
यदि आप Koder.ai उपयोग कर रहे हैं, तो यह चरण आपको बहुत बेहतर प्रॉम्प्ट देगा। "Build an admin panel" अस्पष्ट है। "Owner plans और refunds संभाल सकता है, staff अकाउंट देख सकते हैं और टिकट्स का जवाब दे सकते हैं, customers केवल अपनी प्रोफ़ाइल और ऑर्डर एडिट कर सकते हैं" जैसी स्पष्ट बातें सिस्टम को निर्माण के लिए ठोस निर्देश देती हैं।
कुछ भी लॉक करने से पहले मैप को कुछ वास्तविक परिदृश्यों से टेस्ट करें। सरल कार्यों को आज़माएँ जैसे एक staff सदस्य का ऑर्डर रिफंड करना, ग्राहक का पता बदलना, या owner का मासिक बिक्री देखना। अगर कोई चरण अस्पष्ट लगे तो अनुमति अभी भी बहुत धुंधली है।
उदाहरण: एक सैलून बुकिंग ऐप
हर भूमिका जल्दी जाँचें
लॉन्च से पहले owner, staff, customer और admin के कार्यों को चरण-दर-चरण चलाएं।
एक छोटा सैलून बुकिंग ऐप अच्छा उदाहरण है क्योंकि उत्पाद सरल दिखता है जब तक आप यह न देखें कि किसे किस चीज़ की पहुंच चाहिए।
माया owner है। उन्हें बिज़नेस का पूरा दृश्य चाहिए: बुकिंग्स, स्टाफ कैलेंडर, ग्राहक इतिहास, सर्विस प्राइस, और सेल्स टोटल। वे स्टाफ जोड़ या हटा सकती हैं, खुलने के घंटे बदल सकती हैं, छुट्टियाँ ब्लॉक कर सकती हैं, रिफंड जारी कर सकती हैं, और एक्सेस नियम बदल सकती हैं।
लियो स्टाइलिस्ट है। उसे केवल अपने काम के लिए ज़रूरी बातें चाहिए। उसे अपनी ही अपॉइंटमेंट्स, बेसिक ग्राहक नोट्स और वह सर्विसेस दिखनी चाहिए जो वह कर सकता है। वह अपॉइंटमेंट को पूरा दिखा सकता है, विज़िट के बाद नोट जोड़ सकता है, और बुकिंग को मूव कर सकता है यदि वह माय ने तय किए नियमों के भीतर रहे।
वह प्राइस बदल नहीं सकता, पूरा बिज़नेस रिपोर्ट नहीं देख सकता, दूसरे स्टाफ के शेड्यूल एडिट नहीं कर सकता, और सिस्टम से ग्राहक नहीं हटा सकता। ये owner के काम हैं, रोज़ के कार्य नहीं।
नीना ग्राहक है। उसका व्यू सबसे सरल होना चाहिए। वह खाली समय बुक कर सकती है, आने वाली अपॉइंटमेंट देख सकती है, पिछली यात्राओं की समीक्षा कर सकती है, और कट-ऑफ समय से पहले अपनी बुकिंग बदल या रद्द कर सकती है। वह अपना फोन नंबर या ईमेल अपडेट कर सकती है, पर वह अन्य ग्राहकों, आंतरिक नोट्स या स्टाफ-ओनली शेड्यूल डिटेल्स नहीं देख सकती।
इस ऐप में admin भूमिका हो सकती है, पर उसका उद्देश्य अलग होगा। Admin अकाउंट रिकवरी, बिलिंग मुद्दे या सुरक्षा सेटिंग्स संभाल सकता है। यह भूमिका सैलून चलाने की भूमिका नहीं है।
इसीलिए "owner, staff, customer, और admin की एक्सेस" को ऐप बनाना शुरू करने से पहले मैप करना ज़रूरी है। अगर शुरुआत सबको एक साझा बुकिंग स्क्रीन से होती है, तो अक्सर देर से पता चलता है कि staff निजी राजस्व डेटा देख सकते हैं या ग्राहक सेटिंग्स तक पहुँच सकते हैं जो उन्हें नहीं छूना चाहिए। बाद में इसे ठीक करने का मतलब स्क्रीन, नियम और टेस्ट फिर से बनाना होता है बजाय एक शुरुआती योजना निर्णय के।
वे गलतियाँ जो पुनःकार्य को लाती हैं
लॉन्च से पहले एक्सेस का परीक्षण करें
जल्दी स्क्रीन जेनरेट करें और हर भूमिका क्या देख सकती और कर सकती है, यह समीक्षा करें।
ज़्यादातर अनुमति समस्याएँ शॉर्टकट लेने से शुरू होती हैं।
पहली आम गलती बहुत जल्दी बहुत अधिक पहुंच देना है। जिस व्यक्ति को केवल staff टूल्स चाहिए, उसे सेटअप के दौरान पूरा admin अधिकार दे दिया जाता है क्योंकि यह आसान लगता है। कुछ समय के लिए यह काम करता है, फिर सफाई का समय आता है जब आपको सेटिंग्स छिपानी होंगी, डेटा लॉकडाउन करना होगा, और सही भूमिका के लिए स्क्रीन फिर से बनानी होंगी।
दूसरी गलती सभी staff सदस्यों को समान मानना है। असली टीमों में सेल्स रिप, सपोर्ट एजेंट, वेयरहाउस वर्कर और फाइनेंस लीड के टूल अक्सर एक जैसे नहीं होते। यदि वे सब एक व्यापक "staff" भूमिका साझा करते हैं, तो ऐप जल्दी ही उलझन भरा हो जाता है। लोग उन बटन को देखते हैं जिनका उपयोग उन्हें नहीं करना चाहिए, और साधारण कार्य जोखिम भरे लगने लगते हैं।
तीसरी गलती एज केसज़ को अनदेखा करना है। टीम आम क्रियाओं की योजना बनाती है जैसे ऑर्डर देखना या प्रोफ़ाइल अपडेट करना, पर संवेदनशील क्रियाओं को भूल जाती है: रिफंड, एक्सपोर्ट, अकाउंट क्लोजर, सब्सक्रिप्शन रिकवरी या रिकॉर्ड डिलीट करना। इन क्रियाओं को अक्सर कड़े नियम, अप्रूवल स्टेप या कार्रवाई का लॉग चाहिए।
चौथी गलती आंतरिक निजी डेटा को ग्राहक-फेसिंग डेटा के साथ मिलाकर रखना है। यदि सपोर्ट नोट्स, फ़्रॉड फ़्लैग या बिलिंग टिप्पणियाँ उन फ़ील्ड्स के पास रहती हैं जिन्हें ग्राहक देख सकती है, तो कोई न कोई गलत चीज़ उजागर करेगा। एक बार ऐसा होने पर आप सिर्फ़ स्क्रीन नहीं सुधार रहे होते — आपको डेटा मॉडल भी बदलना पड़ सकता है।
एक और महँगा पैटर्न है स्क्रीन पहले बनाना और पहुंच बाद में तय करना। इंटरफ़ेस शुरुआती डेमो में ठीक दिख सकता है, पर असली भूमिकाएँ शामिल होने पर टूटने लगता है। एक डैशबोर्ड जो admin के लिए काम करता है, staff या customer के लिए अलग मेनू, अलग लेबल और कम क्रियाएँ चाहिए होंगी।
यही कारण है कि टीमें अक्सर अनुमति पुनःकार्य दो बार करती हैं: पहली बार पहली बिल्ड के बाद, और दूसरी बार असली उपयोगकर्ता टेस्ट करने के बाद।
जेनरेट करने से पहले एक त्वरित चेक
बनाने से पहले रुकें और कुछ सरल सवालों के जवाब दें। यह छोटी समीक्षा आपको बाद की अनुमति पुनःकार्य से बचा सकती है।
- क्या हर भूमिका अपने मुख्य काम को कुछ ही कदमों में पूरा कर सकती है?
- क्या संवेदनशील डेटा गलत उपयोगकर्ताओं से छिपा है?
- क्या अप्रूवल कार्रवाइयाँ सही व्यक्ति के पास हैं?
- क्या नया टीम सदस्य भूमिकाओं को जल्दी समझ सकता है?
- किसी के रोल बदलने या टीम छोड़ने पर क्या होता है?
ये सवाल जल्दी समस्याओं को पकड़ लेते हैं।
उदाहरण के लिए, यदि एक staff सदस्य स्टोर मैनेजर बन जाता है, तो अब वह डिस्काउंट अप्रूव कर सकता है और टीम शेड्यूल देख सकता है। इसका यह मतलब नहीं कि उसे अपने आप बिलिंग सेटिंग्स या सभी ग्राहक डेटा एक्सपोर्ट करने की अनुमति मिल जानी चाहिए। रोल परिवर्तन को नई ज़रूरतों के अनुसार पहुँच देनी चाहिए और पुराने अधिकार हटा देने चाहिए।
यह वही समय है जब अजीब परिदृश्यों की जाँच करें। निलंबित यूज़र क्या देख सकता है? जब किसी admin को staff में डाउनग्रेड किया जाए तो क्या होता है? क्या कोई पुराना डेटा परिवर्तन के बाद भी दिखाई देता है?
यदि आप इन सवालों का सादे भाषा में जवाब दे सकते हैं तो आपकी भूमिका और अनुमति योजना शायद तैयार है। यदि नहीं, तो अब भूमिका मैप ठीक करें जब परिवर्तन सस्ते हों।
योजना को छोटे ब्रीफ़ में बदलें
सुरक्षित रूप से एक्सेस परिष्कृत करें
स्क्रीन और अनुमति नियम समायोजित करते समय snapshots और rollback का प्रयोग करें।
एक बार भूमिकाएँ स्पष्ट हो जाएँ, उन्हें टीम के लिए एक छोटे दस्तावेज़ में बदल दें जिसे कोई एक या दो मिनट में समझ सके। यह फॉर्मल होने की ज़रूरत नहीं—बस विशेष होना चाहिए।
हर भूमिका के लिए लिखें कि वे क्या देख सकते हैं, क्या बदल सकते हैं, और क्या उन्हें कभी नहीं छूना चाहिए। इसे व्यावहारिक रखें। एक owner बिलिंग और रिपोर्ट देख सकता है। Staff ऑर्डर और ग्राहक रिकॉर्ड अपडेट कर सकते हैं। Customers केवल अपना अकाउंट देख सकते हैं। Admins उपयोगकर्ताओं और सेटिंग्स को प्रबंधित कर सकते हैं पर ओनरशिप कंट्रोल नहीं ले सकते।
एक छोटा ब्रीफ़ आमतौर पर चार चीज़ें कवर करता है:
- ऐप में भूमिकाएँ
- हर भूमिका द्वारा की जाने वाली मुख्य क्रियाएँ
- वह डेटा जिसे हर भूमिका देख या एडिट कर सकती है
- कोई भी संवेदनशील क्षेत्र जिनमें अतिरिक्त सीमाएँ चाहिए
इस ब्रीफ़ का उपयोग स्क्रीन, वर्कफ़्लो और डेटा नियम जेनरेट करते समय करें। यह निर्माण प्रक्रिया को शुरू से ही गार्डरैइल देता है।
यह Koder.ai में और भी ज़्यादा महत्वपूर्ण है, जहाँ आप चैट से वेब, सर्वर, और मोबाइल ऐप बना सकते हैं। चूँकि जेनरेशन तेज़ है, एक स्पष्ट permission ब्रीफ़ पहले वर्ज़न को वही निकटतम रूप देता है जिसकी आपकी टीम वास्तव में ज़रूरत है।
आगे बढ़ने से पहले, पहले वर्ज़न की समीक्षा एक वास्तविक परिदृश्य लेकर करें—प्रत्येक भूमिका के लिए एक टेस्ट। owner के रूप में लॉगिन करें, staff के रूप में, customer और admin के रूप में। एक सामान्य कार्य पूरा करें, देखे कि कौन सा डेटा दिखाई दे रहा है, और एक ऐसा कार्य आज़माएँ जिसे ब्लॉक किया जाना चाहिए।
यह सरल पास उन समस्याओं को पकड़ लेता है जो योजना में और बाद के डिज़ाइन में आसानी से छूट जाती हैं। एक साफ भूमिका मैप, एक पन्ने का ब्रीफ़, और हर भूमिका के लिए एक त्वरित टेस्ट आमतौर पर अधिकांश एक्सेस गलतियों को रोकने के लिए पर्याप्त होते हैं।