नीतियाँ नियंत्रित करती हैं कि आपकी Organization में कार्रवाइयाँ तुरंत पूरी होती हैं या पहले अन्य Members द्वारा अनुमोदित की जानी चाहिए। प्रत्येक workflow की अपनी स्वतंत्र रूप से कॉन्फ़िगर करने योग्य नीति होती है। यह लेख बताता है कि अनुमोदन, नीतियाँ और लॉकिंग एक साथ कैसे काम करते हैं। अनुमतियों और workflows की संरचना के लिए, अनुमतियाँ और workflow देखें। उच्च-स्तरीय अवलोकन के लिए, Organizations के बारे में देखें।
एक Organization में प्रत्येक नियंत्रित कार्रवाई एक ही जीवनचक्र का पालन करती है:
चरण 1 — Initiation: Initiate या Execute permission वाला एक Member एक request बनाता है।
चरण 2 — तत्काल पूर्णता जाँच: यदि Member के पास Execute है और workflow के लिए approval की आवश्यकता नहीं है ("Always require approval" OFF है), तो request तुरंत पूरी हो जाती है। कोई approval queue नहीं, कोई प्रतीक्षा नहीं।
चरण 3 — Approval queue: यदि request तुरंत पूरी नहीं की जा सकती है — या तो इसलिए कि Member के पास Execute नहीं है, या इसलिए कि "Always require approval" ON है — तो request approval queue में प्रवेश करती है। उस workflow पर Approve permission वाले Member इसकी समीक्षा कर सकते हैं।
चरण 4 — Approval threshold: एक बार जब स्वतंत्र approvals की आवश्यक संख्या पूरी हो जाती है, तो request पूरी हो जाती है।
चरण 5 — Rejection: कोई भी अकेला approver लंबित request को अस्वीकार कर सकता है। अस्वीकृत request पूरी नहीं होती है।
कोई Member अपनी स्वयं की request को approve नहीं कर सकता। यह नियम सभी workflows में सिस्टम द्वारा लागू किया जाता है और किसी भी permission या policy configuration द्वारा इसे ओवरराइड नहीं किया जा सकता है।
एक अकेले Member द्वारा अकेले किसी कार्रवाई को पूरा करने का एकमात्र तरीका Execute के माध्यम से है, और तभी जब workflow policy इसकी अनुमति देती है।
Execute permission "Always require approval" policy setting के साथ इंटरैक्ट करती है:
सदस्य की अनुमतियाँ | "हमेशा अनुमोदन की आवश्यकता होगी" | क्या होता है |
|---|---|---|
इनिशिएट + एग्जीक्यूट | बंद | Request तुरंत पूरी हो गई, किसी approval की आवश्यकता नहीं |
इनिशिएट + एग्जीक्यूट | चालू | Request approval queue में प्रवेश करती है, स्वतंत्र approvers का इंतजार करना होगा |
महत्वपूर्ण: Execute तभी काम करता है जब workflow policy तत्काल पूर्णता की अनुमति देती है। जब "Always require approval" ON होता है, तो Execute का कोई प्रभाव नहीं होता — सभी requests को स्वतंत्र Members द्वारा approved किया जाना चाहिए।
Execute Member से नहीं हटता है। यह permission configuration में दिखाई देता रहता है, लेकिन जब "Always require approval" ON होता है तो सिस्टम इसे अनदेखा करता है। UI Execute कॉलम पर चेतावनी-रंग का संकेतक दिखाता है। यदि आप बाद में "Always require approval" को वापस OFF करते हैं, तो Member को permission को फिर से असाइन किए बिना फिर से तुरंत कार्य पूरे कर सकता है।
जब कोई Member Execute का उपयोग करके तुरंत (स्वतंत्र approvers के बिना) एक whitelisted address जोड़ता या हटाता है, तो परिवर्तन प्रभावी होने से पहले सिस्टम एक email confirmation भेजता है। address परिवर्तन तब तक अंतिम नहीं होता जब तक confirmation पूरा नहीं हो जाता।
Beta के दौरान, email confirmation Organization Owner को भेजी जाती है, भले ही Member ने परिवर्तन शुरू किया हो। request creator को सीधे confirmation भेजना भविष्य के release के लिए नियोजित है।
डिवाइस ट्रस्ट की स्थिति इस व्यवहार को प्रभावित नहीं करती है — तत्काल पता परिवर्तनों के लिए हमेशा ईमेल पुष्टि की आवश्यकता होती है।
जब पता परिवर्तन का अनुरोध स्वतंत्र अनुमोदकों के साथ मानक अनुमोदन प्रक्रिया से गुजरता है, तो ईमेल पुष्टि की कोई आवश्यकता नहीं होती है। अन्य सदस्यों से अनुमोदन सुरक्षा नियंत्रण के रूप में कार्य करता है।
यदि नीतियों को प्रबंधित करें वर्कफ़्लो में ही कोई नीति कॉन्फ़िगर की गई है, तो आपके परिवर्तन अनुमोदन कतार में प्रवेश कर सकते हैं। नीति शासन कैसे काम करता है, इसके विवरण के लिए नीतियों को लॉक करना देखें।
महत्वपूर्ण: आवश्यक अनुमोदन संख्या निर्धारित करने से पहले, सुनिश्चित करें कि लक्ष्य वर्कफ़्लो पर पर्याप्त सदस्यों के पास अनुमोदन की अनुमति है ताकि वे सीमा को पूरा कर सकें। सिस्टम ऐसी कॉन्फ़िगरेशन को रोकता है जिन्हें पूरा नहीं किया जा सकता है।
प्रत्येक वर्कफ़्लो की अपनी नीति होती है जिसमें दो सेटिंग्स होती हैं:
सेटिंग | यह क्या करता है |
|---|---|
आवश्यक अनुमोदन | विशिष्ट अनुमोदकों की संख्या जिन्हें अनुरोध पूरा होने से पहले स्वीकृति देनी होगी। अनुमोदकों को उस वर्कफ़्लो पर अनुमोदन की अनुमति वाले सदस्यों के समूह से चुना जाता है। जिस व्यक्ति ने अनुरोध शुरू किया था, उसे हमेशा अनुमोदक समूह से बाहर रखा जाता है। |
हमेशा अनुमोदन की आवश्यकता होती है | जब 'चालू' (ON) हो: सभी अनुरोधों को अनुमोदन से गुजरना होगा, भले ही सदस्य के पास एक्सेक्यूट की अनुमति हो। जब 'बंद' (OFF) हो: एक्सेक्यूट वाले सदस्य तुरंत कार्य पूरा कर सकते हैं। |
नीति को लॉक करने से कोई भी एक सदस्य, जिसमें ऑर्गनाइजेशन का मालिक भी शामिल है, अकेले किसी वर्कफ़्लो की शासन सेटिंग्स को बदलने से रोका जा सकता है।
जब कोई नीति लॉक हो जाती है:
एक बार जब शासन लॉक हो जाता है, तो कोई भी व्यक्ति इसे अकेले कमजोर नहीं कर सकता। भविष्य के परिवर्तन अभी भी संभव हैं, लेकिन वे स्वतंत्र अनुमोदन और अनुमोदक कवरेज के उपलब्ध रहने पर निर्भर करते हैं।
दायरा: नीति को लॉक करना प्रति वर्कफ़्लो लागू होता है। एक वर्कफ़्लो की नीति को लॉक करने से किसी अन्य वर्कफ़्लो पर कोई प्रभाव नहीं पड़ता है। यह आपको शासन को धीरे-धीरे, एक-एक वर्कफ़्लो करके मजबूत करने देता है।
ये दो नियंत्रण अलग-अलग स्तरों पर एक ही लक्ष्य की पूर्ति करते हैं:
नियंत्रण | दायरा | प्रभाव |
|---|---|---|
नीति लॉक | एक समय में एक वर्कफ़्लो | उस विशिष्ट वर्कफ़्लो की नीति में परिवर्तनों के लिए स्वतंत्र अनुमोदन की आवश्यकता होती है। अन्य वर्कफ़्लो अप्रभावित रहते हैं। |
मैनेज पॉलिसीज़ पर "हमेशा मंज़ूरी की आवश्यकता है" | सभी वर्कफ़्लो एक साथ | हर वर्कफ़्लो में सभी नीति परिवर्तनों के लिए स्वतंत्र मंज़ूरी की आवश्यकता होती है। यह एक थोक गवर्नेंस स्विच के रूप में कार्य करता है। |
बढ़ते हुए सख्त करने के लिए पॉलिसी लॉक का उपयोग करें। मैनेज पॉलिसीज़ पर "हमेशा मंज़ूरी की आवश्यकता है" का उपयोग तभी करें जब आप सभी नीति परिवर्तनों को एक साथ गवर्न करना चाहते हों।
सिस्टम अमान्य या अप्रवर्तनीय कॉन्फ़िगरेशन को रोकने के लिए सुरक्षा उपाय लागू करता है:
मंज़ूरकर्ता की उपलब्धता: किसी नीति को तब तक लॉक नहीं किया जा सकता जब तक कि कम से कम एक अन्य सदस्य (लॉक करने वाले व्यक्ति के अलावा) के पास मैनेज पॉलिसीज़ वर्कफ़्लो पर 'मंज़ूर करें' की अनुमति न हो। इसके बिना, एक लॉक की गई नीति एक गतिरोध पैदा कर सकती है जहाँ कोई भी भविष्य के परिवर्तनों को मंज़ूर नहीं कर पाएगा।
लॉकआउट रोकथाम: सिस्टम किसी नीति को सहेजने से रोकता है जब किसी वर्कफ़्लो पर 'मंज़ूर करें' की अनुमति वाला एकमात्र सदस्य 'शुरू करें' की अनुमति भी रखता हो और आवश्यक मंज़ूरी गणना 1 हो। चूंकि सदस्य अपने स्वयं के अनुरोधों को मंज़ूर नहीं कर सकते हैं, इस सदस्य के अनुरोधों के लिए कोई योग्य मंज़ूरकर्ता नहीं होगा।
निष्क्रियकरण मंज़ूरकर्ता कवरेज की जांच नहीं करता है: किसी सदस्य को निष्क्रिय करना या हटाना तब भी आगे बढ़ता है जब यह वर्कफ़्लो के लिए आवश्यक सीमा से नीचे उपलब्ध मंज़ूरकर्ताओं की संख्या को कम कर देता है। निष्क्रियकरण के लिए स्वचालित कवरेज जांच भविष्य के रिलीज़ के लिए नियोजित हैं। तब तक, यह सत्यापित करें कि किसी सदस्य को निष्क्रिय करने से पहले प्रभावित वर्कफ़्लो पर आवश्यक मंज़ूरी गणना को पूरा करने के लिए 'मंज़ूर करें' की अनुमति वाले पर्याप्त अन्य सदस्य सक्रिय रहें, या सहायता के लिए सहायता टीम से संपर्क करें।
एक बार जब आप समझ जाते हैं कि नीतियां और अनुमोदन कैसे काम करते हैं, तो शासन लागू करना देखें, जिसमें अनुमोदन आवश्यकताओं को एक-एक करके वर्कफ़्लो में पेश करने के लिए एक चरण-दर-चरण मार्गदर्शिका है, जिसमें चयनात्मक और पूर्ण शासन कॉन्फ़िगरेशन दिखाने वाले उदाहरण भी शामिल हैं।