वर्कफ़्लो कॉन्फ़िगरेशन और सुरक्षा

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

वर्कफ़्लो चालू या बंद करना#

हर वर्कफ़्लो के बिल्डर में सबसे ऊपर और उसके अवलोकन पेज पर एक सक्षम स्विच होता है। जब यह बंद होता है, तो इसका ट्रिगर रुका रहता है — वेबहुक कॉल, आने वाले ईमेल, अनुसूचित समय, Status200 इवेंट और दूसरे वर्कफ़्लो के Execute Workflow चरण इसे शुरू नहीं करते। वर्कफ़्लो चलाएं और Run just this step करते हैं: वर्कफ़्लो बंद रहते हुए आपके द्वारा ख़ुद शुरू किया गया रन एक टेस्ट रन है। नए वर्कफ़्लो अक्षम अवस्था में शुरू होते हैं।

इस स्विच को अपने "तैयार है" वाले दरवाज़े की तरह इस्तेमाल करें:

किसी वर्कफ़्लो को बंद करने से उसका ट्रिगर नए रन शुरू करना बंद कर देता है। पहले से चल रहा रन पूरा होता है, लेकिन जो रन इसके ट्रिगर ने शुरू किया था और किसी Sleep ब्लॉक पर इंतज़ार कर रहा है, वह जागने पर रद्द हो जाता है। टेस्ट रन चलते रहते हैं। कई को एक साथ चालू या बंद करने के लिए उन्हें वर्कफ़्लो सूची में चुनें और बल्क कार्रवाइयाँ में सक्षम करें या अक्षम करें चुनें।

वर्कफ़्लो को संग्रहित करना#

ऐसे वर्कफ़्लो को संग्रहित करें जिसकी अब आपको ज़रूरत नहीं लेकिन जिसे आप रखना चाहते हैं। संग्रहीत वर्कफ़्लो:

• कभी नहीं चलता, किसी भी ट्रिगर से। हाथ से चलाए गए रन और Run just this step, वेबहुक कॉल, अनुसूचियाँ, Status200 इवेंट, आने वाले ईमेल, और दूसरे वर्कफ़्लो के Execute Workflow चरण, सब अस्वीकार होते हैं। संग्रहीत वर्कफ़्लो पर वेबहुक कॉल को ऐसी त्रुटि मिलती है जो बताती है कि वर्कफ़्लो संग्रहीत है।
• इंतज़ार कर रहे रन रोक देता है। किसी Sleep चरण में सो रहा रन जागने पर रद्द हो जाता है, और जो रन कतार में था लेकिन अभी शुरू नहीं हुआ था, वह "Workflow was archived before this run started, so it did not run." के साथ खत्म होता है।
• वर्कफ़्लो सूची से हट जाता है। इसे वर्कफ़्लो → उन्नत → संग्रहीत के अंतर्गत ढूँढें।
• सब कुछ रखता है। इसके चरण, वेरिएबल, मालिक, लेबल और रन इतिहास जैसे थे वैसे रहते हैं।

किसी एक वर्कफ़्लो को संग्रहित करने के लिए उसे खोलें, सेटिंग्स पर जाएं और संग्रहित करें पर क्लिक करें। कई को संग्रहित करने के लिए उन्हें वर्कफ़्लो सूची में चुनें और संग्रहित करें चुनें।

किसी वर्कफ़्लो को वापस लाने के लिए वर्कफ़्लो → उन्नत → संग्रहीत खोलें, उसे चुनें और अनसंग्रहीत करें चुनें, या उसे खोलें और उसके पेजों में सबसे ऊपर बैनर पर अनसंग्रहीत करें पर क्लिक करें।

संग्रहित करना और सक्षम स्विच अलग-अलग हैं। संग्रहित करना स्विच को नहीं छूता, इसलिए जो वर्कफ़्लो चालू था वह अनसंग्रहीत होते ही फिर चलता है, और जो बंद था वह बंद रहता है। संग्रहीत पेज अपने When Unarchived कॉलम में दिखाता है कि कौन-सा कौन-सा है।

निर्यात किया गया वर्कफ़्लो कभी अपनी संग्रहीत अवस्था साथ नहीं ले जाता, इसलिए आयात की गई प्रति कभी संग्रहीत नहीं होती।

मालिक और लेबल#

