आंतरिक उपकरणों के लिए अनुमति मैट्रिक्स डिजाइन: भूमिकाएँ और स्कोप

अनुमति मैट्रिक्स किस समस्या को हल करती है

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

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

अनुमतियाँ जल्दी जटिल हो जाती हैं क्योंकि आंतरिक टूल परतों में बढ़ते हैं। नए रोल बनते हैं, पुराने विभाजित होते हैं, और एक-बार के अपवाद जमा हो जाते हैं: “मारिया को रिफंड की अनुमति दें”, “ठेका कर्मचारियों को नोट्स से रोकें”, “टीम लीड केवल $500 तक की मंज़ूरी दे सके।” जब ये नियम केवल लोगों के दिमाग में (या बिखरे टिकटों में) रहते हैं, तो स्क्रीन और API एंडपॉइंट अलग हो जाते हैं और सुरक्षा में गैप बन जाते हैं।

एक अनुमति मैट्रिक्स डिजाइन इसे ठीक करता है: यह यह तय करके एक साझा मानचित्र बनाता है कि कौन क्या कर सकता है, किस डेटा पर, और किन सीमाओं के साथ। यह UI निर्णयों (कौन से स्क्रीन, बटन, फील्ड दिखें) और बैकएंड निर्णयों (सर्वर वास्तव में क्या अनुमति देता है, भले ही कोई UI बायपास करने की कोशिश करे) दोनों के लिए ट्रू-सोर्स बन जाता है।

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

एक सरल मैट्रिक्स आपकी मदद करता है:

• बनाने से पहले नियम स्पष्ट करें
• “स्पेशल केस” अराजकता कम करें
• UI और API अनुमतियों को संरेखित रखें
• अनुमतियों के परिवर्तनों की समीक्षा बिना अटकलों के करें

मुख्य शब्द: रोल, संसाधन, क्रियाएँ, स्कोप, अपवाद

अच्छा अनुमति मैट्रिक्स डिजाइन साझा शब्दों से शुरू होता है। अगर आपकी टीम इन शब्दों को एक ही तरह समझती है, तो बाद में जटिल नियमों से बचा जा सकता है।

एक रोल काम-आधारित लोगों का समूह है जिन्हें आमतौर पर समान एक्सेस चाहिए। सोचें Support, Finance, Ops, या Manager। रोल्स को इस आधार पर परिभाषित करें कि कोई व्यक्ति अधिकांश दिनों में क्या करता है, न कि उनकी सीनियॉरिटी। एक व्यक्ति के पास एक से अधिक रोल हो सकते हैं, पर इसे दुर्लभ रखें।

एक संसाधन वह चीज़ है जिसे आप सुरक्षित रखते हैं। आंतरिक टूल में आम तौर पर संसाधन होते हैं: Customers, Tickets, Invoices, Reports, Integrations, Settings। संसाधनों को नाम देते समय संज्ञा (noun) का उपयोग करें। इससे बाद में नियमों को स्क्रीन और API एंडपॉइंट में बदलना आसान होता है।

एक क्रिया वह है जो कोई किसी संसाधन पर कर सकता है। क्रियाओं में एकरूप क्रिया-शब्द (verbs) रखें ताकि मैट्रिक्स पढ़ने योग्य रहे। सामान्य क्रियाएँ हैं:

• view
• create
• edit
• delete
• approve
• export

एक स्कोप यह तय करता है “कौन से रिकॉर्ड?” बिना नए रोल बनाये। स्कोप अक्सर सुरक्षित और असुरक्षित एक्सेस के बीच फर्क होते हैं। सामान्य स्कोप हैं:

• own (आपने जो रिकॉर्ड बनाए या जिन्हें असाइन किया गया है)
• team (आपका समूह)
• region (आपका क्षेत्र)
• all (सब कुछ)

एक अपवाद वह ओवरराइड है जो सामान्य रोल और स्कोप नियमों को तोड़ता है। अपवाद अस्थायी (किसी शिफ्ट के लिए), उपयोगकर्ता-विशेष (एक विशेषज्ञ को एक अतिरिक्त क्रिया चाहिए), या रिकॉर्ड-विशेष (एक VIP ग्राहक रिकॉर्ड लॉक्ड) हो सकते हैं। अपवादों को नियंत्रित ऋण की तरह मानें: ट्रैक करें किसने यह मंज़ूर किया, क्यों और कब तक मान्य है।

