Microsoft का नया plugin registry एंटरप्राइज़ एप्लिकेशन में Copilot की क्षमताएँ बाँटना आसान बनाता है। लेकिन उन plugins जिन सिस्टम पर निर्भर करते हैं, उन्हें चलाने और सपोर्ट करने के लिए अब भी लोगों की ज़रूरत है।
एक कर्मचारी Copilot से किसी प्रोजेक्ट की ताज़ा स्थिति पूछता है और उसे कंपनी द्वारा स्वीकृत इंटीग्रेशन के ज़रिए आंतरिक प्रोजेक्ट-मैनेजमेंट सिस्टम से जानकारी मिल जाती है। यह सब ठीक चलता रहता है, फिर एक सुबह Copilot वह जानकारी लाना बंद कर देता है।
कर्मचारी Microsoft 365 सपोर्ट टीम को फ़ोन करता है। एक SharePoint एडमिनिस्ट्रेटर उपलब्ध कॉन्फ़िगरेशन जाँचता है, पर उसे कोई साफ़ गड़बड़ी नहीं दिखती। आख़िरकार एप्लिकेशन टीम पता लगाती है कि आंतरिक API के क्रेडेंशियल की अवधि समाप्त हो चुकी है।
समस्या SharePoint में नहीं, जुड़ी हुई सेवा में थी। यह काल्पनिक उदाहरण दिखाता है कि जब एक Copilot अनुभव के पीछे कई सिस्टम हों, तो जाने-पहचाने इंटीग्रेशन फ़ेल्योर का स्रोत उपयोगकर्ता के लिए, और उस पहली सपोर्ट टीम के लिए जिससे वे संपर्क करते हैं, ढूँढना और कठिन हो सकता है।
Microsoft ने क्या घोषणा की
September 30, 2026 को Microsoft ने समर्थित Copilot अनुभवों के लिए एक plugin registry की घोषणा की, जिनमें SharePoint भी शामिल है। यह plugins को खोजने, प्रकाशित करने, प्रबंधित करने और उन पर गवर्नेंस लागू करने के लिए एक साझा जगह देता है। एक plugin में skills, connectors और agents जैसी क्षमताएँ पैकेज की जा सकती हैं या उनका संदर्भ दिया जा सकता है। Microsoft की घोषणा registry को रोलआउट होता हुआ बताती है, जिसकी उपलब्धता अनुभव और क्षमता के अनुसार अलग-अलग है।
SharePoint के enterprise-store फ़ीचर की अपनी समय-सारणी है। Microsoft 365 roadmap item 567669 में August 2026 से प्रीव्यू शुरू होने और web पर SharePoint के लिए December 2026 का रिलीज़ लक्ष्य दर्ज है। ये नियोजित तिथियाँ हैं, इस बात का प्रमाण नहीं कि हर tenant के पास यह फ़ीचर पहले से मौजूद है। Microsoft 365 roadmap।
शब्दावली पर भी ध्यान देना ज़रूरी है। Copilot को जानकारी देने वाला connector, किसी दूसरे एप्लिकेशन में डेटा लाने या बदलने वाले API action के बराबर नहीं है। Microsoft के मौजूदा दस्तावेज़ API और MCP plugins को declarative agents के भीतर actions के रूप में रखते हैं, स्वतंत्र Microsoft 365 Copilot अनुभवों के रूप में नहीं। Microsoft Learn: MCP और API plugins।
एक plugin, रखरखाव के लिए कई सिस्टम
प्रोजेक्ट-स्थिति वाले उदाहरण में, एक agent किसी स्वीकृत action के ज़रिए प्रोजेक्ट-मैनेजमेंट API को कॉल कर सकता है। वह API Azure में चल सकती है, किसी दूसरी टीम द्वारा संभाले जा रहे identity कॉन्फ़िगरेशन का उपयोग कर सकती है, और ऐसे डेटाबेस पर निर्भर हो सकती है जिसे SharePoint एडमिनिस्ट्रेटर कभी छूता भी नहीं।
कर्मचारी की नज़र से देखें तो एक ही अनुरोध फ़ेल हुआ है। उसके पीछे गड़बड़ी agent कॉन्फ़िगरेशन, API authentication, नेटवर्क एक्सेस, एप्लिकेशन की उपलब्धता या API में किसी असंगत बदलाव में हो सकती है।
इसलिए ज़िम्मेदारी टीमों की सीमाओं के पार जाती है। Microsoft 365 एडमिनिस्ट्रेटर प्रबंधित करते हैं कि plugin कैसे उपलब्ध कराया जाए, डेवलपर API कॉन्ट्रैक्ट के मालिक होते हैं, identity टीमें एक्सेस की व्यवस्थाएँ संभालती हैं, और एप्लिकेशन ऑपरेशन्स टीमें सेवा की विफलताओं की जाँच करती हैं। सटीक बँटवारा संगठन के अनुसार अलग होता है। Microsoft का declarative-agent मार्गदर्शन साफ़ तौर पर कनेक्शन, अनुमतियाँ, मालिक और सपोर्ट संपर्क पहचानने की बात कहता है।
यह स्वामित्व इंटीग्रेशन बनाते समय ही तय हो जाना चाहिए। नहीं तो पहली प्रोडक्शन विफलता उस टीम को ढूँढने की कवायद बन जाती है जो उसका निदान कर सके।
Plugin हटाना पूरी रिटायरमेंट प्रक्रिया नहीं है
मान लीजिए संगठन बाद में प्रोजेक्ट-मैनेजमेंट एप्लिकेशन बदल देता है और उसका Copilot plugin हटा देता है। क्या इंटीग्रेशन पूरी तरह रिटायर हो गया?
Microsoft चेतावनी देता है कि किसी plugin को ब्लॉक या अनइंस्टॉल करने से ज़रूरी नहीं कि कोई remote सेवा बंद हो, दी गई सहमति रद्द हो या पहले से इंडेक्स किया गया connector डेटा हट जाए। दूसरे plugins भी उसी सेवा या connector पर निर्भर हो सकते हैं। Microsoft Learn: plugin एक्सेस और कनेक्शन का गवर्नेंस।
इसलिए रिटायरमेंट योजना में अनुपयोगी अनुमतियाँ रद्द करना, connector डेटा की समीक्षा, सेवा क्रेडेंशियल हटाना और यह पुष्टि करना शामिल हो सकता है कि साझा निर्भरताओं की अब भी ज़रूरत है। ये अलग-अलग कार्य हैं, registry से plugin हटाने के स्वचालित परिणाम नहीं।
इसका असर अपडेट पर भी पड़ता है। Authentication, API response या किसी remote टूल में बदलाव Copilot के इंटरैक्शन को तोड़ सकता है, भले ही प्रकाशित plugin खुद न बदला हो।
क्या सपोर्ट टीम किसी फ़ेल हुए अनुरोध को ट्रेस कर सकती है?
शुरुआती परिदृश्य में सपोर्ट टीम को तय करना होगा कि Copilot ने अपेक्षित इंटीग्रेशन को कॉल किया या नहीं, authentication सफल हुआ या नहीं, और API ने क्या लौटाया। संबंधित जानकारी Microsoft एडमिनिस्ट्रेशन, identity रिकॉर्ड, API लॉग और सेवा मॉनिटरिंग में बिखरी हो सकती है।
यह मान नहीं लेना चाहिए कि registry हर बाहरी ऑपरेशन के लिए पूरा end-to-end ऑडिट ट्रेल देता है। उपलब्ध डायग्नॉस्टिक्स इंटीग्रेशन के रास्ते और हर जुड़ी सेवा में कॉन्फ़िगर किए गए लॉगिंग पर निर्भर करते हैं। जहाँ actions बिज़नेस डेटा बदलते हैं, वहाँ एप्लिकेशन को अपनी ऑडिट ज़रूरतों के अनुसार यह भी दर्ज करना चाहिए कि बदलाव किसने या किस चीज़ ने शुरू किया।
इन रास्तों को परखने के लिए एक छोटा पायलट अच्छी जगह है। जानबूझकर किसी API अनुमति को अस्वीकार करें, बैकिंग सेवा को बाधित करें या किसी टेस्ट क्रेडेंशियल को बदलें। देखें कि उपयोगकर्ता को क्या दिखता है, कौन-सी टीम को अलर्ट मिलता है और उपलब्ध रिकॉर्ड कारण की पहचान कराते हैं या नहीं। इन जाँचों के लिए टेस्ट सिस्टम और गैर-संवेदनशील डेटा का उपयोग करें।
Microsoft का registry स्वीकृत Copilot क्षमताओं को बाँटना आसान बना सकता है। एंटरप्राइज़ को इस सुविधा से तब ज़्यादा लाभ मिलेगा जब वे यह भी तय करें कि हर जुड़े सिस्टम का मालिक कौन है और उसे कैसे सपोर्ट, अपडेट और रिटायर किया जाएगा। कर्मचारी को इंटीग्रेशन एक फ़ीचर जैसा दिख सकता है। उसे चालू रखना साझा इंजीनियरिंग ज़िम्मेदारी ही रहती है।
संदर्भ और आगे पढ़ने के लिए
Microsoft की घोषणा और दस्तावेज़ों के पन्नों को 14 अक्टूबर 2026 को जाँचा गया। Roadmap की तिथियाँ योजनाएँ हैं और बदल सकती हैं।
- Microsoft: Introducing the plugin registry. 30 सितंबर 2026 को प्रकाशित। घोषणा और समर्थित अनुभव।
- Microsoft 365 roadmap: item 567669. SharePoint enterprise-store plugin रोलआउट। निर्धारित तिथियाँ बदल सकती हैं।
- Microsoft Learn: MCP and API plugins for declarative agents. Actions और plugin वितरण के बीच तकनीकी अंतर।
- Microsoft Learn: Declarative agents. इंटीग्रेशन योजना और मालिक व निर्भरता संबंधी मार्गदर्शन।
- Microsoft Learn: Govern plugin access and connections. लाइफ़साइकिल नियंत्रण और घटकों का अलग-अलग प्रबंधन।