नियम कैसे मेल खाते हैं, इसके लिए देखें लेबल और स्वामी नियम।

Secrets#

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

सीक्रेट वेरिएबल इनके लिए इस्तेमाल करें:

• बाहरी सेवाओं की API कुंजियाँ।
• प्रमाणीकरण टोकन।
• वेबहुक साइनिंग कुंजियाँ।
• कुछ भी जो आप नहीं चाहेंगे कि सिर्फ़ पढ़ने की पहुँच वाला कोई व्यक्ति देखे।

किसी सीक्रेट को सीधे किसी ब्लॉक में न चिपकाएं — Authorization: Bearer eyJh... जैसे मान वर्कफ़्लो और लॉग में दिखने लगते हैं। इसके बजाय {{global.variables.MY_SECRET}} इस्तेमाल करें।

अगर सीक्रेट कोई ऐसा OAuth एक्सेस टोकन है जिसकी समय-सीमा खत्म होती है, तो वेरिएबल को OAuth 2.0 वेरिएबल बनाएं। तब Status200 आपके पहचान प्रदाता से टोकन लाता है और जब भी कोई वर्कफ़्लो समय-सीमा खत्म हुआ टोकन इस्तेमाल करने वाला हो, उसे रिफ्रेश करता है। OAuth 2.0 वेरिएबल हमेशा सीक्रेट होते हैं, और उनके क्रेडेंशियल डेटाबेस में एन्क्रिप्टेड होते हैं।

वर्कफ़्लो निर्यात और आयात करना#

आप किसी वर्कफ़्लो को JSON फ़ाइल के रूप में प्रोजेक्ट के बीच, या किसी स्व-होस्टेड इंस्टॉलेशन और Status200 Cloud के बीच ले जा सकते हैं।

फ़ाइल में वर्कफ़्लो का नाम, विवरण, सक्षम अवस्था और उसका ग्राफ़ होता है। इसमें जानबूझकर ये नहीं होते:

• वेबहुक की सीक्रेट कुंजी। वर्कफ़्लो बनने पर नई बनाई जाती है, इसलिए आयात किए गए वर्कफ़्लो का वेबहुक URL अलग होता है — इसे नए वर्कफ़्लो के वेबहुक ट्रिगर से कॉपी करें। मूल को कॉल करने वाली हर चीज़ को नए की ओर मोड़ना होगा।
• आने वाले ईमेल का पता। Incoming Email ट्रिगर वाले आयात किए गए वर्कफ़्लो को उसका अपना पता मिलता है — इसे नए वर्कफ़्लो के ट्रिगर से कॉपी करें। मूल को ईमेल भेजने वाली हर चीज़ को नया पता देना होगा।
• ग्लोबल वेरिएबल। {{global.variables.MY_SECRET}} पढ़ने वाला ब्लॉक वह संदर्भ रखता है, लेकिन मान फ़ाइल में नहीं होता। आयात किया गया वर्कफ़्लो चलाने से पहले गंतव्य प्रोजेक्ट में वेरिएबल बनाएं।
• मालिक और लेबल। आपके प्रोजेक्ट के अपने लेबल और स्वामी नियम आयात किए गए वर्कफ़्लो पर चलते हैं, ठीक वैसे ही जैसे आपने उसे हाथ से बनाया हो।

आयात किया गया वर्कफ़्लो हमेशा अक्षम बनाया जाता है, भले ही जहाँ से निर्यात हुआ वहाँ वह सक्षम था — उसका ग्राफ़ ऐसे मॉनिटर, ऑन-कॉल नीतियों या दूसरे वर्कफ़्लो की ओर इशारा कर सकता है जो गंतव्य प्रोजेक्ट में मौजूद नहीं हैं। इसकी समीक्षा करें, वर्कफ़्लो चलाएं से परखें, और फिर इसे चालू करें। वर्कफ़्लो की प्रतिलिपि बनाना भी इसी तरह काम करता है, ताकि आपके संपादित करने से पहले कोई प्रति मूल के साथ-साथ चलना शुरू न कर दे।

क्योंकि ग्राफ़ ज्यों-का-त्यों जाता है, किसी ब्लॉक में सीधे टाइप की गई हर चीज़ भी साथ जाती है। क्रेडेंशियल को सीक्रेट वेरिएबल में रखने की यही व्यावहारिक वजह है: हार्डकोड किए गए टोकन वाला वर्कफ़्लो निर्यात करना वह टोकन फ़ाइल पाने वाले को सौंपना है।

