> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/get-started/hi/platform/enterprise-features/recommended-enterprise-access-setup.md). # अनुशंसित पहुँच सेटअप कस्टम भूमिकाएँ, Auth Groups, और folder permissions को मिलाएँ ताकि एक भूमिका बताए कि कोई व्यक्ति क्या कर सकता है और एक group बताए कि कहाँ। यह पृष्ठ कई साइटों, व्यावसायिक इकाइयों या टीमों वाले वर्कस्पेस के लिए अनुशंसित अभिगम मॉडल का वर्णन करता है। इसमें तीन विशेषताएँ शामिल हैं, जिनका दस्तावेज़ अलग-अलग है: [भूमिका-आधारित अभिगम नियंत्रण](/get-started/hi/platform/enterprise-features/role-based-access-control.md), [प्रोजेक्ट फ़ोल्डर अनुमतियाँ](https://docs.roboflow.com/datasets/manage/project-folders/project-folder-permissions) और Auth Groups. स्क्रीनशॉट इस तरह सेट किए गए उदाहरण वर्कस्पेस से लिए गए हैं। {% hint style="info" %} कस्टम भूमिकाएँ, Auth Groups, फ़ोल्डर अनुमतियाँ और SSO समूह मैपिंग Enterprise सुविधाएँ हैं। संपर्क करें [Roboflow बिक्री टीम](https://roboflow.com/sales) या उन्हें सक्षम कराने के लिए अपने खाता प्रतिनिधि से संपर्क करें। {% endhint %} ## भूमिकाएँ बताती हैं क्या, समूह बतातें हैं कहाँ भूमिका नाम में स्थान जोड़ना (जैसे: Engineer-PlantA, Engineer-PlantB) भूमिकाओं की संख्या बढ़ा देता है, और प्रतियाँ समय के साथ अलग-अलग दिशा में चली जाती हैं। प्रश्न को दो भागों में बाँटें। * एक भूमिका निर्धारित करती है कि कोई व्यक्ति क्या कर सकता है: एनोटेट करना, ट्रेन करना, डिप्लॉय करना, API कुंजियाँ प्रबंधित करना, फ़ोल्डर प्रबंधित करना। भूमिकाएँ पूरे वर्कस्पेस पर लागू होती हैं। * एक Auth Group निर्धारित करता है कि वे यह कहाँ कर सकते हैं। समूहों को फ़ोल्डरों पर केवल-पढ़ने की या पढ़ने एवं लिखने की अनुमति दी जाती है। सदस्यता मैन्युअल होती है या SSO समूहों से मैप की जाती है। Plant A में एक production engineer की भूमिका: Eng-Prod तथा समूह: Plant A होता है। Plant B का एक आगंतुक जो Plant A के मॉडल्स की समीक्षा करता है, अपनी स्वयं की भूमिका बनाए रखता है और समूह अनुदान के माध्यम से Plant A फ़ोल्डर पर केवल-पढ़ने की अनुमति पाता है। किसी स्थान के लिए कोई भूमिका नहीं बनाई जाती।
Roles tab listing Admin, Labeler, Reviewer, Eng-Dev, Eng-Prod, Read Only and Site Admin

अंतर्निहित भूमिकाओं के साथ "भूमिकाएँ" टैब, साथ में Read Only, Eng-Dev, Eng-Prod और Site Admin।