उदाहरण: एक Support एजेंट को “tickets देखना” स्कोप “team” के साथ मिल सकता है, पर एक घटना समीक्षा के लिए उसे अल्पकालिक अपवाद के तहत “tickets export” की अनुमति दी जा सकती है। AppMaster में बने टूल में, यदि आप रोल, संसाधन, क्रियाएँ और स्कोप शुरू से लगातार नाम देते हैं तो इस तरह के नियम बनाए रखना आसान होता है।

मैट्रिक्स बनाने से पहले निर्णय जो लेने हैं

शुरू करें यह तय करके कि आप वास्तव में क्या सुरक्षित कर रहे हैं। आंतरिक टूल के क्षेत्रों को संसाधन के रूप में सूचीबद्ध करें, न कि स्क्रीन के रूप में। एक स्क्रीन में “Orders”, “Refunds”, और “Customers” एक साथ दिख सकते हैं, पर ये अलग-अलग रिस्क वाले अलग संसाधन हैं।

एक भी अनुमति लिखने से पहले अपने क्रिया-शब्दों को मानकीकृत करें। छोटे शब्दों के अंतर बाद में डुप्लीकेट नियम बनाते हैं (edit बनाम update, remove बनाम delete, view बनाम read)। एक छोटा साझा सेट चुनें और हर संसाधन में वही रखें। अधिकांश आंतरिक टूल के लिए view, create, update, delete, approve, export का छोटा सेट काफ़ी होता है।

स्कोप अगला निर्णय है, और इसे आपकी कंपनी की सोच से मिलाना चाहिए। बहुत सारे स्कोप मैट्रिक्स को पढ़ने लायक नहीं छोड़ते; बहुत कम से लगातार अपवाद बनते हैं। एक छोटे सेट का लक्ष्य रखें जो आपकी संगठन संरचना में फ़िट हो, जैसे:

• own (आपके द्वारा बनाए रिकॉर्ड)
• team (आपकी टीम के रिकॉर्ड)
• location (एक शाखा या क्षेत्र)
• all (सब कुछ)
• none (कोई एक्सेस नहीं)

आपको “नहीं” के लिए स्पष्ट नियम की भी जरूरत है। क्या स्पष्ट रूप से मना है बनाम अप्रत्यक्ष रूप से अस्वीकार किया गया — तय करें। सामान्यतः implicit deny (जो सूचीबद्ध नहीं है वह अस्वीकार) सुरक्षित और सरल है। explicit forbid उपयोगी है जब आपके पास व्यापक एक्सेस है पर किसी विशेष क्रिया को ब्लॉक करना चाहते हैं, जैसे “Finance सभी invoices देख सकता है सिवाय delete के।”

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

यदि आप AppMaster में बना रहे हैं, तो ये निर्णय बाद में बैकएंड एंडपॉइंट्स और Business Process लॉजिक में साफ़ मैप होंगे, पर मैट्रिक्स पहले स्पष्ट होना चाहिए।

चरण-दर-चरण: खूद से अनुमति मैट्रिक्स बनाना

लोग क्या करते हैं उस काम से शुरुआत करें, उन स्क्रीन से नहीं जिन्हें आप बनाना चाहते हैं। अगर आप स्क्रीन से शुरू करेंगे, तो आप आज की UI को कॉपी करेंगे और असली नियम (जैसे कौन रिफंड अनुमोदित कर सकता है, या लॉक होने के बाद ग्राहक रिकॉर्ड कौन संपादित कर सकता है) मिस कर देंगे।

एक सरल तरीका मैट्रिक्स डिजाइन को कार्यों से एक्सेस तक का मानचित्र मानना है, और बाद में उसे आपके ऐप में बदलना है।

एक प्रायोगिक निर्माण क्रम

1. व्यापारिक कार्यों की आसान भाषा में सूची बनाएं। उदाहरण: “रिफंड जारी करना”, “ग्राहक का ईमेल बदलना”, “पिछले महीने के इनवॉइस एक्सपोर्ट करना”। इसे छोटा और वास्तविक रखें।

