अपवाद-पथ डिजाइन: स्वीकृतियों से पहले अस्वीकृतियों की योजना बनाएं

क्यों सिर्फ़ "हैप्पी पाथ" काफी नहीं है

ज़्यादातर टीमें वर्कफ़्लो का साफ़ रूप से शुरू करती हैं। एक अनुरोध आता है, कोई उसे रिव्यू करता है, और उसे स्वीकृति मिल जाती है। यह कुशल लगता है, पर यह असली काम को छुपा देता है।

हैप्पी पाथ आम तौर पर सबसे छोटा मार्ग होता है। फ़ॉर्म पूरा है, संलग्नक मौजूद हैं, और समीक्षक को ठीक-ठीक पता है क्या करना है। असल संचालन में, वही भाग शायद देर का कारण नहीं होता।

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

यदि इन स्थितियों की पहले से योजना नहीं बनाई गई, तो लोग इंस्टिन्क्ट पर फैसले लेते हैं। एक समीक्षक ईमेल भेज देता है। दूसरे टूल में कमेंट छोड़ते हैं। तीसरा बिना स्पष्टीकरण के अनुरोध अस्वीकार कर देता है। अनुरोधकर्ता फँस जाता है: क्या वे समस्या ठीक करें, फिर से शुरू करें, या किसी से मदद मांगें?

यह उलझन महँगी होती है। इससे अनुरोध भेजने वाला, उसे रिव्यू करने वाला, और जो भी समझाने के लिए बुलाया जाता है—सभी की गति धीमी पड़ जाती है। एक वर्कफ़्लो जो व्हाइटबोर्ड पर सरल लगती है, फ़ॉलो-अप चैट, डुप्लिकेट सबमिशन और मैन्युअल हैंडऑफ़ में बदल जाती है।

एक साधारण अनुमोदन फ्लो स्केच करना आसान है:

• अनुरोध सबमिट करें
• अनुरोध रिव्यू करें
• अनुरोध स्वीकृत करें

असली संस्करण कठिन है। यदि कोई दस्तावेज़ ग़ायब है क्या होगा? यदि अनुरोध का केवल एक हिस्सा स्वीकृत हो तो? यदि समीक्षक उसे अस्वीकार कर देता है पर उपयोगकर्ता उसे ठीक कर सकता है? ये असामान्य मामले नहीं हैं। कई टीमों के लिए ये सामान्य मामले हैं।

इसीलिए स्क्रीन बनाने और स्टेटस नाम रखने से पहले अपवाद-पथ डिज़ाइन पर ध्यान दिया जाना चाहिए। अपवाद-पथ परिभाषित करता है कि योजना में असली दुनिया जब बाधा बनकर आए तो क्या होता है—और वास्तविकता अक्सर ऐसा ही करती है।

यदि आप एक आंतरिक अनुमोदन ऐप बना रहे हैं, यहां तक कि किसी नो-कोड प्लेटफ़ॉर्म में जैसे AppMaster, तो अस्वीकृत और अपूर्ण मामलों को स्वीकृत मामले जितनी ही प्राथमिकता दें। वे उन संदेशों, अगले क्रियाओं और इस बात को आकार देते हैं कि वर्कफ़्लो लोगों को रिकवर करने में मदद करता है या उन्हें फँसा छोड़ देता है।

हैप्पी पाथ इरादा दिखाती है। अपवाद पाथ दिखाती हैं कि क्या प्रक्रिया असली उपयोग सहन कर सकती है।

अपवाद-पथ कैसा दिखता है

अपवाद-पथ वह है जो तब होता है जब अनुरोध सामान्य तरीके से आगे नहीं बढ़ सकता। यह कोई दुर्लभ एज़ केस नहीं है। यह उस हिस्से को संभालता है जो असली दुनिया की गड़बड़ी है: अनुरोध अस्वीकार किया गया, फ़ॉर्म अपूर्ण है, एक हिस्सा स्वीकृत हुआ पर दूसरा नहीं, या काम अटक गया है।

एक स्पष्ट अपवाद-पथ सादे भाषा का उपयोग करता है। "Failed" जैसे अस्पष्ट स्टेटस की बजाय स्पष्ट बताएं कि क्या हुआ: "बजट सीमा से ऊपर होने के कारण अस्वीकृत" या "ID दस्तावेज़ की प्रतीक्षा।" लोगों को जानना चाहिए कि क्या गलत है, किसे कार्रवाई करनी है, और आगे क्या होता है।