## अनुशंसित भूमिका-सीढ़ी पाँच भूमिकाएँ, सबसे कम से सबसे अधिक पहुँच तक। | भूमिका | सामान्य धारक | वे क्या कर सकते हैं | | ------------------------- | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | नया उपयोगकर्ता (डिफ़ॉल्ट) | हर नया लॉगिन | असाइन किए जाने तक कुछ नहीं। | | केवल-पढ़ने की अनुमति | ऑपरेटर, ऑडिटर, आगंतुक | परियोजनाएँ, मॉडल, Vision Events और डिवाइस मॉनिटरिंग देखें। ऐप में इन्फ़ेरेंस चलाएँ। कोई एनोटेशन, ट्रेनिंग या डिप्लॉय नहीं। | | Eng-Dev | विकास इंजीनियर | डेटासेट बनाएँ, एनोटेट करें, अपलोड करें, ट्रेन करें, संस्करण बनाएँ, जॉब चलाएँ। कोई डिप्लॉय नहीं, कोई कुंजी प्रबंधन नहीं, कोई फ़ोल्डर निर्माण नहीं। | | Eng-Prod | उत्पादन इंजीनियर | Eng-Dev के साथ डिप्लॉय करना, मॉडल और वर्कफ़्लो प्रबंधित करना, डिवाइस प्रबंधित करना, Vision Events बनाना, बैच जॉब चलाना। जिन फ़ोल्डरों तक उनकी पहुँच है, उनमें API कुंजियों का पूरा जीवनचक्र (बनाना, अपडेट करना, रद्द करना)। | | साइट प्रशासक | प्रति साइट एक या दो लोग | वर्कस्पेस प्रशासन और सदस्य प्रबंधन को छोड़कर सब कुछ। फ़ोल्डर बनाता है, समूहों को फ़ोल्डर पहुँच देता है, कुंजियाँ प्रबंधित करता है, आँकड़े और ऑडिट लॉग पढ़ता है। | | प्रशासक (अंतर्निहित) | केंद्रीय IT, प्रोग्राम लीड | वर्कस्पेस-व्यापी API कुंजियों, बिलिंग, SSO और कस्टम भूमिकाओं सहित पूर्ण पहुँच। | इंजीनियर फ़ोल्डर नहीं बनाते। फ़ोल्डर ट्री (जैसे: Business Unit > Site > Environment) गवर्नेंस संरचना है, इसलिए फ़ोल्डर निर्माण Site Admin और Admin के पास रहता है। केवल Admin को workspace-व्यापी API कुंजियाँ दिखाई देती हैं। Site Admin और Eng-Prod फ़ोल्डर कुंजियों के साथ काम करते हैं, जिससे सबसे संवेदनशील क्रेडेंशियल सबसे कम लोगों के पास रहते हैं।
Edit Role dialog for Eng-Prod showing the API keys permission group

Eng-Prod, "API keys" समूह: create, update और revoke चालू, "Use and Copy API Keys" चालू, "View Workspace API Keys" बंद.

Edit Role dialog for Site Admin showing the Workspace Management permission group

Site Admin, "Workspace Management" समूह: केवल "View Workspace Settings" और "View Audit Logs"।