2. कार्यों को संसाधन और क्रियाओं में बदलें। संसाधन संज्ञाएँ हैं (Invoice, Ticket, Customer), क्रियाएँ क्रियात्मक शब्द (view, create, edit, approve, export) हैं। हर संसाधन के लिए एक मालिक असाइन करें: वह व्यक्ति जो किनारों के मामलों की व्याख्या कर सके और कह सके “हाँ, यह सही है।”

3. स्थिर टीमों के आधार पर रोल परिभाषित करें। Support, Finance, Operations, Team Lead जैसे समूहों का उपयोग करें। बार-बार बदलने वाले टाइटल (Senior, Junior) से बचें जब तक वे वास्तव में एक्सेस बदल न दें।

4. प्रत्येक रोल को वे न्यूनतम पहुँच दें जो उन्हें कार्य करने के लिए चाहिए। अगर Support को केवल सवालों का जवाब देने के लिए इनवॉइस देखने की जरूरत है, तो उन्हें डिफ़ॉल्ट रूप से “export” न दें। आप बाद में एक्सेस जोड़ सकते हैं, पर हटाना बाद में आदतों को तोड़ता है।

5. जहाँ मायने रखे वहां ही स्कोप जोड़ें। एक ही “edit” अनुमति के बजाय, स्कोप जैसे “edit own”, “edit assigned”, या “edit all” लिखें। यह बिना 50 रोल बनाए नियमों को स्पष्ट रखता है।

अपवादों को मैट्रिक्स के अंदर गंदे नोट्स के रूप में न रखें—अलग तालिका में कैप्चर करें। हर अपवाद का स्पष्ट कारण फ़ील्ड (compliance, fraud risk, separation of duties) और एक मंज़ूर करने वाला मालिक होना चाहिए।

यह पूरा होने के बाद, AppMaster जैसे टूल मैट्रिक्स को प्रोटेक्टेड एंडपॉइंट्स और एडमिन स्क्रीन में बदलना आसान बनाते हैं बिना निर्माण के दौरान अनुमान लगाए।

मैट्रिक्स को उपयोगी रखने के लिए संरचना

एक अनुमति मैट्रिक्स तभी मददगार है जब लोग उसे जल्दी पढ़ सकें। अगर यह सेल्स की एक विशाल दीवार बन जाए, तो टीमें इसका उपयोग बंद कर देंगी और अनुमति आपके उद्देश्य से भटकेगी।

शुरू में ही मैट्रिक्स को डोमेन के अनुसार विभाजित करें। सब कुछ के लिए एक शीट रखने के बजाय, व्यापार के हर क्षेत्र के लिए एक टैब रखें, जैसे Customers, Billing, Content। अधिकांश रोल्स केवल कुछ डोमेन्स को छूते हैं, इसलिए यह रिव्यू को तेज़ रखता है और गलती से बदलाव कम करता है।

टैब्स में एक सुसंगत नामकरण पैटर्न रखें। Resource.Action.Scope जैसे सरल फॉर्मैट से स्पष्ट होता है कि हर अनुमति का क्या अर्थ है, और यह उन डुप्लीकेट्स को रोकता है जो अलग दिखते हुए एक ही काम करते हैं। उदाहरण: Invoice.Approve.Department उसी तरह पढ़ता है जैसे Customer.Edit.Own।

जब आपको किनारा-केस मिलें, तो नई रोल बनाने का लालच टालें। सेल के बगल में संक्षिप्त नोट जोड़ें जो अपवाद को और कब लागू होता है यह बताए। उदाहरण: Support इनवॉइस देख सकता है, पर केवल ग्राहक पहचान सत्यापित होने के बाद। नोट अतिरिक्त UI चरण की ओर भी इशारा कर सकता है बिना रोल मॉडल बदले।

उচ্চ-जोखिम वाली अनुमतियों को फ़्लैग करें ताकि वे रिव्यू के दौरान अलग दिखें। ये क्रियाएँ जैसे refunds, approvals, exports, और delete हैं। सेल्स को चिन्हित करें और लिखें कि किस अतिरिक्त जांच की ज़रूरत है, जैसे दो-व्यक्ति की मंज़ूरी या मैनेजर-ओनली कन्फर्मेशन।

मैट्रिक्स को समय के साथ बनाए रखने के लिए इसे एक वास्तविक आर्टिफैक्ट की तरह वर्शन करें:

• v1, v2 आदि साथ में तारीख
• मालिक (एक जिम्मेदार व्यक्ति)
• संक्षिप्त परिवर्तन सारांश
• परिवर्तन का कारण (नया वर्कफ़्लो, ऑडिट फाइंडिंग)

एक बार मैट्रिक्स स्थिर हो जाए, तो AppMaster जैसे टूल में स्क्रीन और एंडपॉइंट बनाना आसान हो जाता है, क्योंकि हर बटन और API क्रिया एक स्पष्ट अनुमति नाम से जुड़ी होती है।

मैट्रिक्स को स्क्रीन और एंडपॉइंट्स में बदलना

एक अनुमति मैट्रिक्स तभी उपयोगी है जब वह दो जगह वास्तविक नियम बन जाए: आपकी API और आपकी UI। हर संसाधन (जैसे Tickets, Invoices, Users) को एक एन्डपॉइंट समूह मानकर शुरू करें। क्रियाएँ अपने मैट्रिक्स क्रिया शब्दों के साथ संरेखित रखें: view, create, edit, approve, export, delete।

API की तरफ, हर रिक्वेस्ट पर अनुमतियाँ लागू करें। UI चेक स्पष्टता के लिए मददगार हैं, पर वे सुरक्षा नहीं हैं। एक छिपा हुआ बटन सीधे API कॉल को नहीं रोकता।

मैट्रिक्स को API अनुमतियों में बदलने का एक सरल तरीका है अनुमतियों के नामों को सुसंगत रखना और उन्हें उस बाउंड्री पर अटैच करना जहाँ क्रिया होती है:

• tickets:view, tickets:edit, tickets:export
• invoices:view, invoices:approve, invoices:delete
• users:view, users:invite

फिर उन्हीं अनुमति नामों का उपयोग UI गेट्स चलाने के लिए करें: मेनू आइटम, पेज एक्सेस, बटन, और फ़ील्ड तक। उदाहरण के लिए, एक Support एजेंट टिकट लिस्ट देख सकता है और टिकट खोल सकता है, पर “Refund” फ़ील्ड केवल तभी एडिटेबल होगा जब उसके पास invoices:approve भी हो।

लिस्ट बनाम डिटेल एक्सेस में सावधान रहें। टीम्स को अक्सर “यह दिखाई दे कि कुछ मौजूद है” चाहिए पर रिकॉर्ड खुद नहीं दिखाना होता। इसका मतलब हो सकता है कि आप लिस्ट रिज़ल्ट्स में सीमित कॉलम्स दिखाएं, पर डिटेल खोलना तभी अनुमति दें जब यूज़र के पास डिटेल अनुमति हो (या कोई स्कोप चेक पास हो जैसे “मुझसे असाइन”)। यह जल्दी तय करें ताकि आप ऐसी लिस्ट स्क्रीन न बनाएं जो संवेदनशील डेटा लीक कर दे।

अंततः, उन क्रियाओं के लिए ऑडिट लॉगिंग मैप करें जो मायने रखती हैं। Export, delete, approve, रोल बदलना, और डेटा डाउनलोड को ऑडिट इवेंट बनाना चाहिए जिसमें कौन, क्या, कब और लक्ष्य रिकॉर्ड हो। AppMaster में बना रहे हैं तो आप इसे एंडपॉइंट लॉजिक और बिज़नेस प्रोसेस फ्लो में दर्शा सकते हैं ताकि वही नियम कार्रवाई और उसके ऑडिट एंट्री दोनों को ट्रिगर करे।

आम गलतियाँ और जाल

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

एक और आम जाल रोल स्प्रोल है। टीमें रोल्स जोड़ती रहती हैं (Support Level 1, Support Level 2, Support Manager, आदि) जबकि एक छोटा सेट रोल्स और साफ़ स्कोप काम कर देता। “own team”, “assigned region”, या “accounts you manage” जैसे स्कोप्स अक्सर नया रोल बनाने से बेहतर बताते हैं कि फर्क क्या है।

यहाँ कुछ गलतियाँ जो असली टूल्स में दिखती हैं:

• केवल “view” और “edit” परिभाषित करना, और फिर export, bulk edit, refund, impersonate, या “change owner” जैसी क्रियाओं को भूल जाना।
• अपवादों का लंबे समय तक पैच के रूप में उपयोग। एक-बार की ग्रांट्स (“सैम को एक हफ्ते के लिए Finance की पहुँच दें”) जल्दी ही स्थायी बन जाती हैं और एक टूटी रोल मॉडल को छिपाती हैं।
• UI में बटन छिपाकर यह मान लेना कि सिस्टम सुरक्षित है। API को अभी भी रिक्वेस्ट नकारनी चाहिए, भले ही कोई यूज़र एंडपॉइंट ढूंढ ले।
• यह न तय करना कि किसी के स्कोप बदलने पर क्या होता है, जैसे टीम ट्रान्सफर या क्षेत्र परिवर्तन। अनुमतियाँ पूर्वानुमेय रूप से अपडेट होनी चाहिए, न कि बहकनी चाहिए।
• “admin” को सीमाहीन समझना बिना सुरक्षा के। यहां तक कि एडमिन्स को अक्सर अलग-अलग सीमाएँ चाहिए, जैसे “यूज़र्स प्रबंधित कर सकता है” पर “payouts approve नहीं कर सकता।”

अपवादों को विशेष सावधानी की ज़रूरत है। वे अस्थायी स्थितियों के लिए उपयोगी हैं, पर उन्हें एक्सपायर या रिव्यू होना चाहिए। अगर अपवाद बढ़ते जाते हैं, तो यह संकेत है कि आपके रोल्स या स्कोप साफ़ नहीं मैप हुए हैं।

छोटी सी उदाहरण: सपोर्ट और फाइनेंस टूल में, Support ग्राहकों की प्रोफाइल देख सकता है और टिकट बना सकता है, पर Finance इनवॉइस एक्सपोर्ट और रिफंड कर सकता है। अगर आप केवल पेजेज़ को सुरक्षित करते हैं, तो एक Support एजेंट अभी भी सीधे export एंडपॉइंट कॉल कर सकता है। चाहे आप कस्टम कोड लिख रहे हों या AppMaster जैसे प्लेटफ़ॉर्म का उपयोग कर रहे हों, नियम सर्वर-साइड होने चाहिए, सिर्फ UI पर नहीं।

निर्माण से पहले त्वरित चेकलिस्ट

एक अनुमति मैट्रिक्स तभी उपयोगी है जब यह स्पष्ट, लागू करने योग्य नियम बन जाए। अपनी पहली स्क्रीन या एंडपॉइंट बनाने से पहले यह चेकलिस्ट चलाएँ। यह आपको “लगभग सुरक्षित” सेटअप से बचाएगा जो नए रोल या किनारे-केस आते ही टूट जाता है।

नियम बनाएँ, फिर UI बनाएं

डिफ़ॉल्ट रूप से अस्वीकार (default deny) सोच रखें: जो स्पष्ट रूप से अनुमति नहीं दी गई वह ब्लॉक रहे। यह सबसे सुरक्षित आधार है और नए फीचर्स जोड़ने पर सरप्राइज़ एक्सेस रोकता है।

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

यहाँ एक संकुचित प्री-बिल्ड चेकलिस्ट है जिसे आप अनुमति मैट्रिक्स डिजाइन के लिए उपयोग कर सकते हैं:

• Default deny हर जगह लागू है (UI बटन, API एंडपॉइंट, एक्सपोर्ट्स, बैकग्राउंड जॉब्स)।
• हर क्रिया के लिए स्पष्ट स्कोप परिभाषा है (own record, team, region, all, या नामित उपसमूह)।
• एडमिन क्षमताएँ बिजनेस क्रियाओं से अलग हैं (role management वही नहीं है जो “approve refund”)।
• संवेदनशील क्रियाओं के लिए मजबूत नियंत्रण चाहिए (अनुमोदन चरण, लॉगिंग, और असामान्य गतिविधि के लिए अलर्ट)।
• अपवादों का एक मालिक और समाप्ति तिथि है, ताकि “अस्थायी एक्सेस” स्थायी न बन जाए।