ज़्यादातर वर्कफ़्लो कुछ सामान्य तरीकों से टूटते हैं:

• अनुरोध किसी स्पष्ट कारण से अस्वीकार किया गया है
• कोई आवश्यक दस्तावेज़ या फ़ील्ड ग़ायब है
• अनुरोध का केवल एक हिस्सा स्वीकृत हुआ है
• अनुरोध का कोई मालिक नहीं है या कोई परिभाषित अगला कदम नहीं है

ग़ायब जानकारी सबसे आम समस्याओं में से एक है। कल्पना करें एक सप्लायर ऑनबोर्डिंग फ़ॉर्म जिसे कर दस्तावेज़ और बैंक अकाउंट नंबर चाहिए। अगर इनमें से कोई भी ग़ायब है, तो सिस्टम को बस रुक जाना नहीं चाहिए। इसे अनुरोध को "अपूर्ण" के रूप में चिह्नित करना चाहिए, ठीक-ठीक दिखाना चाहिए क्या ग़ायब है, और उसे सही व्यक्ति के पास वापस भेजना चाहिए।

आंशिक स्वीकृतियाँ उतनी ही महत्वपूर्ण हैं। एक ट्रैवल अनुरोध सोचें जिसमें उड़ान, होटल और भोजन बजट शामिल है। मैनेजर उड़ान और होटल को स्वीकृत कर देता है पर भोजन का बजट काट देता है। अब प्रक्रिया को नियमों की ज़रूरत है। क्या कर्मचारी परिवर्तन स्वीकार कर लेते हैं, अनुरोध अपडेट करें, या यात्रा रद्द करें?

स्टॉल भी मायने रखते हैं। कोई अनुरोध बिना स्पर्श के पड़ा रह सकता है क्योंकि असाइन किया गया समीक्षक कंपनी छोड़ चुका है, टीम ने बैकअप अप्रूवर सेट नहीं किया, या प्रक्रिया ऐसे स्टेप पर पहुंच गई जहाँ अगला कोई मालिक परिभाषित नहीं है। तकनीकी रूप से कुछ टूटा नहीं है, पर अनुरोध फिर भी आगे नहीं बढ़ सकता।

यदि आप इन पथों को पहले नहीं डिजाइन करते, तो लोग उन्हें ईमेल, चैट, या स्प्रेडशीट नोट्स से हैंडल करते हैं। थोड़ी ही देर में कोई नहीं जानता कौन सा संस्करण अंतिम है।

एक साधारण अनुमोदन उदाहरण

एक सेल्स मैनेजर का ट्रैवल अनुरोध लें जो दो दिनों के सम्मेलन में भाग लेना चाहता है। कागज़ पर फ्लो आसान दिखता है: कर्मचारी यात्रा की तारीखें, अनुमानित लागत और यात्रा का कारण भरता है। मैनेजर इसे स्वीकृत करता है, फाइनेंस बजट की पुष्टि करता है, और यात्रा बुकिंग के लिए आगे बढ़ती है।

वह फ्लो साफ़ है, पर अधूरा भी है।

अब उसी अनुरोध को तोड़ दें। कर्मचारी उड़ान का अनुमान और कॉन्फ़्रेंस टिकट अपलोड करता है पर होटल कोट भूल जाता है। यदि सिस्टम केवल "submitted" और "approved" जानता है, तो लोग जल्दी फंस जाते हैं। फाइनेंस एक अपूर्ण अनुरोध देख सकता है, मैनेजर सोच सकता है कि यह तैयार है, और कर्मचारी को पता नहीं होगा क्या ग़ायब है।

एक बेहतर फ्लो उस अनुरोध को अपना अलग स्टेट देता है, जैसे "Waiting for document" या "Needs update." कर्मचारी को स्पष्ट संदेश दिखना चाहिए: "होटल कोट जोड़ें इससे पहले कि यह अनुरोध फाइनेंस को जाए।" मैनेजर को पूरे ट्रिप को अस्वीकार नहीं करना चाहिए सिर्फ़ एक फाइल माँगने के लिए।

अब एक दूसरी समस्या जोड़ें। मैनेजर सहमत है कि कर्मचारी यात्रा करे, पर पूरी राशि नहीं। वे उड़ान और एक होटल रात स्वीकृत करते हैं, पर वर्कशॉप फीस और दूसरी होटल रात अस्वीकार कर देते हैं।