वेबहुक सुरक्षा#

वेबहुक ट्रिगर आपको एक अनोखा URL देते हैं। जो कोई भी URL जानता है, वह उसे कॉल कर सकता है। अनजाने या अनचाहे कॉल करने वालों से बचने के लिए:

• URL को पासवर्ड की तरह बरतें। इसे सार्वजनिक रूप से साझा न करें और किसी सार्वजनिक रिपॉज़िटरी में कमिट न करें। वेबहुक ट्रिगर URL की सीक्रेट कुंजी तब तक छिपाता है जब तक आप दिखाएं पर क्लिक नहीं करते, और URL कॉपी करें URL को बिना दिखाए कॉपी करता है।
• अगर URL लीक हो जाए, तो बिल्डर में वेबहुक ट्रिगर पर क्लिक करें और URL रीसेट करें पर क्लिक करें। वर्कफ़्लो को नया URL मिलता है और पुराना तुरंत काम करना बंद कर देता है।
• अगर ट्रिगर कहता है कि उसका URL वर्कफ़्लो के ID पर खत्म होता है, तो उसे रीसेट करें। वेबहुक URL को अपनी सीक्रेट कुंजी मिलने से पहले बने वर्कफ़्लो इसके बजाय वर्कफ़्लो का ID इस्तेमाल करते हैं, और जो कोई वर्कफ़्लो खोल सकता है वह उसे देख सकता है।
• संवेदनशील वर्कफ़्लो के लिए, कॉल करने वाले सिस्टम से एक साझा टोकन हेडर के रूप में भेजने को कहें (जैसे X-Webhook-Token) और कुछ भी महत्वपूर्ण करने से पहले उसे If / Else ब्लॉक से जाँचें। अपेक्षित टोकन को सीक्रेट वेरिएबल के रूप में सहेजें।
• बहुत संवेदनशील वर्कफ़्लो के लिए, सार्वजनिक वेबहुक के बजाय Status200 इवेंट ट्रिगर और हाथ से किए जाने वाले आयात चरण को प्राथमिकता दें।

सिर्फ़ वही लोग जो वर्कफ़्लो संपादित कर सकते हैं — Project Owner, Project Admin, Workflow Admin या Edit Workflow — उसका वेबहुक URL देख या रीसेट कर सकते हैं। URL वाला कोई भी व्यक्ति बिना साइन इन किए कहीं से भी वर्कफ़्लो शुरू कर सकता है, इसलिए बाकी सबको एक नोट दिखता है जो बताता है कि इसके बजाय किससे पूछें। इसमें वह Workflow Member भी शामिल है जो बिल्डर से वर्कफ़्लो हाथ से चलाता है।

आने वाले ईमेल की सुरक्षा#

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

• इसे प्रकाशित न करें या किसी सार्वजनिक रिपॉज़िटरी में न रखें। ट्रिगर कुंजी तब तक छिपाता है जब तक आप दिखाएं पर क्लिक नहीं करते, और पता कॉपी करें पते को बिना दिखाए कॉपी करता है।
• अगर पता लीक हो जाए, तो बिल्डर में Incoming Email ट्रिगर पर क्लिक करें और पता रीसेट करें पर क्लिक करें। वर्कफ़्लो को नया पता मिलता है, और उसके बाद पुराने पते पर आने वाला ईमेल अनदेखा होता है।
• कोई भी किसी ईमेल पर कोई भी भेजने वाला लिख सकता है, इसलिए From इस बात का सबूत नहीं है कि उसे किसने भेजा। किसी वर्कफ़्लो के कुछ महत्वपूर्ण करने से पहले, If / Else ब्लॉक से ऐसी चीज़ जाँचें जो सिर्फ़ असली भेजने वाला जानता हो — विषय या किसी हेडर में कोई टोकन। अपेक्षित टोकन को सीक्रेट वेरिएबल के रूप में सहेजें।
• रन को जो कुछ भी मिलता है — To, CC, हेडर और बॉडी — उन सबमें कुंजी छिपाई जाती है, क्योंकि रन का लॉग हर उस व्यक्ति को दिखता है जो वर्कफ़्लो के रन पढ़ सकता है।