## एक भूमिका क्या कर सकती है और कहाँ देख सकती है किसी व्यक्ति की प्रभावी पहुँच भूमिका और फ़ोल्डर अनुदान के प्रतिच्छेद से तय होती है। भूमिका स्तंभ तय करती है, अनुदान पंक्ति तय करता है। | व्यक्ति के समूह के लिए फ़ोल्डर अनुदान | केवल-पढ़ने की अनुमति | Eng-Dev | Eng-Prod | साइट प्रशासक | प्रशासक | | ------------------------------------- | ------------------------------------------ | -------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------- | | कोई अनुदान नहीं | फ़ोल्डर छिपा हुआ | फ़ोल्डर छिपा हुआ | फ़ोल्डर छिपा हुआ | फ़ोल्डर छिपा हुआ | पूर्ण पहुँच (सभी फ़ोल्डर पहुँच) | | केवल-पढ़ने की अनुमति | परियोजनाएँ और मॉडल देखें, इन्फ़ेरेंस चलाएँ | Read Only के समान | देखें, साथ ही फ़ोल्डर की API कुंजियाँ प्रबंधित करें (नोट देखें) | देखें, साथ ही फ़ोल्डर की API कुंजियाँ प्रबंधित करें (नोट देखें) | पूर्ण पहुँच | | पढ़ें एवं लिखें | देखें, इन्फ़ेरेंस चलाएँ | एनोटेट करें, अपलोड करें, ट्रेन करें, संस्करण बनाएँ | Eng-Dev के साथ डिप्लॉय, वर्कफ़्लो, डिवाइस, Vision Events, API कुंजियाँ | Eng-Prod के साथ उप-फ़ोल्डर बनाएँ और फ़ोल्डर को समूहों के साथ साझा करें | पूर्ण पहुँच | कुंजी से जुड़ी कार्रवाइयाँ भूमिका का अनुसरण करती हैं, जहाँ भी फ़ोल्डर पहुँच योग्य हो। आगंतुकों को केवल आवश्यकता होने पर और किसी समूह के माध्यम से ही Read-Only दें, ताकि इसे एक ही स्थान से हटाया जा सके। हर व्यक्ति ग्रिड की एक ही सेल में होता है। पंक्तियाँ भूमिकाएँ हैं, कॉलम स्थान हैं। | **भूमिका** | **Plant A फ़ोल्डर** | **Plant B फ़ोल्डर** | **सभी फ़ोल्डर** | | ------------------------ | ------------------- | ------------------- | --------------- | | **केवल-पढ़ने की अनुमति** | लाइन ऑपरेटर | आने वाला ऑडिटर | | | **Eng-Dev** | विकास इंजीनियर | | | | **Eng-Prod** | उत्पादन इंजीनियर | (Read-Only विज़िट) | | | **साइट प्रशासक** | Plant A लीड | Plant B लीड | | | **प्रशासक** | | | केंद्रीय IT | स्थानांतरण व्यक्ति का समूह बदलता है। पदोन्नति उनकी भूमिका बदलती है। ## इसे सेट करना ### भूमिकाएँ बनाएँ Settings, "Team Members", "Roles" पर जाएँ और "New Role" पर क्लिक करें। ऊपर दी गई सीढ़ी से प्रत्येक भूमिका बनाएँ। सबसे निकटतम अंतर्निहित भूमिका से "Duplicate Permissions From" के साथ शुरू करें और समायोजित करें। एडिटर में अनुमति समूह (जैसे: "Workspace Management", "User & Team Management", "API keys") तालिका की श्रेणियों से मेल खाते हैं। देखें [एक कस्टम भूमिका बनाना](/get-started/hi/platform/enterprise-features/role-based-access-control.md#creating-a-custom-role) स्वयं एडिटर के लिए। ### प्रत्येक साइट के लिए एक Auth Group बनाएँ Settings, "Team Members", "Auth Groups" पर जाएँ और "Create Auth Group" पर क्लिक करें। समूहों के नाम स्थानों के आधार पर रखें (जैसे: Plant A, Plant B), कभी भी भूमिकाओं के आधार पर नहीं। यदि किसी साइट के Dev और Prod फ़ोल्डरों में अलग-अलग लोग हैं, तो प्रति साइट और प्रति वातावरण एक समूह बनाएँ। सदस्यों को हाथ से जोड़ें, या SSO समूह नाम मैप करें ताकि सदस्यता आपके पहचान प्रदाता का अनुसरण करे (देखें [SSO के साथ इसे स्वचालित करना](#automating-it-with-sso)).
Auth Groups tab with two groups and their members

दो साइट समूहों और उनके मैन्युअल रूप से असाइन किए गए सदस्यों के साथ "Auth Groups" टैब।

### प्रत्येक साइट फ़ोल्डर को उसके समूह के साथ साझा करें फ़ोल्डर कार्ड पर, मेनू खोलें और "Set Permissions" चुनें। साइट के समूह को Read & Write दें और किसी भी विज़िटिंग समूह को Read-Only दें। जैसे-जैसे समूह जिम्मेदारी लेते हैं, व्यक्तिगत अनुदान हटाते जाएँ। तब स्थानांतरण या प्रस्थान केवल एक समूह संपादन बन जाता है। देखें [प्रोजेक्ट फ़ोल्डर अनुमतियाँ](https://docs.roboflow.com/datasets/manage/project-folders/project-folder-permissions) पहुँच स्तरों के लिए।
Share Folder dialog with a group granted Read & Write

एक साइट फ़ोल्डर पर "Share Folder": एक समूह को व्यक्तिगत अनुदान के साथ-साथ Read & Write दिया गया है। समूह ही लक्ष्य स्थिति हैं।