यहाँ कई टीमों को पता चलता है कि उनके पास असली आंशिक स्वीकृति प्रक्रिया नहीं है।

यदि वर्कफ़्लो केवल पूरे अनुरोध को स्वीकृत कर सकता है, लोग वर्कअराउंड इस्तेमाल करते हैं। वे पूरे अनुरोध को अस्वीकार कर कर्मचारी से फिर से सबमिट करने को कह सकते हैं। या फाइनेंस गलती से पूरी राशि स्वीकृत कर सकता है क्योंकि सिस्टम केवल एक हाँ-या-नौ निर्णय स्टोर करता है।

एक स्पष्ट मॉडल प्रत्येक लागत आइटम को ट्रैक करता है, या कम से कम स्वीकृत कुल को। एक अनुरोध दिखा सकता है:

• Flight: approved
• Hotel: approved for 1 night
• Workshop add-on: not approved
• Total requested: $1,450
• Total approved: $980

यह एक उदाहरण दिखाता है कि क्यों अनुमोदन वर्कफ़्लो त्रुटियाँ अक्सर नियमों के अभाव से आती हैं, न कि लापरवाही से। यदि आप उन नियमों को स्क्रीन डिज़ाइन से पहले परिभाषित करते हैं, तो बाकी वर्कफ़्लो पर भरोसा करना बहुत आसान हो जाता है।

स्क्रीन से पहले अपवाद डिज़ाइन करें

एक वर्कफ़्लो सुधारने का अच्छा तरीका यह मानना है कि अनुरोध साफ़ तरीके से नहीं जाएगा। यह एक छोटा सा शिफ्ट डिज़ाइन की गुणवत्ता को तेज़ी से बदल देता है।

गंदे मामलों से शुरू करें: फ़ॉर्म अपूर्ण है, नीति अस्पष्ट है, अप्रूवर अनुपस्थित है, या केवल अनुरोध का एक हिस्सा आगे बढ़ना चाहिए। अधिकांश टीमें इन्हें तीन मुख्य पैटर्न में समूहित कर सकती हैं:

• rejection
• missing information
• partial approval

यह काम को संभालने योग्य बनाए रखता है। हर एज़ केस के लिए नया उत्तर बनाने की बजाय आप कुछ पैटर्न परिभाषित करते हैं और उन्हें हर अनुरोध प्रकार पर लागू करते हैं।

इस क्रम में काम करें।

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

अगला, हर केस में क्या होता है तय करें। हर अपवाद के लिए चार आसान सवालों के जवाब दें:

• किसे सूचित किया जाता है
• अनुरोध कौन सा स्टेटस दिखाता है
• उपयोगकर्ता को अगला क्या करना है
• अनुरोध फिर कब आगे बढ़ता है

उदाहरण के लिए, कल्पना करें कि एक कर्मचारी $600 के ट्रैवल खर्च का दावा सबमिट करता है। होटल रसीद ग़ायब है, और एक भोजन नीति से ऊपर है। यदि आप सिर्फ़ हैप्पी पाथ डिज़ाइन करते हैं, तो अनुरोध या तो अटक जाएगा या एक बड़े ब्लॉक के रूप में अस्वीकार कर दिया जाएगा। यदि आप पहले अपवाद डिज़ाइन करते हैं, तो सिस्टम दावा को_missing receipt_ के लिए रोक सकता है, कर्मचारी को स्पष्ट संदेश भेज सकता है, और अभी भी अनुमति दिए गए आइटम को सशर्त रूप से स्वीकृत के रूप में मार्क कर सकता है।

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

यदि आप AppMaster में प्रोसेस बना रहे हैं, तो यह वही बिंदु है जहाँ उन शाखाओं को बिज़नेस लॉजिक में मैप करना चाहिए—UI पॉलिश करने से पहले। जब reject, return-for-edits, और approve-with-conditions अलग पाथ के रूप में ट्रीट किए जाते हैं न कि एक अस्पष्ट स्टेट के पीछे छुपे हुए, तो वर्कफ़्लो पर भरोसा करना आसान होता है।

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

इंटरफ़ेस से पहले नियम तय करें

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