सिर्फ़ वही लोग जो वर्कफ़्लो संपादित कर सकते हैं — Project Owner, Project Admin, Workflow Admin या Edit Workflow — उसका पता देख या रीसेट कर सकते हैं। बाकी सबको एक नोट दिखता है जो बताता है कि किससे पूछें।

बाहर जाने वाली नेटवर्क पहुँच#

API और दूसरे HTTP ब्लॉक अपने अनुरोध Status200 से करते हैं, और IRC ब्लॉक Status200 से IRC सर्वर के पोर्ट पर जुड़ता है। अगर आप स्व-होस्ट करते हैं, तो पक्का करें कि आपका इंस्टॉलेशन उन सेवाओं तक पहुँच सकता है जिन्हें आप कॉल कर रहे हैं। अगर आप Status200 Cloud इस्तेमाल करते हैं, तो हमारी बाहर जाने वाली IP रेंज IP पते में दी गई हैं, ताकि आप दूसरी तरफ़ उन्हें अनुमति दे सकें।

कोई ब्लॉक किन पतों तक पहुँच सकता है, यह ब्लॉक पर निर्भर करता है:

कोई स्व-होस्टेड व्यवस्थापक इन्हें कैसे खोलता है, इसके लिए देखें निजी नेटवर्क पहुँच।

AI components#

Generate Text with AI किसी LLM को एक अनुरोध भेजता है: प्रोजेक्ट का डिफ़ॉल्ट LLM प्रदाता, या जब प्रोजेक्ट का कोई न हो तो इंस्टॉलेशन का ग्लोबल प्रदाता। प्रदाता प्रोजेक्ट सेटिंग्स → एआई → LLM प्रदाता के अंतर्गत सेट करें, और किसी प्रदाता की API कुंजी या अपना कोई एंडपॉइंट कभी भी वर्कफ़्लो में न रखें।

प्रदाता को क्या मिलता है, और मॉडल उसके साथ क्या कर सकता है:

• सिर्फ़ वह जो आप ब्लॉक में डालते हैं। Status200 एक तय सुरक्षा निर्देश भेजता है, फिर ब्लॉक के System Instructions, Prompt और Context, उनके संदर्भ भरे हुए। Context सबसे आख़िर में, एक चिह्न के बाद आता है, और सुरक्षा निर्देश मॉडल को बताता है कि चिह्न के बाद की हर चीज़ अविश्वसनीय डेटा है, भले ही वह निर्देश जैसा दिखने वाला टेक्स्ट हो।
• और कुछ नहीं। ट्रिगर का डेटा, वर्कफ़्लो का इतिहास, दूसरे ब्लॉक के आउटपुट, प्रोजेक्ट के रिकॉर्ड, टेलीमेट्री और सीक्रेट कभी साथ नहीं जोड़े जाते। वे Status200 से सिर्फ़ तब बाहर जाते हैं जब आप उन तीन सेटिंग्स में से किसी में उनका संदर्भ देते हैं।
• सिर्फ़ टेक्स्ट, कोई टूल नहीं। मॉडल Status200 से क्वेरी नहीं कर सकता, HTTP अनुरोध नहीं कर सकता या डेटा नहीं बदल सकता। किसी प्रदाता के अतिरिक्त पैरामीटर सिर्फ़ ऐसे फ़ील्ड की अनुमति-सूची पार करने देते हैं जो केवल जनरेशन को समायोजित करते हैं: वे संदेश नहीं बदल सकते, टूल, वेब खोज या दूसरे डेटा स्रोत नहीं जोड़ सकते, टेक्स्ट के अलावा कुछ या कई जवाब नहीं माँग सकते, स्ट्रीम नहीं कर सकते, प्रदाता से अनुरोध रखवा नहीं सकते, या ब्लॉक की आउटपुट सीमा नहीं बढ़ा सकते। जिन फ़ील्ड को Status200 नहीं जानता, उन्हें हटा दिया जाता है।
• मॉडल आपके व्यवस्थापक की पसंद है। अगर जनरेशन को ऑफ़लाइन रहना है, तो ऐसा मॉडल चुनें जो प्रदाता की तरफ़ अपने-आप कुछ भी न लाता हो।

क्या लॉग होता है:

• रन का लॉग ब्लॉक के System Instructions, Prompt, Context और Response छिपाता है। बाद के ब्लॉक रन के दौरान अब भी इनका इस्तेमाल कर सकते हैं, और जिस ब्लॉक में आप इनमें से कोई डालते हैं वह उसे अपने नियमों से लॉग करता है, इसलिए किसी को डालना उसे दिखाने का फ़ैसला है।
• प्रदाता, मॉडल, टोकन की गिनती, LLM Log ID और एक सुरक्षित त्रुटि संदेश संचालन और बिलिंग के लिए दिखते रहते हैं। किसी प्रदाता की कच्ची त्रुटि हर लॉग से बाहर रखी जाती है, क्योंकि प्रदाता उसमें अनुरोध दोहरा सकता है।
• हर कॉल प्रोजेक्ट सेटिंग्स → एआई → AI लॉग के अंतर्गत अपने प्रदाता, मॉडल, स्थिति, टोकन, लागत और बिलिंग के साथ सूचीबद्ध होती है, प्रॉम्प्ट, जवाब या कच्ची त्रुटि के बिना।

इसे क्या चाहिए, और इसकी लागत क्या है:

• प्रोजेक्ट सेटिंग्स → एआई → AI Features के अंतर्गत AI सक्षम करें चालू होना चाहिए। Status200 Cloud पर प्रोजेक्ट को Growth प्लान या उससे ऊपर और भुगतान की गई सब्सक्रिप्शन भी चाहिए। बिलिंग के बिना स्व-होस्टेड इंस्टॉलेशन पर कोई प्लान शर्त नहीं है।
• किसी लागत वाले ग्लोबल प्रदाता के ज़रिए कॉल प्रोजेक्ट के AI क्रेडिट इस्तेमाल करती हैं।
• जब कोई प्रोजेक्ट मालिक इन्हें सेट करता है, तो हर कॉल प्रोजेक्ट की अपनी दैनिक AI सीमाओं में गिनी जाती है। सीमा पूरी होने पर ब्लॉक UTC आधी रात तक मॉडल से संपर्क किए बिना Error लेता है।

सत्यापन, कॉन्फ़िगरेशन, पहुँच, सीमा, क्रेडिट, समवर्तीता, प्रदाता और टाइमआउट की विफलताएँ सभी Error रास्ता लेती हैं, कारण Error में होता है। वर्कफ़्लो के लाइव होने से पहले वह रास्ता जोड़ें।

अनुमतियाँ#

वर्कफ़्लो आपके प्रोजेक्ट के भूमिका-आधारित पहुँच नियंत्रण का पालन करते हैं। वर्कफ़्लो की तीन भूमिकाएँ:

• Workflow Admin — वर्कफ़्लो बनाता है: उन्हें बनाता, बदलता, चलाता और हटाता है, और उनके इस्तेमाल किए वेरिएबल प्रबंधित करता है।
• Workflow Member — उनका इस्तेमाल करता है: वर्कफ़्लो और उनके रन खोलता है, और वर्कफ़्लो चलाएं से किसी वर्कफ़्लो को हाथ से चलाता है। सदस्य कोई वर्कफ़्लो बना, बदल या हटा नहीं सकता, और न उसका कोई चरण अकेले चला सकता है।
• Workflow Viewer — वर्कफ़्लो और उनके रन पढ़ता है।

Project Owner और Project Admin वह सब कर सकते हैं जो Workflow Admin कर सकता है। Project Member वर्कफ़्लो बना और हटा सकता है, लेकिन उन्हें बदल या चला नहीं सकता।

अकेली अनुमतियाँ, ऐसी टीम या API कुंजी के लिए जिसे ठीक एक चीज़ चाहिए:

• Create / Read / Edit / Delete Workflow — खुद वर्कफ़्लो पर बुनियादी अनुमतियाँ। किसी वर्कफ़्लो को बदलने के लिए, जिसमें उसे चालू या बंद करना और संग्रहित करना शामिल है, Edit Workflow चाहिए; Delete Workflow सिर्फ़ हटाता है।
• Edit Workflow — किसी एक चरण को Run just this step से अकेले चलाने, और किसी वर्कफ़्लो का वेबहुक URL और आने वाले ईमेल का पता देखने या रीसेट करने के लिए भी यही चाहिए। पूरा वर्कफ़्लो हाथ से चलाने के लिए Edit Workflow, Workflow Admin या Workflow Member चाहिए।
• Read Workflow Log — रन देखने के लिए ज़रूरी।
• Create / Read / Edit / Delete Workflow Variables — ग्लोबल और वर्कफ़्लो वेरिएबल प्रबंधित करना।