उसके बाद, एक वास्तविक परिदृश्य के साथ नियमों की सैनीटी-चेक करें। उदाहरण: “एक सपोर्ट एजेंट एक ऑर्डर देख सकता है और अपने क्षेत्र के लिए नोट जोड़ सकता है, पर कीमतें एडिट या रिफंड जनरेट नहीं कर सकता। फाइनेंस रिफंड कर सकता है, पर मैनेजर की मंज़ूरी के बाद ही, और हर रिफंड लॉग होता है।” अगर आप इसे एक-दो वाक्यों में नहीं कह सकते, तो आपके स्कोप और अपवाद अभी स्पष्ट नहीं हैं।

यदि आप AppMaster में बना रहे हैं, तो इन मदों को दोनों—स्क्रीन और बिज़नेस लॉजिक—के लिए आवश्यकताओं की तरह ट्रीट करें, सिर्फ़ UI के लिए नहीं। बटन एक्शंस को छिपा सकता है, पर केवल बैकएंड नियम उन्हें सच में रोकते हैं।

उदाहरण परिदृश्य: एक सपोर्ट और फाइनेंस आंतरिक टूल

कल्पना करें एक मिड-साइज़ कंपनी जिसमें Support और Finance द्वारा इस्तेमाल किया जाने वाला एक आंतरिक टूल है। वही डेटाबेस Customers, Tickets, Refunds, Payouts और छोटा Settings एरिया (टेम्पलेट्स और इंटीग्रेशन्स जैसी चीज़ें) रखता है। यहाँ एक साधारण लॉगिन चेक पर्याप्त नहीं होगा।

वे रोल्स जिनसे वे शुरुआत करते हैं:

• Support Agent: एक क्यू में टिकटों पर काम करता है
• Support Lead: क्यूज़ के पार मदद करता है और कुछ कार्रवाइयों को मंज़ूरी देता है
• Finance: पैसे-संबंधी काम संभालता है
• Ops Admin: एक्सेस कंट्रोल और सिस्टम सेटिंग्स का मालिक

एक व्यावहारिक अनुमति मैट्रिक्स शुरुआत में संसाधन-प्रति कार्रवाई लिखकर और फिर स्कोप के साथ उसे कड़ा करके बनता है।

Tickets के लिए, Support Agents केवल उन्हीं टिकटों के लिए टिकट की स्थिति देख और अपडेट कर सकते हैं जो उनकी असाइन की क्यू में हैं। वे नोट जोड़ सकते हैं, पर टिकट का ओनर बदल नहीं सकते। Support Leads वह सब कर सकते हैं जो Support Agent कर सकता है, और साथ ही अपने क्षेत्र के भीतर टिकट्स को रीऐसाइन कर सकते हैं।

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

Payouts और Settings के लिए, टूल सख्त रहता है: केवल Finance payouts देख सकता है, और केवल Ops Admin Settings बदल सकता है। Support इन स्क्रीन को देख भी नहीं पाएगा, जिससे प्रलोभन कम होता है और गलतियाँ घटती हैं।

अब एक अपवाद जोड़ें: एक Support Lead दो सप्ताह के लिए दूसरे क्षेत्र का कवर कर रहा है। व्यापक रोल जैसे Ops Admin देने के बजाय, मैट्रिक्स अस्थायी स्कोप विस्तार (Support Lead + Region B, एक्स्पायर डेट के साथ) जोड़ सकता है। यह एक ही अपवाद को रोल्स के बीच नकल करने से अधिक सुरक्षित बनाता है।

अगर आप इसे AppMaster में बनाते हैं, तो वही मैट्रिक्स UI में क्या दिखे और बैकएंड पर क्या अनुमति दी जाए इसे मार्गदर्शन करेगा, ताकि कोई भी Payouts या Settings को केवल API अनुमान लगाकर एक्सेस न कर सके।

समय के साथ अनुमतियों का परीक्षण और रखरखाव

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

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

फिर मैट्रिक्स को टेस्ट केस में बदल दें। हर नियम के लिए एक "अनुमत" पाथ और एक "नाकार" पाथ लिखें। नाकार पाथ को विशिष्ट बनाएं (क्या होना चाहिए) ताकि लोग उसे अनदेखा न कर दें।