### सदस्यों को भूमिकाएँ असाइन करें Settings, "Team Members", "Members" पर जाएँ और प्रत्येक सदस्य की भूमिका सेट करें। भूमिका और समूह स्वतंत्र हैं, इसलिए किसी को दूसरी साइट पर जाने के लिए दूसरी भूमिका की आवश्यकता नहीं है। देखें [किसी टीम सदस्य की भूमिका बदलें](/get-started/hi/platform/workspaces/team-members/change-a-team-member-role.md). ## इस मॉडल में API कुंजियाँ फ़ोल्डर कुंजियाँ साइट के कार्य के लिए होती हैं। वर्कस्पेस-व्यापी कुंजियाँ केवल Admin के लिए हैं। किसी फ़ोल्डर कुंजी को वह कोई भी देख सकता है जो उस फ़ोल्डर तक पहुँच सकता है। Site Admin और Eng-Prod फ़ोल्डर कार्ड मेनू से कुंजियाँ प्रबंधित करते हैं और Settings में उनका कोई "API Keys" पृष्ठ नहीं होता। प्रत्येक फ़ोल्डर के लिए कई कुंजियाँ बनाएँ: प्रति उत्पादन लाइन, डिवाइस बेड़े या इंटीग्रेशन एक। उपयोग रिपोर्टिंग में हर कुंजी अपनी अलग पंक्ति होती है, इसलिए खर्च को फ़ोल्डर के भीतर आवंटित किया जा सकता है (देखें [बिलिंग फ़ोल्डर](/get-started/hi/platform/billing-and-plans/billing-folders.md#folder-api-keys)), और दो सक्रिय कुंजियाँ रोटेशन के दौरान ओवरलैप की अनुमति देती हैं। हर कुंजी निर्माण के 365 दिन बाद एक रोटेशन तिथि दिखाती है, और उसके बाद एक Overdue बैज दिखता है। एक नई कुंजी बनाकर, उपभोक्ताओं को उस पर स्थानांतरित करके, और पुरानी को रद्द करके रोटेट करें। जब कठोर कटओवर स्वीकार्य हो, तो "Roll" उसी स्थान पर रोटेट करता है। प्रबंधन API वही तिथि लौटाता है जैसे `rotationDueAt`.
Folder card menu with the API Keys entry

फ़ोल्डर कार्ड मेनू: "API Keys" "Folder Usage" और "Set Permissions" के साथ स्थित है।

API Keys dialog for one folder with three keys

एक फ़ोल्डर के लिए "API Keys": उपभोक्ताओं के नाम पर रखी गई कुंजियाँ, मेटाडेटा में एक स्वामी, प्रत्येक पर एक रोटेशन तिथि, और "Generate New Key"।

Key table with overdue and upcoming rotation badges

कुंजी तालिका पर रोटेशन बैज, और सूची को संकीर्ण करने के लिए "Show only keys due for rotation"।

Settings sidebar as an Eng-Prod member with no API Keys entry

Eng-Prod सदस्य के रूप में Settings: केवल "Usage", "Team Members" और "Trash"। कुंजियाँ फ़ोल्डरों पर रहती हैं।

## SSO के साथ इसे स्वचालित करना यदि आपका पहचान प्रदाता समूह क्लेम भेजता है, तो प्रत्येक भूमिका के लिए एक SSO समूह और प्रत्येक साइट Auth Group के लिए एक समूह मैप करें। देखें [सिंगल साइन-ऑन](/get-started/hi/platform/enterprise-features/single-sign-on-sso.md#custom-role-mapping-via-sso-groups) पहचान प्रदाता पक्ष के लिए। * भूमिकाएँ: भूमिका संपादक में, "SSO Auth Groups (auto-assign)" खोलें और पहचान प्रदाता समूह का नाम जोड़ें। उस समूह वाले उपयोगकर्ताओं को अगला लॉगिन या वर्कस्पेस लोड पर वह भूमिका मिल जाती है। * Auth Groups: समूह पर "Edit" क्लिक करें और "SSO Group Mappings" के तहत पहचान प्रदाता समूह का नाम जोड़ें। मेल खाने वाले सदस्यों को साइन-इन पर असाइन किया जाता है और सदस्य सूची में SSO बैज दिखता है। नया कर्मचारी डिफ़ॉल्ट भूमिका में रहता है जब तक IT उसे सही समूहों में नहीं जोड़ देता। उनकी अगली लॉगिन पर भूमिका और फ़ोल्डर पहुँच दिखाई देती है। मैपिंग को एक समय में एक भूमिका के लिए सक्षम करें। जो भी बिना मैप किया रह जाए, उसके लिए मैन्युअल असाइनमेंट काम करते रहते हैं।
Edit Role dialog with the SSO Auth Groups field

"SSO Auth Groups (auto-assign)" फ़ील्ड के साथ "Edit Role"।

Edit Auth Group dialog with the SSO Group Mappings field

"SSO Group Mappings" फ़ील्ड के साथ "Edit Auth Group"।