एक परिवेश रणनीति स्थापित करना
Power Platform परिवेश वे कंटेनर हैं, जिनका उपयोग व्यवस्थापक ऐप्स, प्रवाहों, कनेक्शन और अन्य परिसंपत्तियों को प्रबंधित करने के लिए कर सकते हैं, साथ ही संगठन सदस्यों को संसाधनों का उपयोग करने की अनुमति देते हैं. इस आलेख में आपको Microsoft Power Platform में परिवेशों के बारे में महत्वपूर्ण विवरणों की जानकारी मिलती है और नियमित रूप से उन्हें प्रबंधित करने से लाभ के तरीकों पर चर्चा की गई है. अधिक जानकारी: Microsoft Power Platform परिवेशों का अवलोकन
परिवेश रणनीति विकसित करने का अर्थ है कि परिवेश और डेटा सुरक्षा की अन्य परतों को इस तरह से कॉन्फ़िगर करना, जो आपके संगठन में उत्पादक विकास का समर्थन करे, साथ ही संसाधनों को सुरक्षित और व्यवस्थित रखा जा सके. परिवेश की आपूर्ति और पहुँच को प्रबंधित करने और उनके भीतर संसाधनों को नियंत्रित करने की रणनीति निम्नलिखित के लिए महत्वपूर्ण है:
- डेटा और पहुँच को सुरक्षित करने.
- डिफ़ॉल्ट परिवेश का सही उपयोग करने का तरीका समझने.
- फैलाव से बचने और क्षमता के संरक्षण के लिए परिवेशों की सही संख्या का प्रबंधन करने.
- एप्लिकेशन जीवनचक्र प्रबंधन (ALM) को सुविधाजनक बनाने.
- संसाधनों को तार्किक विभाजनों में व्यवस्थित करने.
- उन ऐप की पहचान करने के लिए सहायता (और हेल्पडेस्क) वाले कार्यों में, जो समर्पित परिवेश में होने से संचालन में हैं.
- सुनिश्चित करें कि डेटा स्वीकार्य भौगोलिक क्षेत्रों (प्रदर्शन और अनुपालन कारणों से) में संग्रहीत और संचारित किया जा रहा है.
- डेवलप किए जा रहे एप्लिकेशन का अलगाव सुनिश्चित करें.
परिवेशों को समझें
शुरू करने से पहले, आइए परिवेश और सुरक्षा के संबंध में कुछ महत्वपूर्ण तथ्यों को देखते हैं:
- परिवेश उस भौगोलिक स्थान से जोड़े जाते हैं, जिसे परिवेश बनाने के समय कॉन्फ़िगर किया जाता है.
- परिवेशों का उपयोग विभिन्न ऑडियंस को लक्षित करने या विकास, परीक्षण और उत्पादन जैसे विभिन्न उद्देश्यों के लिए किया जा सकता है.
- डेटा हानि की रोकथाम (DLP) नीतियाँ व्यक्तिगत परिवेश या टैनेंट के लिए लागू की जा सकती हैं.
- प्रत्येक टेनेंट का एक डिफ़ॉल्ट वातावरण होता है .
- गैर-डिफ़ॉल्ट परिवेश लाइसेंस प्राप्त Power Apps, Power Automate और Dynamics 365 उपयोगकर्ताओं द्वारा बनाए जा सकते हैं. निर्माण को टैनेंट सेटिंग के माध्यम से केवल ग्लोबल और सेवा व्यवस्थापक तक सीमित किया जा सकता है.
- गैर-डिफ़ॉल्ट वातावरण अनुमतियों के आसपास अधिक नियंत्रण प्रदान करते हैं।
- परिवेश में एक या शून्य Microsoft Dataverse आवृत्तियाँ हो सकती हैं.
- परिवेशों में पूर्वनिर्धारित सुरक्षा भूमिकाएँ शामिल हैं जो परिभाषित किए गए पहुँच स्तरों वाले सामान्य उपयोगकर्ता कार्य दर्शाती हैं ताकि ऐप के उपयोग के लिए आवश्यक न्यूनतम मात्रा में व्यवसाय डेटा तक पहुँच प्रदान करने के लिए सुरक्षा-संबंधी सर्वश्रेष्ठ-प्रथा के लक्ष्य को पूरा किया जा सके.
- डिफ़ॉल्ट पर्यावरण रूटिंग एक प्रीमियम, शासन सुविधा है। यह सुविधा व्यवस्थापकों को नए निर्माताओं को पहली बार make.powerapps.com पर जाने पर स्वचालित रूप से अपने स्वयं के, व्यक्तिगत डेवलपर वातावरण में निर्देशित करने की अनुमति देती है। Power Platform
परिवेशों के प्रकार
इससे पहले कि आप पर्यावरण रणनीति विकसित करना शुरू करें, सुनिश्चित करें कि आप विभिन्न प्रकार के पर्यावरण को समझते हैं।
रणनीति विकसित करना
आपकी परिवेश रणनीति के लिए विचार करने के लिए प्रारंभिक बिंदु यह है.
अपने व्यवस्थापक को Microsoft Power Platform सेवा व्यवस्थापक या Dynamics 365 सेवा व्यवस्थापक भूमिका असाइन करें.
ये भूमिकाएँ Power Apps कैनवास ऐप, प्रवाह, मॉडल-चालित ऐप, परिवेश, कस्टम कनेक्टर, कनेक्शन, गेटवे, Power Apps पोर्टल, AI Builder मॉडल और सभी Dataverse आवृत्तियों तक व्यवस्थापकीय पहुँच प्रदान करती हैं. यह भूमिका उन व्यवस्थापकों को दी जानी चाहिए, जिन्हें ग्लोबल टैनेंट व्यवस्थापकीय पहुँच की आवश्यकता नहीं है और वे Microsoft Power Platform के प्रबंधन के लिए समर्पित हैं.शुद्ध नए संचालन परिवेश के निर्माण को व्यवस्थापक तक सीमित करें.
परिवेश निर्माण को सीमित करना सामान्य रूप से नियंत्रण बनाए रखने के लिए फायदेमंद रहता है: गैर-हिसाब क्षमता उपभोग को रोकने और प्रबंधित करने के लिए वातावरण की संख्या को कम करने दोनों के लिए. यदि उपयोगकर्ताओं को सेंट्रल IT से परिवेश का अनुरोध करना है, तो यह देखना आसान है कि व्यवस्थापक के द्वारपाल होने पर लोग क्या काम कर रहे हैं.डिफ़ॉल्ट परिवेश को अपने व्यावसायिक समूहों के लिए उपयोगकर्ता और टीम उत्पादकता परिवेश के रूप में मानें.
व्यवस्थापक केंद्र के माध्यम से परिवेश का नाम बदलने के लिए उस परिवेश का उद्देश्य स्पष्ट करने की सिफारिश की जाती है. स्पष्ट रूप से बताएँ कि डिफ़ॉल्ट का उपयोग उपयोगकर्ता और टीम उत्पादकता परिदृश्यों के लिए किया जाता है, लेकिन व्यवसाय के लिए महत्वपूर्ण या मिशन के लिए महत्वपूर्ण ऐप के लिए नहीं. इस परिवेश को अक्षम या हटाया नहीं जा सकता क्योंकि यह SharePoint जैसे उत्पादों और प्रोजेक्ट के साथ एकीकरण को होस्ट करता है. हम उपयोगकर्ता और टीम उत्पादकता परिवेश के लिए स्तरीय दृष्टिकोण की सलाह देते हैं.परिवेशों तक पहुँच या उसके निर्माण हेतु अनुरोध करने के लिए एक प्रक्रिया स्थापित करें.
परिवेश निर्माण के साथ लॉक-इन किए गए और प्रथम-पक्ष एकीकरण ऐप के लिए डिफ़ॉल्ट रूप से आरक्षित होने के साथ, आपके संगठन के लिए यह स्पष्ट कर देता है कि एक नए समर्पित परिवेश का अनुरोध करके एक उचित डेवलपमेंट प्रोजेक्ट शुरू किया जाना चाहिए, जहाँ पर डेवलपर और व्यवस्थापकों के बीच उद्देश्य और सहायता का स्पष्ट संचार हो. अगले सेक्शन में स्वचालित परिवेश निर्माण के बारे में अधिक विवरण दिया गया है, जो एक आसान औपचारिक अनुरोध प्रक्रिया को लागू करने का मात्र एक तरीका है.विशिष्ट व्यावसायिक समूहों या एप्लिकेशन के लिए विकास/परीक्षण/संचालन परिवेश.
अवस्था-युक्त परिवेश होने से यह सुनिश्चित होता है कि डेवलपमेंट के दौरान परिवर्तन उपयोगकर्ताओं को उत्पादन में अलग नहीं करते हैं और डेटा दूषित नहीं होता है. जब संसाधन सीमित होते हैं, तो इस पैटर्न को मिशन के लिए अत्यंत महत्वपूर्ण और महत्वपूर्ण ऐप या व्यावसायिक इकाइयों पर केंद्रित करें, जिनके लिए अपने स्वयं के समर्पित स्थान की सबसे अधिक आवश्यकता होती है.अवधारणाओं और प्रशिक्षण कार्यशालाओं के प्रमाण के लिए व्यक्तिगत-उपयोग का परिवेश.
कार्यशालाओं, हैकाथॉन और आंतरिक प्रशिक्षण इवेंट—जैसे एक दिन में ऐप या एक दिन में प्रवाह को होस्ट करने के लिए—सभी को व्यवस्थित रखने हेतुए इवेंट के लिए एक नया, अलग परिवेश बनाएँ. उपयोगकर्ताओं से कहें कि वे इवेंट के बाद अल्पावधि में आवश्यक संसाधनों को बचाएँ और परिवेश को साफ करें या अन्य इवेंट के लिए उसे रीसेट करें. परीक्षण परिवेशों का उपयोग करें, जो कि इस प्रकार की गतिविधियों के लिए क्षमता का उपभोग नहीं करते हैं.टैनेंट और परिवेश स्तर की डेटा हानि की रोकथाम (DLP) नीतियाँ स्थापित करें
डेटा हानि की रोकथाम (DLP) नीतियाँ, संगठनात्मक डेटा को गैरकानूनी रूप से प्रकट करने और टैनेंट में सूचना सुरक्षा को संरक्षित करने में उपयोगकर्ताओं की मदद करने के लिए रक्षक रेलिंग के रूप में कार्य करती हैं. Power Platform व्यवस्थापक भूमिका का एक अनिवार्य हिस्सा टैनेंट और परिवेश स्तर की DLP नीतियों को स्थापित और बनाए रखना होगा.
टीम और उपयोगकर्ता उत्पादकता वातावरण के लिए स्तरीय दृष्टिकोण
एकीकरण का समर्थन करने के लिए, आवश्यक परिवेशों की संख्या कम करें, और ऑनबोर्डिंग में तेज़ी लाएँ, हम ऐसे कई साझा परिवेश बनाने की सलाह देते हैं, जिनका उपयोग व्यक्तियों और टीमों द्वारा किया जा सकता है.
डिफ़ॉल्ट परिवेश
आपके टैनेंट में सभी को यहाँ पर ऐप और प्रवाह बनाने की अनुमतियाँ हैं. वर्तमान में इस परिवेश में परिवेश निर्माता भूमिका असाइनमेंट को अवरोधित करने का कोई तरीका नहीं है. यह वह परिवेश भी है, जिसका उपयोग प्रथम-पक्ष के एकीकरणों के लिए किया जाता है, जैसे कि किसी SharePoint सूची से ऐप बनाना. अधिक जानें: डिफ़ॉल्ट वातावरण
डेटा के जोखिम को कम करने के लिए, आपके ऐप और प्रवाह में उपयोग किए जाने वाले कनेक्टर के प्रकार कम अनुमति देने वाली डेटा हानि की रोकथाम (DLP) नीति तक सीमित होने चाहिए. इस नीति में सामान्य व्यक्तिगत और छोटी टीम उत्पादकता उपयोग मामलों को शामिल किया जाना चाहिए, जैसे कि SharePoint डेटा के साथ काम करना, ईमेल भेजना और अनुमोदन कार्यप्रवाह होना.
पावर उपयोगकर्ता परिवेश
जबकि डिफ़ॉल्ट वातावरण कई उपयोग मामलों को कवर करता है, कुछ पावर उपयोगकर्ताओं को अपने ऐप्स और प्रवाहों के लिए अधिक उन्नत आवश्यकताएं होंगी, जैसे Microsoft Teams, Microsoft Entra ID, या Azure DevOps के साथ एकीकरण करना।
इस उद्देश्य के लिए, हम एक पावर उपयोगकर्ता परिवेश बनाने की सलाह देते हैं. इस साझा परिवेश को अधिक रिआयती DLP नीतियों का उपयोग करना चाहिए और व्यवस्थापकों को इस परिवेश के लिए निर्माता सूची को नियंत्रित करना चाहिए।
पावर उपयोगकर्ता परिवेश के लिए कुछ विचार:
- इस परिवेश में उपलब्ध कनेक्टर की समीक्षा करें, जिससे कि यह सुनिश्चित हो सके कि यह आपके उपयोगकर्ताओं के लिए सही है.
- इस परिवेश में उद्देश्य और उपलब्ध कनेक्टरों को स्पष्ट रूप से दस्तावेज़ीकृत करें—उदाहरण के लिए, किसी SharePoint साइट या wiki पर.
- पावर उपयोगकर्ता परिवेश तक पहुँच हेतु अनुरोध करने के लिए निर्माताओं के लिए एक स्वचालित प्रक्रिया बनाएँ—उदाहरण के लिए, Microsoft Forms का उपयोग करके कोई SharePoint साइट या कोई ऐप. यदि आवश्यक हो, तो इस प्रक्रिया में लाइन मैनेजर या IT द्वारा अनुमोदन शामिल किया जा सकता है.
कस्टम परिवेश
जहाँ साझा किए गए परिवेश एप्लिकेशन के लिए कई उपयोग मामलों को शामिल करते हैं, टीमों और प्रोजेक्ट को अपने व्यावसायिक इकाई-विशिष्ट उपयोग मामलों या एप्लिकेशन जीवनचक्र प्रबंधन परिदृश्यों का समर्थन करने के लिए कस्टम परिवेश होने का लाभ हो सकता है.
कस्टम परिवेशों के लिए कुछ विचार:
- प्रोजेक्ट टीमों या व्यावसायिक इकाइयों के साथ यह स्थापित करने के लिए काम करें कि क्या उन्हें समर्पित विकास, परीक्षण और उत्पादन परिवेश की आवश्यकता है या कोई समर्पित विकास परिवेश और साझा परीक्षण और उत्पादन परिवेश उनके उपयोग के मामले में अधिक उपयुक्त है.
- महत्वपूर्ण प्रोजेक्ट और कार्यभार के लिए समर्पित परिवेशों पर विचार करें. डेवलपर के पास विकास के परिवेश में परिवेश निर्माता पहुँच होती है, लेकिन परीक्षण और संचालन परिवेश में केवल उपयोगकर्ता की पहुँच होती है. अंतिम उपयोगकर्ताओं के पास केवल उत्पादन समाधान के लिए उपयोगकर्ता की पहुँच होती है, जिससे कि कोई भी उत्पादन एप्लिकेशन को संशोधित न कर सके.
- मध्यम लेकिन महत्वपूर्ण एप्लिकेशन के बीच साझाकरण परीक्षण और संचालन परिवेशों पर विचार करें. डेटा की सुरक्षा के लिए व्यक्तिगत प्रोजेक्ट और व्यावसायिक इकाइयों का अपना विकास परिवेश होता है, लेकिन समाधान साझा परीक्षण और संचालन परिवेश में परिनियोजित किए जाते हैं. डेवलपर परीक्षण परिवेश में अंतिम उपयोगकर्ता होते हैं, और अंतिम उपयोगकर्ताओं के पास संचालन परिवेश में समाधान और डेटा तक केवल बुनियादी उपयोगकर्ता पहुँच होती है.
- यह स्थापित करने के लिए व्यवसाय इकाई के साथ काम करें कि कौन से कनेक्टर की आवश्यकता है और एक अपवाद नीति बनाएँ.
- यह स्थापित करने के लिए व्यवसाय इकाई के साथ काम करें कि इस परिवेश में निर्माता कौन होगा और परिवेश का व्यवस्थापक कौन होगा.
- प्रत्येक परिवेश में 1 GB डेटा क्षमता होती है, इसलिए कस्टम परिवेश का समझदारी से प्रबंधन करें.
उपरोक्त सुझावों के अलावा, आपकी परिवेश रणनीति स्थापित करने से आपकी DLP रणनीति को आकार और निर्देशन भी मिलेगा.
- हर कोई एक निर्माता है. सभी के साथ संवाद करें जो महत्वपूर्ण ऐप्स के विकास के लिए डिफ़ॉल्ट नहीं है।
- केवल एक उपयोगकर्ता के पास पहुँच होती है. डेवलपर परिवेश केवल उस उपयोगकर्ता को छोड़कर किसी भी अन्य उपयोगकर्ता के लिए पूरी तरह से लॉक होते हैं, जिसने सामुदायिक योजना की सदस्यता ली हुई है. आवश्यकता होने पर एप्लिकेशन को परिवेश से बाहर ले जाया जा सकता है.
- अनुमोदित उपयोगकर्ताओं के पास पहुँच होती है. अनुमोदित निर्माता सूची के साथ उपयोगकर्ता और टीम उत्पादकता परिदृश्यों के लिए साझा परिवेश.
- अत्यंत महत्वपूर्ण प्रोजेक्ट और कार्यभार के लिए समर्पित परिवेश. डेवलपर के पास विकास के परिवेश में परिवेश निर्माता पहुँच होती है, लेकिन परीक्षण और संचालन परिवेश में केवल उपयोगकर्ता की पहुँच होती है. अंतिम उपयोगकर्ताओं के पास केवल उत्पादन समाधान के लिए उपयोगकर्ता की पहुँच होती है, जिससे कि कोई भी उत्पादन एप्लिकेशन को संशोधित न कर सके.
- मध्यम लेकिन महत्वपूर्ण ऐप्स के लिए साझा परीक्षण और संचालन परिवेश. डेटा की सुरक्षा के लिए व्यक्तिगत प्रोजेक्ट और व्यावसायिक इकाइयों का अपना विकास परिवेश होता है, लेकिन समाधान साझा परीक्षण और संचालन परिवेश में परिनियोजित किए जाते हैं. डेवलपर परीक्षण परिवेश में अंतिम उपयोगकर्ता होते हैं, और अंतिम उपयोगकर्ताओं के पास संचालन परिवेश में समाधान और डेटा तक केवल बुनियादी उपयोगकर्ता पहुँच होती है.
परिवेशों का प्रबंधन करने के लिए अतिरिक्त सुझाव
ग्राहक सहभागिताओं के साथ सफल अनुभव के आधार पर, यहाँ पर अतिरिक्त सुझावों की एक सूची दी गई है, जो परिवेशों के प्रबंधन को आसान बनाने में मदद कर सकती है.
उत्पादन समाधान परिनियोजित करने के लिए एक सेवा खाते का उपयोग करें: एक सेवा खाता बनाएँ, जिसे सेंट्रल IT परीक्षण करें और संचालन परिवेशों में परिनियोजित करने का प्रबंधन करती हो. यह कई कारणों से फायदेमंद होता है:
- IT के सभी सदस्यों को व्यवस्थापक संसाधनों (जैसे परीक्षण और संचालन परिवेश) का प्रबंधन करने की अनुमति देता है.
- केवल सेवा खाते में परिवेश में व्यवस्थापक अनुमतियाँ होती हैं.
- अन्य सभी उपयोगकर्ताओं के पास उपयोगकर्ता अनुमतियाँ होती हैं और वे नए संसाधन नहीं बना सकते हैं—यह महत्वपूर्ण है क्योंकि यदि उपयोगकर्ताओं को डेटा कनेक्शन तक पहुँच प्रदान की जाती है, तो वे उस डेटा के साथ सहभागिता करने के लिए कोई नया इंटरफ़ेस बना सकते हैं, जो डेवलपर द्वारा इच्छित नहीं था.
- IT को उन उत्पादन-ग्रेड के एप्लिकेशन के बारे में पता होता है, जो क्रियान्वयन में शामिल होने के बाद से परिनियोजित होते हैं.
- सेवा खातों को PIM में Microsoft Power Platform या Dynamics 365 सेवा व्यवस्थापक अनुमति की आवश्यकता होगी. अनुरोध प्रक्रिया में कनेक्टर का उपयोग करने की आवश्यकता के आधार पर आवश्यकतानुसार अतिरिक्त लाइसेंस असाइन करें (उदाहरण के लिए, यदि Dataverse और Outlook का उपयोग किया जाता है, तो प्रीमियम Power Apps और Office Enterprise असाइन करें).
- किसी एप्लिकेशन के लिए विवरण प्रदर्शित करते समय, यह सेवा खाता को मेकर के रूप में नहीं, बल्कि क्रिएटर के रूप में दिखाएगा. इससे उपयोगकर्ताओं को यह जानने में मदद मिलेगी कि एप्लिकेशन में समस्याएँ होने पर किससे संपर्क करें.
विचार करें कि क्या सेवा खाता होने के जोखिम आपके लिए महत्वपूर्ण हैं. कुछ संगठन सेवा खाता रखने में सहज नहीं होते हैं क्योंकि, उदाहरण के लिए, व्यवस्थापक विशेषाधिकारों के साथ साझा संसाधन से किसी एक व्यक्ति को ट्रैक नहीं किया जा सकता है. यह मान्य है, लेकिन स्थान-आधारित सशर्त पहुँच को लागू करने, किसी IP में ऑडिट लॉग को ट्रैक करने या अधिक व्यापक तरीकों जैसे एक सुरक्षित पहुँच वर्कस्टेशन को बनाए रखने, जिसको उपयोग के दौरान उपयोगकर्ता पहचान की आवश्यकता होती है और उस डिवाइस तक सेवा खाते की पहुँच को सीमित करता है.
साझा डेवलपमेंट परिवेशों की संख्या कम करें
अलग-अलग प्रोजेक्ट विकास के लिए अलग-अलग परिवेश होता है, खासकर जब सुरक्षित डेटा के साथ काम कर रहे हों. परिवेश डेटा के कनेक्शन जैसे संसाधनों के लिए कंटेनर हैं और विकास के परिवेशों में परिवेश निर्माता पहुँच वाले एकाधिक लोग हो सकते हैं. यदि निर्माताओं के पास साझा डेटा कनेक्शन तक पहुँच होती है और वे ऐप और प्रवाह बना सकते हैं, तो एक जोखिम यह होता है कि कोई व्यक्ति डेटा को पढ़ने, अद्यतित करने और हटाने के लिए एक नया इंटरफ़ेस बना लेगा, जिस पर उन्हें पहुँच दी जा सकती है. डिफ़ॉल्ट परिवेश के लिए यह ध्यान रखना विशेष रूप से महत्वपूर्ण है—आपके पास हमेशा महत्वपूर्ण डेटा कनेक्शन, कस्टम कनेक्टर और अन्य परिसंपत्तियाँ होनी चाहिए, जिनकी सुरक्षा के लिए उन्हें अलग किए गए परिवेश में सुरक्षित करने की आवश्यकता होती है.
Microsoft Entra सुरक्षा समूहों के साथ संसाधन साझा करें
Power Apps, प्रवाह, Dataverse सुरक्षा भूमिकाएँ और अन्य Office 365 सेवाओं जैसे कि SharePoint ऑनलाइन तक पहुँच प्रबंधित करने के लिए सुरक्षा समूहों का उपयोग किया जा सकता है. यह प्रत्येक घटक के लिए अलग-अलग अंतिम उपयोगकर्ताओं तक पहुँच को अद्यतन करने के व्यवस्थापक के बोझ को हटाता है (विशेषकर यदि कई शामिल हों)—ऐप के स्वामी इसे बिना IT के सुरक्षा समूह स्तर पर संशोधित कर सकते हैं (जब तक कि IT सुरक्षा समूह प्रबंधन तक पहुँच को सीमित नहीं कर देता).
परिवेश निर्माण को स्वचालित करें
व्यवस्थापक कनेक्टर (Microsoft Power Platform for Admins) ऐसा अनुमोदन प्रवाह बनाने के लिए संभव बनाता है, जहाँ पर उपयोगकर्ता IT द्वारा परिवेश निर्माण को सीमित कर दिए जाने पर परिवेश का अनुरोध करते हैं. सेंट्रल IT व्यवस्थापक केंद्र में मैन्युअल रूप से जाने और उपयोगकर्ता के लिए परिवेश बनाने के लिए ज़िम्मेदार हुए बिना, केवल अनुरोध विवरण, व्यावसायिक औचित्य, DLP आवश्यकताओं और यह सत्यापित करने के लिए कि क्या पर्याप्त क्षमता उपलब्ध है, किसी अनुरोध की समीक्षा कर सकता है और परिवेश के निर्माण को अनुमोदित या अस्वीकार कर सकता है.
अस्थायी विकास परिवेश बनाएँ
जैसा कि उल्लेख किया गया है, जितना संभव हो उतना डेवलपमेंट परिवेशों को अलग करने और विशेष रूप से डिफ़ॉल्ट परिवेश में महत्वपूर्ण समाधानों के लिए एक साथ ऐप विकास से बचने की सिफारिश की जाती है. यदि विकास के उद्देश्यों के लिए परिवेश बनाया जाता है, तो इस बात की समय-सीमा निर्धारित करें कि डेवलपर के लिए परिवेश कब तक उपलब्ध होना चाहिए और उनका बैकअप लेने और हटाने के लिए एक प्रक्रिया होनी चाहिए.
कम बेहतर है
हालाँकि यह सुनिश्चित करना महत्वपूर्ण है कि परिवेश का उपयोग करने वाले प्रोजेक्ट और व्यावसायिक इकाइयों के बीच संसाधनों का उचित विभाजन किया गया हो, फिर भी सुरक्षा और व्यवहार्यता के बीच एक अच्छा संतुलन रखना महत्वपूर्ण होता है. क्षमता का संरक्षण और सर्वोत्तम प्रथाओं का पालन करते हुए साझा परीक्षण और संचालन परिवेशों का प्रबंधन बड़ी संख्या में महत्वपूर्ण समाधानों को सुविधाजनक बनाने का अच्छा तरीका है. यह सीमित अनुमतियों को बनाए रखता है क्योंकि परीक्षण और संचालन में परिवेश अनुमतियाँ सीमित हैं और इसलिए अंतिम उपयोगकर्ता एप्लिकेशन को संशोधित नहीं कर सकते हैं.
उपयुक्त क्षेत्र में Dataverse आवृत्तियों के साथ परिवेशों का प्रावधान करें
जिन कंपनियों में कर्मचारी एक से अधिक देशों/क्षेत्रों में काम करते हैं, वहां डेटा को कहां संग्रहीत किया जाता है और देशों/क्षेत्रों के बीच कहां भेजा जाता है, इस संबंध में कुछ अनुपालन संबंधी विचार हो सकते हैं। यदि परिवेश में Dataverse आवृत्ति है, तो डेटा को भौतिक रूप से इस क्षेत्र में संग्रहीत किया जा रहा है. समर्थित परिवेश क्षेत्रों की सूची की समीक्षा करें.
आपूर्ति को प्रभावित करने वाले कारक
कुछ कारक इस बात को प्रभावित करते हैं कि कब और किस प्रकार के परिवेश की आपूर्ति की जानी है:
एप्लिकेशन समर्थन के परिभाषित स्तर
जटिलता का स्तर, एप्लिकेशन कितना महत्वपूर्ण है और एप्लिकेशन द्वारा प्रभावित होने वाले उपयोगकर्ता (उदाहरण के लिए, किसी संगठन में मासिक सक्रिय उपयोगकर्ता/कुल उपयोगकर्ता) सभी परिदृश्यों का समर्थन करने के लिए परिवेश को प्रबंधित करने के तरीके के संबंध में सभी महत्वपूर्ण उपाय हैं.
विभिन्न प्रकार के एप्लिकेशन को इस आधार पर विभिन्न परिवेशों में अलग किया जाना चाहिए कि प्रत्येक कितना महत्वपूर्ण हैं.
मिशन के लिए महत्वपूर्ण परिदृश्य और/या उच्च-जटिलता और/या संगठन भर में उपयोग. सहायता IT के स्वामित्व में है. मज़बूत ALM प्रक्रिया (विकास/परीक्षण/संचालन). लंबे विकास चक्र, अक्सर न्यूनतम व्यवहार्य उत्पाद के लिए 3 महीने से अधिक के होते हैं. 
महत्वपूर्ण लेकिन अत्यंत महत्वपूर्ण और/या मध्यम जटिलता और/या व्यावसायिक इकाई के दायरे में नहीं है. IT की बदौलत, सहायता ऐप स्वामी या व्यावसायिक इकाई के स्वामित्व में है. ALM का उपयोग करने वाले परिवेश की सलाह दी जाती है लेकिन ऐसा आवश्यक नहीं हो सकता है. विकास आमतौर पर न्यूनतम व्यवहार्य उत्पाद के लिए तीन महीने से कम होता है. 
उत्पादकता ऐप, जिसे उच्च स्तर के नियंत्रण की आवश्यकता नहीं होती है. ऐप डेवलपर द्वारा समर्थित है. आमतौर पर, एप्लिकेशन जीवनचक्र प्रबंधन आवश्यक नहीं होता है. न्यूनतम व्यवहार्य उत्पाद के लिए दो सप्ताह से कम होता है. क्षमता
प्रत्येक परिवेश (परीक्षण और डेवलपर परिवेश के अलावा) शुरुआती प्रावधान में 1 GB का उपभोग करेगा. यदि आपके संगठन द्वारा प्रीमियम Power Apps या Dynamics 365 लाइसेंस के लिए भुगतान नहीं किया जाता है, तो परिवेश के प्रावधान के लिए यह एक बाधा हो सकती है और यह पूरे टैनेंट के लिए एक साझा क्षमता भी है, जिसे उन्हें आवंटित करने की आवश्यकता होती है, जिन्हें इसकी ज़रूरत होती है.
इसके द्वारा क्षमता का संरक्षण करें:
- साझा परीक्षण और संचालन परिवेश का प्रबंधन करके. साझा विकास परिवेशों के विपरीत, परीक्षण और संचालन परिवेशों में अनुमतियाँ परीक्षण के लिए अंतिम-उपयोगकर्ता पहुँच को सीमित होना चाहिए.
- अस्थायी विकास के परिवेशों की सफाई को स्वचालित करें और परीक्षण या अवधारणा-के-प्रमाण कार्य के लिए परीक्षण परिवेशों के उपयोग को प्रोत्साहित करें.
व्यवस्थापक की भागीदारी
टैनेंट में होने वाले प्रत्येक विकास प्रोजेक्ट में सेंट्रल IT को हमेशा शामिल करना संभव नहीं होता है, विशेष रूप से यदि IT टीम छोटी हो या प्रबंधन करने के लिए कोई बड़ा उद्यम हो.
इसके द्वारा व्यवस्थापक पर बोझ कम करें:
- परिवेश निर्माण को स्वचालित करके, जिससे कि टैनेंट व्यवस्थापक को केवल अनुरोध को अनुमोदित करने की आवश्यकता रहे.
- अस्थायी परिवेश के साथ विकास परिवेश की सफाई को स्वचालित करके.
अपने संगठन की परिवेश रणनीति को स्पष्ट रूप से निर्माताओं तक पहुँचाएँ
SharePoint साइट या कोई wiki सेट करें, जो निम्न का स्पष्ट रूप से संचार करता हो:
- आपके डिफ़ॉल्ट परिवेश का उद्देश्य.
- साझा टीम और उपयोगकर्ता संचालन परिवेश का उद्देश्य, अन्य साझा परिवेशों के निर्माताओं के अलावा, जिनकी उन परिवेशों तक पहुँच हो सकती है (उदाहरण के लिए, प्रशिक्षण परिवेश) और उन परिवेशों तक पहुँच का अनुरोध करने की प्रक्रिया.
- परीक्षण परिवेशों का उद्देश्य और उनका अनुरोध करने का तरीका.
- डेवलपर परिवेशों का उद्देश्य और उन्हें बनाने का तरीका
- विशिष्ट व्यावसायिक इकाई या प्रोजेक्ट उद्देश्यों के लिए कस्टम परिवेश का अनुरोध करने की प्रक्रिया.
- निर्माता की ज़िम्मेदारियाँ:
- टैनेंट को साफ रखें. यदि आवश्यकता न हो, तो अपने परिवेश, ऐप और प्रवाह को हटा दें. प्रयोग कर रहे हों, तो परीक्षण परिवेश का उपयोग करें.
- समझदारी से साझा करें. अपने परिवेशों, ऐप, प्रवाह और साझा किए गए कनेक्शनों के अधिक साझाकरण पर निगरानी रखें.
- संगठन का डेटा बचाएँ. अत्यधिक गोपनीय या गोपनीय डेटा स्रोतों से डेटा को गैर-संरक्षित या बाहरी संग्रहण में ले जाने से बचें.
इसके अलावा, अपने संगठन की DLP नीतियों के बारे में निर्माताओं को स्पष्ट रूप से बताएँ.