एक बेहतर क्रम सरल है: स्टेट्स, हैंडऑफ़, डेडलाइन्स, और आगे बढ़ने के लिए ज़रूरी प्रमाण पहले परिभाषित करें। फिर उन पर स्क्रीन बनाएं।

अपवाद-पथ डिज़ाइन तब बहुत आसान हो जाता है जब नियमों का सेट छोटा और स्पष्ट हो। यदि एक अनुरोध को approve, reject, send back for fixes, या partly approve किया जा सकता है, तो उन स्टेट्स के स्पष्ट नाम होने चाहिए जिनका केवल एक ही अर्थ हो। "returned," "reopened," और "needs changes" जैसे लगभग-डुप्लीकेट्स से बचें जब तक कि वे सचमुच अलग व्यवहार न करें।

एक खरीद अनुरोध लें। एक मैनेजर उसे खोलता है और नोटिस करता है कि कोट ग़ायब है। यदि टीम ने यह तय नहीं किया कि अगला कदम क्या होगा, लोग सहज रूप से काम करेंगे। एक मैनेजर इसे अस्वीकार कर देगा। दूसरे उसे पेंडिंग छोड़ देंगे। तीसरा चैट भेजेगा और सिस्टम में कुछ नहीं बदलेगा। जल्दी ही कोई भी स्टेटस पर भरोसा नहीं करेगा।

पहले नियम लिखिए। जब कोट ग़ायब हो, अनुरोध "Needs documents" में चला जाए। अनुरोधकर्ता अगला कदम उठाने वाला हो। अनुरोध वहाँ पांच व्यावसायिक दिनों के लिए रहे। अगर कुछ नहीं आता, तो वह "Expired" में बदल जाए और नई सबमिशन आवश्यक हो।

वह एक नियम प्रोडक्ट को मॉकअप से बेहतर आकार देता है। अब आप जानते हैं उपयोगकर्ता को क्या दिखाना है, क्या रिमाइंडर भेजना है, और क्या इतिहास रखना है।

एक व्यवहारिक नियम सेट को चार सवालों के जवाब देने चाहिए:

• कुछ ऐसे कॉमन स्टेट्स क्या हैं जिन्हें हर दिन हर कोई उपयोग करेगा?
• हर स्टेट में अगला कौन कार्य करता है?
• आइटम वहाँ कितनी देर रह सकता है इससे पहले कि वह एस्केलेट, एक्सपायर, या क्लोज हो जाए?
• आगे बढ़ने से पहले कौन-से फ़ील्ड, फ़ाइलें, या चेक्स आवश्यक हैं?

आंशिक स्वीकृतियों को भी एक ही स्तर की सावधानी चाहिए। यदि ट्रैवल स्वीकृत है पर होटल खर्च नहीं है, तो क्या अनुरोधकर्ता वही रिकॉर्ड एडिट करे या नया बनाए? क्या फाइनेंस केवल बदले हुए हिस्से की पुनरावृति करेगा, या फिर से सब कुछ रिव्यू करेगा? यदि यह पहले तय नहीं किया गया, तो स्क्रीन सजी हुई लग सकती है पर प्रक्रिया पीछे से गंदी रहेगी।

जब टीमें पहले नियम तय कर लेती हैं, इंटरफ़ेस सरल हो जाता है। अधिक महत्वपूर्ण यह है कि उपयोगकर्ता को अगला कदम पता होता है, भले ही जवाब "अभी स्वीकृत नहीं" ही क्यों न हो।

ऐसे संदेश लिखें जिन पर लोग कार्रवाई कर सकें

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

यह वह जगह है जहाँ डिज़ाइन उपयोगकर्ताओं के लिए वास्तविक बनता है। आपके आंतरिक नियम स्पष्ट हो सकते हैं, पर अगर स्क्रीन केवल "Error" या "Pending review" दिखाती है, तो लोग अनुमान लगाएंगे, गलत फाइलें फिर से भेजेंगे, या सपोर्ट से मदद माँगेंगे।

एक विक्रेता अनुमोदन का उदाहरण लें। एक उपयोगकर्ता ने कर दस्तावेज़, बैंक विवरण, और बीमा प्रमाण भेजा। बैंक विवरण ठीक हैं, कर दस्तावेज़ पुराना है, और बीमा प्रमाण ग़ायब है। यदि सिस्टम केवल "Request not approved" दिखाता है, तो उपयोगकर्ता के पास कोई स्पष्ट अगला कदम नहीं है।