• रोल: Support Agent. क्रिया: Refund. अपेक्षित: स्पष्ट संदेश के साथ अस्वीकृत, कोई डेटा न बदले।
• रोल: Finance. क्रिया: Refund. अपेक्षित: अनुमति, रिफंड रिकॉर्ड बने, अभिनेता और कारण लॉग हो।
• रोल: Manager. क्रिया: View tickets. स्कोप: team only. अपेक्षित: टीम टिकट देख सकता है, अन्य टीम्स के टिकट नहीं खोल सकता।

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

स्कोप्स का परीक्षण करने के लिए असली डेटा चाहिए। ownership, team, और region से भिन्न टेस्ट रिकॉर्ड बनाएँ। सत्यापित करें कि आप किसी अन्य स्कोप का ID अनुमान लगाकर उसे एक्सेस न कर सकें।

अंत में, संवेदनशील क्रियाओं (refunds, exports, role changes) के लिए क्या लॉग होगा यह तय करें। कौन किया, क्या बदला, कब और कहाँ से—ये सभी लॉग करें। लॉग्स की नियमित समीक्षा करें, और उन क्रियाओं के लिए अलर्ट जोड़ें जो दुर्लभ होनी चाहिए, जैसे अनुमति संपादन या बुल्क एक्सपोर्ट।

अगले कदम: मैट्रिक्स से कार्यशील आंतरिक टूल तक

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

एक छोटा वर्कशॉप (30 मिनट काफी है) करें जिसमें हर रोल का एक प्रतिनिधि और कुछ "रिसोर्स ओनर्स" (जो Customers, Invoices, Payouts, Tickets आदि के लिए जिम्मेदार हैं) शामिल हों। रोल्स, संसाधन, क्रियाएँ और स्कोप्स पर चर्चा करें, और जो भी "स्पेशल केस" लगें उन्हें नोट करें। अगर कोई अपवाद सामान्य लगता है, तो संभव है कि वह एक मिसिंग स्कोप हो।

फिर v1 मैट्रिक्स ड्राफ्ट करें और रिसोर्स ओनर्स के साथ फोकस्ड रिव्यू करें। व्यावहारिक रखें: “क्या Support इनवॉइस देख सकता है?” “क्या Finance ग्राहक विवरण एडिट कर सकता है?” अगर कोई हिचकिचाहट हो, तो नियम पहले सादा भाषा में कैप्चर करें; बाद में आप उसे औपचारिक बना सकते हैं।

v1 सहमत होने के बाद, एक डोमेन को एंड-टू-एंड बनाकर बनाएं। एक पतला हिस्सा चुनें जो डेटा, लॉजिक और UI सबको छुए (उदाहरण: Ticketing या Invoice approvals)। आपको यह जवाब देना चाहिए: कौन देख सकता है, कौन बदल सकता है, और जब वे कोशिश करें तो क्या होता है।

यदि आप AppMaster का उपयोग कर रहे हैं, तो मैट्रिक्स को प्रोडक्ट के हिस्सों से पहले मैप करें:

• Data Designer: संसाधनों को एंटिटीज (टेबल्स) के साथ संरेखित करें और उन मुख्य फ़ील्ड्स को चिह्नित करें जो स्कोप को प्रभावित करते हैं (जैसे team_id, region_id)
• Business Processes: उन्हें वहाँ लागू करें जहाँ परिवर्तन होते हैं (create, update, approve, export)
• UI visibility rules: वे क्रियाएँ छिपाएँ जो यूज़र नहीं कर सकते, और जब एक्सेस न मिले तो स्पष्ट “क्यों” संदेश दिखाएँ
• Endpoints: हर रोल को केवल वही एक्सपोज़ करें जिसकी उन्हें ज़रूरत है, और एडमिन-ओनली ऑपरेशन्स अलग रखें

एक सरल उदाहरण: दो रोल्स के साथ "Refund request" फ्लो बनाएं (Support बनाता है, Finance मंज़ूर करता है)। जब यह साफ़ काम करे, तब किनारों के मामलों को जोड़ें जैसे “Support केवल शुरुआत के 30 मिनट में कैंसल कर सकता है।”

एक छोटा आंतरिक टूल AppMaster में बनाकर रोल्स और फ्लोज़ को जल्दी मान्य करें, फिर मैट्रिक्स से इटरेट करें। लक्ष्य यह है कि आप 20 स्क्रीन और अनुमति-फिक्सों के ढेर बनने से पहले गलतफहमियों को पकड़ लें।