हाथ से चलाया गया रन सिर्फ़ उन्हीं वर्कफ़्लो तक पहुँचता है जिन्हें आप खोल सकते हैं: कुछ लेबल तक, या आपकी टीम के स्वामित्व वाले वर्कफ़्लो तक सीमित भूमिका सिर्फ़ उन्हीं को चलाती है। जो किसी वर्कफ़्लो को नहीं चला सकता, उसे वर्कफ़्लो चलाएं धुंधला दिखता है, कारण उसके टूलटिप में होता है।

स्वचालन बनाने वालों को Workflow Admin दें, और जो सिर्फ़ उसे शुरू करते हैं उन्हें Workflow Member। वेरिएबल संपादित करने की पहुँच उन लोगों के लिए रखें जो आपके प्रोजेक्ट के सीक्रेट प्रबंधित करते हैं। भूमिकाएँ कैसे दी जाती हैं, इसके लिए देखें उपयोगकर्ता, टीमें और अनुमतियाँ।

वर्कफ़्लो के चरण क्या कर सकते हैं#

वे चरण जो Status200 रिकॉर्ड पढ़ते और बदलते हैं — Find, Create, Update और Delete घटक, और On Create, On Update, On Create or Update और On Delete ट्रिगर — वर्कफ़्लो के प्रोजेक्ट के Project Admin के रूप में काम करते हैं। वर्कफ़्लो किसी ने भी बनाया हो, चरण पर वही जाँचें लागू होती हैं जो डैशबोर्ड और API में किसी Project Admin पर होती हैं:

• सिर्फ़ वर्कफ़्लो का अपना प्रोजेक्ट। कोई चरण उसी प्रोजेक्ट के रिकॉर्ड पढ़ता और लिखता है जिसका वर्कफ़्लो है, किसी और के नहीं, और कोई Update कभी किसी रिकॉर्ड को दूसरे प्रोजेक्ट में नहीं ले जाता।
• सिर्फ़ वह जो Project Admin कर सकता है। कोई चरण वह नहीं कर सकता जो सिर्फ़ Project Owner, बिलिंग या प्रोजेक्ट हटाने की अनुमतियाँ करने देती हैं, और यह नहीं पढ़ सकता कि किसी प्रोब या AI एजेंट को किसने बनाया, जो सिर्फ़ प्रोजेक्ट मालिक देखते हैं।
• यह नहीं कि किसकी पहुँच है। कोई चरण टीमें, टीम सदस्य, टीम अनुमतियाँ, कस्टम भूमिकाएं या API कुंजी अनुमतियाँ नहीं बनाता, नहीं बदलता और नहीं हटाता, भले ही Project Admin ऐसा कर सकता है। वर्कफ़्लो जो बनाता है वही तय करता है कि उसके चरण क्या करें, और वह कोई Project Member भी हो सकता है, इसलिए ऐसा कर सकने वाला चरण उसे वह पहुँच दे देता जो उसे नहीं दी गई, जैसे Project Admin। चरण अस्वीकार किया जाता है, और रन का लॉग बताता है कि प्रोजेक्ट की टीमें और API कुंजियाँ संभालने वाले किसी व्यक्ति को यह बदलाव करना होगा। इन रिकॉर्ड पर ट्रिगर और Find चरण पहले की तरह काम करते हैं।
• क्रेडेंशियल रखने वाली सेटिंग्स पढ़ना नहीं। Project Admin SMTP सर्वर, कॉल और SMS प्रदाता, SNMP क्रेडेंशियल, वीडियो कॉल कनेक्शन और API कुंजियाँ पढ़ सकता है, लेकिन यह किसी चरण को कभी उधार नहीं दिया जाता, चाहे वर्कफ़्लो किसी ने भी बनाया या सहेजा हो। कोई चरण इनमें से किसी सेटिंग का नाम नहीं ले सकता, जैसे वह SMTP सर्वर जिससे कोई स्टेटस पेज ईमेल भेजता है या वह API कुंजी जिसे कोई अनुमति दी जाती है। चरण अस्वीकार होता है, और उसका रन लॉग बताता है कि बदलाव कोई ऐसा व्यक्ति करे जो उन्हें पढ़ सकता है (उस प्रकार की सेटिंग पढ़ने की अनुमति, या कोई Project Owner या Project Admin)। जो चरण किसी रिकॉर्ड की पहले से बताई सेटिंग बनाए रखता है, या उसे खाली करता है, वह अस्वीकार नहीं होता।
• सिर्फ़ वह जो आपके प्लान में शामिल है। Status200 Cloud पर, ऐसा कुछ बनाने या बदलने वाला चरण जो आपके प्लान में शामिल नहीं, ज़रूरी प्लान बताते हुए अस्वीकार होता है, ठीक वैसे ही जैसे डैशबोर्ड। बिलिंग के बिना स्व-होस्टेड इंस्टॉलेशन पर कोई प्लान सीमा नहीं है।
• कुछ भी नहीं जो Status200 अपने लिए रखता है। ये सबके लिए अस्वीकार होते हैं, वर्कफ़्लो समेत:
  • किसी फ़ीड प्रविष्टि को संपादित करना या हटाना (घटना, अलर्ट, एपिसोड, मॉनिटर, ऑन-कॉल नीति और अनुसूचित रखरखाव की फ़ीड);
  • कोई सूचना लॉग लिखना (SMS, कॉल, ईमेल, WhatsApp, Telegram, पुश, वेबहुक और वर्कस्पेस संदेश लॉग);
  • वे मान जो Status200 घटनाएँ होते-होते सेट करता है: किसी कस्टम डोमेन का CNAME सत्यापित है या नहीं, किसी टीम के सुरक्षा स्विच (Is Team Editable, Is Team Deleteable, Is Permissions Editable, Should Have At Least One Member), कौन-सी घटना भूमिका प्राथमिक है और क्या उसे हटाया जा सकता है, किसी मालिक या सदस्य को सूचित किया गया है या नहीं, रिमाइंडर के समय और गिनती, किसी शेड्यूल पर अभी और आगे कौन ऑन-कॉल है, किसी ऑन-कॉल रन की प्रगति, किसी SLO की मौजूदा बर्न रेट और एरर बजट, किसी घटना या रखरखाव इवेंट से रोका गया मॉनिटर, किसी स्थिति पृष्ठ के निजी उपयोगकर्ता का पासवर्ड रीसेट टोकन और आख़िरी साइन-इन, कोई सेवा अपने बारे में जो तथ्य बताती है (संस्करण, रनटाइम, क्लाउड), और किसी डिटेक्शन नियम या थ्रेट फ़ीड का आख़िरी रन;
  • Create One Incident को createdIncidentTemplateId भेजकर किसी टेम्पलेट से घटना घोषित करना — इसके बजाय चरण की Incident Template सेटिंग के अंतर्गत टेम्पलेट चुनें: तब चरण उससे घटना घोषित करता है, Project Admin के रूप में, और टेम्पलेट दर्ज करता है;
  • कोई रिकॉर्ड बनने के बाद यह बदलना कि वह किस रिकॉर्ड का है, जैसे वह मॉनिटर जिसके लिए कोई मालिक पंक्ति है या वह घटना जिस पर कोई नोट है।
• किसी व्यक्ति के रूप में नहीं। वर्कफ़्लो का बनाया रिकॉर्ड किसी निर्माता का नाम नहीं लेता, और ऑडिट लॉग बदलाव करने वाले के रूप में वर्कफ़्लो का नाम लेता है, उस समय के उसके नाम से।

जब कोई जाँच किसी चरण को अस्वीकार करती है, तो चरण अस्वीकार किया गया बदलाव किए बिना अपना Error आउटपुट लेता है, और रन का लॉग चरण और कारण सीधे शब्दों में बताता है, उदाहरण के लिए "Find One Probe" was refused. Workflow steps can do only what a Project Admin of this project can do: …। इसे वर्कफ़्लो के रन के अंतर्गत पढ़ें। Create Many चरण अपने रिकॉर्ड एक-एक करके बनाता है और पहले अस्वीकार हुए पर रुक जाता है: उससे पहले बनाए गए रिकॉर्ड रखे जाते हैं।