एक बेहतर संदेश कुछ ऐसा बोले: "आपके बैंक विवरण स्वीकृत किए गए हैं। हमें अंतिम कर दस्तावेज़ और बीमा प्रमाण चाहिए ताकि अंतिम स्वीकृति मिल सके।" वह एक वाक्य समय बचाता है क्योंकि यह जो पूरा हो चुका है और जो बाकी है, अलग कर देता है।

अच्छे संदेश आम तौर पर चार छोटे सवालों के जवाब देते हैं:

• किस भाग को अस्वीकार/ग़ायब/अभी रिव्यू किया जा रहा है?
• किस भाग को पहले ही स्वीकार किया जा चुका है?
• व्यक्ति को क्या अपलोड/बदल/पुष्टि करना है?
• वे पुनः जमा करने के बाद क्या उम्मीद कर सकते हैं?

यह आख़िरी हिस्सा मायने रखता है। जब अगला कदम स्पष्ट हो तो लोग कार्य पूरा करने की अधिक संभावना रखते हैं। "Missing file अपलोड करें और पुनः सबमिट करें" कहने से बेहतर है कि बस "Action required" कहा जाए।

अस्पष्ट लेबल चिंता पैदा करते हैं। "Pending review" का अर्थ व्यक्ति के इंतज़ार, ग़ायब डेटा, या किसी अंदरूनी चेक—कुछ भी हो सकता है। यदि कारण पता है, तो उसे स्पष्ट रूप से बताएं। "Waiting for manager approval" और "Waiting for proof of address" एक जैसे नहीं हैं, और उन्हें एक जैसा नहीं दिखना चाहिए।

यदि प्रक्रिया आंशिक स्वीकृति की अनुमति देती है, तो इसे स्टेटस में ही स्पष्ट दिखाएँ। एक संक्षिप्त ब्रेकडाउन अक्सर एक लेबल से बेहतर काम करता है:

• Approved: identity document
• Needs update: tax form
• Missing: insurance certificate

अब उपयोगकर्ता केवल वही सुधार सकता है जो जरूरी है। उन्हें फिर से शुरू करने की ज़रूरत नहीं पड़ती।

यहाँ फिर से सबमिशन को भी आसानी से खोजने लायक बनाना चाहिए। अगली कार्रवाई संदेश के पास रखें, किसी अन्य स्क्रीन पर नहीं। यदि आप AppMaster में फ्लो बना रहे हैं, तो यूज़र-फेसिंग स्टेटस टेक्स्ट को वास्तविक बिज़नेस प्रोसेस स्टेट्स से मिलाना मददगार होता है ताकि ऐप ठीक वही बताए जो वर्कफ़्लो कर रहा है।

अच्छे संदेश सपोर्ट टिकट घटाते हैं, अनुमोदनों को तेज़ करते हैं, और प्रक्रिया को निष्पक्ष महसूस कराते हैं। जब लोग अस्वीकृति को समझते हैं तो उसे स्वीकार भी कर लेते हैं।

वे गलतियाँ जो पुन:काम पैदा करती हैं

ज़्यादातर पुन:काम एक गलत मान्यता से शुरू होता है: सामान्य पाथ ही मुख्य चीज़ है जिसे डिज़ाइन करना है। टीमें अनुरोध सबमिट, स्वीकृत, पूरा मानचित्रित करती हैं और वहीं रुक जाती हैं। फिर असली जीवन आता है: फ़ाइल ग़ायब है, मैनेजर बदलाव चाहता है, या केवल एक हिस्सा आगे बढ़ सकता है।

वह गैप बहुत जल्दी अतिरिक्त काम बन जाता है। लोग मैन्युअल फिक्स बनाते हैं, साइड संदेश भेजते हैं, और स्टेटस बाद में बदल देते हैं। कुछ ही हफ्तों में कोई वर्कफ़्लो पर भरोसा नहीं करता क्योंकि हर अपवाद विशेष मामला जैसा महसूस होता है।

एक आम गलती आदर्श पाथ को प्रोडक्ट मानना और बाकी सबको क्लीनअप समझना है। कल्पना करें एक खर्चा अनुरोध जिसे रसीद, विभागीय अनुमोदन, और फाइनेंस रिव्यू चाहिए। अगर रसीद ग़ायब है, तो क्या अनुरोध रुकेगा, कर्मचारी को वापस जाएगा, या अस्वीकार कर दिया जाएगा? यदि यह नियम शुरुआत में स्पष्ट नहीं है, टीम आमतौर पर बाद में ईमेल और कमेंट्स से पैच कर देती है।

उलझाने वाले स्टेटस नाम एक और पुन:काम का कारण बनते हैं। "In review 2" या "Pending action" जैसे लेबल मासूम लगते हैं, पर वे लोगों को यह अनुमान लगाने के लिए मजबूर करते हैं कि आगे क्या होगा। स्पष्ट नाम गलती घटाते हैं क्योंकि वे समस्या, मालिक, परिणाम, या अगला कदम दिखाते हैं।

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

आंशिक स्वीकृति भी अक्सर गलत ढंग से संभाली जाती है। टीमें इसे पूरी अस्वीकृति जैसा ट्रीट कर देती हैं क्योंकि वह सरल लगता है। पर वे अलग परिणाम हैं। यदि ट्रैवल अनुरोध में फ्लाइट, होटल, और भोजन हैं, तो फाइनेंस उड़ान और होटल को स्वीकृत पर भोजन को अस्वीकृत कर सकता है। उस केस को अपना पाथ, अपना संदेश, और अक्सर अपनी फॉलो-अप कार्रवाई चाहिए।

जब आंशिक स्वीकृति को अस्वीकृति में मिला दिया जाता है, लोग पूरा अनुरोध फिर से सबमिट करते हैं, दस्तावेज़ डुप्लिकेट करते हैं, और उन रिव्यूज़ को दोहराते हैं जो पहले ही हो चुकी थीं। यह शुद्ध पुन:काम है।

एक सरल परीक्षण मदद करता है: हर नॉन-हैप्पी-पाथ स्टेट पढ़ें और पूछें, "किसका मालिक है यह, उपयोगकर्ता क्या देखता है, और आगे क्या होता है?" यदि उत्तर धुंधला है, तो प्रक्रिया उसी स्थान पर बाद में टूटेगी।

निर्माण से पहले त्वरित जाँच

स्क्रीन बनाना या कुछ ऑटोमेट करने से पहले, गंदे मामलों पर एक आख़िरी पास करें। अच्छा अपवाद-पथ डिज़ाइन अक्सर शुरू में लिए गए कुछ स्पष्ट निर्णयों का परिणाम होता है, इससे पहले कि भ्रम पुन:काम में बदल जाए।

यदि कोई अनुरोध अस्वीकार किया गया, रोका गया, या केवल आंशिक रूप से स्वीकृत है, तो किसी को हमेशा पता होना चाहिए कि आगे क्या होगा, कौन करेगी, और कौन सी जानकारी अभी ग़ायब है।

अपने प्रोसेस के हर अपवाद पर इस त्वरित जाँच का उपयोग करें:

• हर अपवाद का एक मालिक है।
• हर स्टेट एक स्पष्ट अगले कदम की ओर ले जाता है।
• ग़ायब आइटम सादा भाषा में नामित हैं।
• आंशिक स्वीकृतियों के नियम हैं, अंदाज़े नहीं।
• समय निर्धारित है।

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

एक छोटा उदाहरण बिंदु स्पष्ट करता है। कल्पना करें कि एक मैनेजर एक सॉफ़्टवेयर अनुरोध को मंज़ूर कर देता है पर हार्डवेयर भाग को अस्वीकार कर देता है। यदि स्टेटस केवल "Partially approved" कहता है, तो कर्मचारी समझ सकता है कि सब कुछ आगे बढ़ सकता है। एक बेहतर स्टेटस स्पष्ट रूप से बताए कि क्या स्वीकृत हुआ, क्या अस्वीकार किया गया, और क्या कर्मचारी ग़ायब भाग फिर से सबमिट कर सकता है।

यदि आप उन नियमों को कार्यशील आंतरिक ऐप में बदलना चाहते हैं, तो पहले अपवाद स्टेट्स मैप करें और हैप्पी पाथ बाद में बनाएं। AppMaster में, इसका मतलब स्टेटस, बिज़नेस नियम, और आवश्यक फ़ील्ड पहले परिभाषित करना हो सकता है—UI की परवाह करने से पहले। यह नो-कोड एप्लिकेशंस बनाने का व्यावहारिक तरीका है जो असली काम संभालते हैं, न कि केवल उसका आदर्श संस्करण।

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