दूसरे सिस्टम से बात करने वाले चरण — API, Email, Slack, Microsoft Teams, Discord, Telegram, IRC, Mattermost, Custom Code और Generate Text with AI — Status200 रिकॉर्ड न पढ़ते हैं न बदलते हैं, इसलिए इनमें से कुछ भी उन्हें नहीं बदलता।

प्लान की सीमाएँ#

Status200 Cloud पर वर्कफ़्लो के लिए Growth प्लान या उससे ऊपर चाहिए, और हर प्लान किन्हीं भी 30 दिनों में तय संख्या में रन की अनुमति देता है:

अवधि आगे खिसकती रहती है: प्रोजेक्ट का दर्ज किया हर रन, हाथ से या किसी ट्रिगर से, 30 दिनों तक गिना जाता है। Growth और Scale प्लान पर वर्कफ़्लो पेज एक वर्कफ़्लो रन कार्ड दिखाता है कि प्रोजेक्ट ने कितने इस्तेमाल किए हैं। सीमा पूरी होने पर नए रन Execution Exceeded Current Plan स्थिति के साथ दर्ज होते हैं और चलाए नहीं जाते, और सब्सक्रिप्शन का भुगतान न होने के दौरान भी यही होता है। बिलिंग के बिना स्व-होस्टेड इंस्टॉलेशन पर कोई सीमा नहीं है।

एक रन कितना समय ले सकता है#

रनर हर ब्लॉक से पहले और बाद में समय-सीमा जाँचता है, और नियंत्रण लौटते ही समय से ज़्यादा चले रन को Timeout चिह्नित करता है। यह किसी ब्लॉक को बीच में नहीं रोक सकता, इसलिए नेटवर्क का इंतज़ार करने वाले ब्लॉक की अपनी समय सीमाएँ हैं: Generate Text with AI अनुरोध अधिकतम 60 सेकंड बाद हार मान लेता है, और OAuth 2.0 टोकन अनुरोध 20 के बाद। किसी Sleep ब्लॉक पर इंतज़ार रन के समय में नहीं गिना जाता: रन एक तरफ़ रख दिया जाता है और जागने पर उसे नए 2 मिनट मिलते हैं।

दूसरे वर्कफ़्लो बुलाने की सीमा#

Execute Workflow घटक एक वर्कफ़्लो को दूसरा शुरू करने देता है। ऐसे लूप रोकने के लिए जहाँ वर्कफ़्लो A, B को शुरू करता है, जो फिर A को शुरू करता है, एक-दूसरे को शुरू करने वाले वर्कफ़्लो की श्रृंखला तब अस्वीकार होती है जब वह किसी ऐसे वर्कफ़्लो पर लौटे जो पहले से उसमें है, या 10 वर्कफ़्लो से ज़्यादा गहरी जाए। तब Execute Workflow ब्लॉक अपना Error आउटपुट लेता है, और त्रुटि श्रृंखला दिखाती है।

अगर आपको सचमुच लंबी श्रृंखला चाहिए (जैसे ऐसा काम जो हर रन में एक आइटम प्रोसेस करता है), तो आम तौर पर Run Custom JavaScript से एक ही वर्कफ़्लो के अंदर लूप करना ज़्यादा आसान होता है।

जब वर्कफ़्लो सही औज़ार नहीं है#

कुछ मामले जहाँ आपको कुछ और इस्तेमाल करना चाहिए:

• भारी गणना या बड़े डेटासेट — वर्कफ़्लो हल्के जोड़ने वाले काम के लिए बने हैं, भारी गणना के लिए नहीं। भारी काम अपने इंफ़्रास्ट्रक्चर में चलाएं और किसी वर्कफ़्लो से उसे शुरू करवाएं।
• लंबे समय तक चलने वाली सक्रिय गणना — एक रन को डिफ़ॉल्ट रूप से 2 मिनट मिलते हैं। "A करो, दो घंटे रुको, B करो" जैसी निष्क्रिय देरी के लिए Sleep घटक इस्तेमाल करें; यह रन को एक तरफ़ रखता है और बाद में बिना कोई वर्कर घेरे फिर शुरू करता है।
• लोगों की भागीदारी वाली चरण-दर-चरण घटना प्रतिक्रिया — Runbook इसी के लिए हैं। वर्कफ़्लो बिना निगरानी वाले स्वचालन के लिए हैं।

अगले कदम#