> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# वर्कफ़्लो बिल्डर: नो-कोड KYC फ़्लो डिज़ाइनर

> Didit के विज़ुअल वर्कफ़्लो बिल्डर से नो-कोड पहचान सत्यापन फ़्लो बनाएँ। ड्रैग-एंड-ड्रॉप ID, लाइवनेस, AML, NFC और शर्त-आधारित लॉजिक। केवल पूरे हुए चरणों का शुल्क।

Didit के Orchestrated Workflows पूरे, बहु-चरणीय पहचान सत्यापन यात्राएँ डिज़ाइन और लागू करने का सबसे शक्तिशाली और लचीला तरीका हैं।

यह Didit Academy पाठ वास्तविक कंसोल में एक सत्यापन वर्कफ़्लो बनाता है, टेम्पलेट से लेकर प्रकाशित फ़्लो तक: हर नोड पर जाँच चुनना, नियम और थ्रेशोल्ड, AML ब्रांचिंग, webhook नोड और संस्करण रोलबैक।

[Didit Academy में अपना पहला सत्यापन फ़्लो बनाएँ — Didit Academy](https://www.youtube.com/embed/7-nJ3JE20i4?rel=0\&playsinline=1)

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

इस पथ को तब चुनें जब आपको उपयोगकर्ता ऑनबोर्डिंग (KYC), आयु सत्यापन, या पुनः प्रमाणीकरण के लिए एक पूर्ण, एंड-टू-एंड समाधान चाहिए, और आप न्यूनतम विकास प्रयास के साथ तेज़ी से शुरू करना चाहते हैं, साथ ही प्रक्रिया पर अधिकतम नियंत्रण भी रखना चाहते हैं।

## देश पहचान विधियाँ

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

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

लाइव एप्लिकेशन केवल प्रोडक्शन के लिए उपलब्ध वॉलेट सक्षम कर सकते हैं।
लॉन्च की प्रतीक्षा कर रहे वॉलेट अक्षम रहते हैं।
सैंडबॉक्स एप्लिकेशन कैटलॉग के हर वॉलेट का सिमुलेटेड परिणामों के साथ परीक्षण कर सकते हैं; सैंडबॉक्स में उपलब्धता का अर्थ प्रोडक्शन में उपलब्धता नहीं है।
लुकअप और वॉलेट विफलता के परिदृश्यों के लिए [सैंडबॉक्स परीक्षण](https://docs.didit.me/hi/integration/sandbox-testing.md) देखें।

## वर्कफ़्लो संस्करण

वर्कफ़्लो **ड्राफ़्ट/प्रकाशित संस्करण प्रणाली** को सपोर्ट करते हैं। इसका मतलब है कि आप लाइव सत्रों को प्रभावित किए बिना अपने वर्कफ़्लो में सुरक्षित रूप से सुधार कर सकते हैं:

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

प्रकाशित वर्कफ़्लो में बदलाव करने के लिए, प्रकाशित संस्करण से एक नया ड्राफ़्ट बनाएँ, उसे संपादित करें, और तैयार होने पर प्रकाशित करें। संस्करण इतिहास Management API के माध्यम से उपलब्ध है।

***

## वर्कफ़्लो बनाने के दो तरीके

Didit सत्यापन वर्कफ़्लो बनाने के लिए **दो अलग तरीके** देता है, ताकि आप अपनी ज़रूरत के हिसाब से सही स्तर की जटिलता चुन सकें:

![Didit KYC वर्कफ़्लो सरल और उन्नत बिल्डर मोड साथ-साथ](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple-and-complex.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=07f4e97f94cb1179de16732573612b6e)

### 1. सरल मोड: टेम्पलेट-आधारित बिल्डर

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

![Didit पहचान सत्यापन वर्कफ़्लो सरल मोड टेम्पलेट बिल्डर इंटरफ़ेस](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=ebe4da7cf6549793629497fb36053fe2)

**किसके लिए सबसे अच्छा है:**

* त्वरित सेटअप और डिप्लॉयमेंट
* मानक सत्यापन प्रवाह
* पहचान सत्यापन में नई टीमें
* सामान्य पैटर्न पर आधारित उपयोग के मामले

**यह कैसे काम करता है:**

1. एक वर्कफ़्लो टेम्पलेट चुनें (KYC, आयु सत्यापन, आदि)
2. सुविधाएँ चालू या बंद करें (लाइवनेस, चेहरा मिलान, AML, आदि)
3. हर सुविधा के लिए बुनियादी सेटिंग्स कॉन्फ़िगर करें
4. प्रकाशित करें और सत्यापन शुरू करें

***

### 2. उन्नत मोड: विज़ुअल ग्राफ़ बिल्डर

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

![नोड-आधारित वर्कफ़्लो विज़ुअल ग्राफ़ बिल्डर](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/node-based-workflow.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2c0997ab8bbb09dbf7c4cb26b201eced)

**किसके लिए सबसे अच्छा है:**

* जटिल, कई-पथ वाली सत्यापन यात्राएँ
* उपयोगकर्ता डेटा या सत्यापन परिणामों पर आधारित शर्त-तर्क
* कस्टम व्यावसायिक नियम और शाखाकरण
* एंटरप्राइज़-स्तरीय अनुपालन आवश्यकताएँ

**मुख्य क्षमताएँ:**

* **विज़ुअल नोड एडिटर**: एक असीमित कैनवास पर नोड्स को खींचें, छोड़ें और जोड़ें
* **स्मार्ट कनेक्शन**: किसी नोड के हैंडल से खाली जगह की ओर खींचें, और तुरंत एक नया नोड बनाकर उससे जोड़ें
* **शर्त-आधारित शाखाएँ**: निकाले गए डेटा, सत्यापन स्थिति, देश, दस्तावेज़ प्रकार, [दस्तावेज़ उप-प्रकार](https://docs.didit.me/hi/core-technology/id-verification/document-subtypes-id-verification.md), जारी होने की तिथि, आयु, webhook JSON रिस्पॉन्स पथ, या कस्टम नियमों के आधार पर उपयोगकर्ताओं को रूट करें
* **कार्रवाई स्वचालन**: प्रवाह के परिणामों के आधार पर टैग जोड़ें, मेटाडेटा सेट करें, या मैन्युअल समीक्षा के लिए रूट करें
* **कीबोर्ड शॉर्टकट**: पूर्ववत करें (Ctrl/Cmd+Z), फिर से करें (Ctrl/Cmd+Shift+Z), हटाएँ (Delete/Backspace)
* **ज़ूम और पैन**: स्क्रॉल से ज़ूम और ड्रैग से पैन करके जटिल प्रवाहों में आगे-पीछे जाएँ

#### ग्राफ़ बिल्डर नोड प्रकार

| नोड प्रकार | आइकन रंग | विवरण | उदाहरण |
| - | - | - | - |
| **सुविधा नोड्स** | नीला | उपयोगकर्ता डेटा को प्रोसेस करने वाली सत्यापन जाँचें | पहचान सत्यापन (OCR), लाइवनेस, चेहरा मिलान, NFC, AML, फ़ोन/ईमेल सत्यापन, प्रश्नावली, पते का प्रमाण, Document AI, डेटाबेस सत्यापन, डिवाइस और IP विश्लेषण, आयु अनुमान |
| **शाखा नोड्स** | बैंगनी | डेटा या परिणामों के आधार पर शर्त-आधारित रूटिंग | देश, जोखिम स्कोर, दस्तावेज़ प्रकार, दस्तावेज़ उप-प्रकार, आयु, जारी होने की तिथि, जारी होने के बाद के महीने, सत्यापन स्थिति के आधार पर रूट करें |
| **कार्रवाई नोड्स** | एम्बर | सत्र या उपयोगकर्ता डेटा बदलने वाले स्वचालन ट्रिगर | टैग जोड़ें, टैग हटाएँ, मेटाडेटा सेट करें, समीक्षा नोट जोड़ें |
| **Webhook नोड्स** | सियान | HTTP अनुरोध जो बाद की शाखाओं को डेटा दे सकते हैं | सत्र डेटा आपके सर्वर पर भेजें, JSON रिस्पॉन्स पार्स करें, `category`, `status`, या `tags.0` जैसे पथों पर शाखा बनाएँ |
| **स्टेटस नोड्स** | हरा/लाल/एम्बर | अंतिम परिणाम जो सत्यापन प्रवाह को समाप्त करते हैं | स्वीकृत, अस्वीकृत, समीक्षाधीन |

#### सुविधा नोड श्रेणियाँ

**उपयोगकर्ता-इंटरैक्टिव सुविधाएँ** (वर्कफ़्लो शुरू कर सकती हैं):

* पहचान सत्यापन (OCR)
* लाइवनेस डिटेक्शन
* चेहरा मिलान
* आयु अनुमान
* फ़ोन सत्यापन
* ईमेल सत्यापन
* प्रश्नावली
* पते का प्रमाण
* Document AI
* NFC / ePassport

**केवल-बैकएंड सुविधाएँ** (अपने-आप चलती हैं, उपयोगकर्ता के साथ कोई इंटरैक्शन नहीं):

* AML स्क्रीनिंग (इससे पहले पहचान सत्यापन, KYB रजिस्ट्री या Document AI चरण की आवश्यकता है - देखें [स्क्रीन की जाने वाली इकाई](#स्क्रीन-की-जाने-वाली-इकाई))
* डेटाबेस सत्यापन (पहले OCR की आवश्यकता है)
* डिवाइस और IP विश्लेषण

> **नोट:** केवल-बैकएंड सुविधाओं को बिल्डर में एक विशेष संकेतक से चिह्नित किया जाता है, और उनकी निर्भरताएँ पूरी होते ही वे उपयोगकर्ता के बिना इंटरैक्शन के अपने-आप चलती हैं।

हर सुविधा नोड के पहले कॉन्फ़िगरेशन टैब की शुरुआत **सत्यापन इंजन** नियंत्रण से होती है: जाँच को Didit के अपने इंजन से चलाएँ, या उसे [Marketplace](https://docs.didit.me/hi/console/marketplace.md) से जुड़े किसी तृतीय-पक्ष प्रदाता पर स्विच करें। यदि वह प्रदाता उपलब्ध न हो, तो Didit पर अपने-आप फ़ॉलबैक होता है।

#### स्क्रीन की जाने वाली इकाई

AML स्क्रीनिंग आम तौर पर उसी चरण से सीखती है जो उसके सामने है: वह व्यक्ति जिसे **पहचान सत्यापन** चरण ने दस्तावेज़ से पढ़ा, या वह कंपनी जिसे **KYB रजिस्ट्री** चरण ने लौटाया। कुछ प्रवाहों में इनमें से कोई नहीं होता। पूरी तरह **Document AI** पर बना प्रवाह - गैर-मानकीकृत दस्तावेज़, जैसे कर प्रमाणपत्र या नोटरी द्वारा प्रमाणित निगमन विलेख - पहले से ही नाम, जन्म तिथि, दस्तावेज़ संख्या और देश रखता है, बस आपकी अपनी फ़ील्ड कुंजियों के तहत।

AML नोड का **उन्नत** टैब वह जगह है जहाँ आप उन कुंजियों को स्क्रीनिंग से जोड़ते हैं:

* **इकाई प्रकार** - **व्यक्ति** की स्क्रीनिंग करें, या अपलोड किए गए दस्तावेज़ में नामित **कंपनी** की। कंपनी नोड लोगों के बजाय कंपनी रिकॉर्ड में खोजता है।
* **फ़ील्ड स्रोत** - चारों स्क्रीनिंग इनपुट (नाम, जन्म तिथि, देश, दस्तावेज़ संख्या) में से हर एक को Document AI फ़ील्ड, प्रश्नावली के उत्तर, या सत्र बनाते समय भेजे गए मान (`expected_details` / `metadata`) से मैप करें। जो Document AI फ़ील्ड आपने पहले से `full_name` नाम दिया है, वह अपने-आप उठा लिया जाता है।
* **अधूरा स्क्रीनिंग डेटा** - जब स्क्रीनिंग पूरी पहचान से कम डेटा पर चलती है, तो क्या होता है। डिफ़ॉल्ट रूप से समीक्षा होती है; *No action* तभी चुनें जब प्रवाह जानबूझकर केवल नाम रखता हो।

#### ब्रांच शर्तें सत्र डेटा कैसे पढ़ती हैं

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

**कौन-सा रिकॉर्ड शर्त पढ़ती है।** एक शाखा शर्त उस फ़ीचर नोड से बंधी होती है जिससे वह बनाई गई थी, और वह उस नोड का परिणाम पढ़ती है। जब एक ही नोड ने एक से अधिक रिकॉर्ड बनाए हों, तो शर्त **सबसे हाल का** रिकॉर्ड पढ़ती है। यह **Device & IP Analysis** के लिए सबसे अधिक मायने रखता है: Didit हर उस डिवाइस और IP पते के लिए एक अवलोकन रिकॉर्ड करता है जिससे कोई सत्र खोला जाता है, इसलिए जो उपयोगकर्ता सत्र के बीच में फ़ोन या नेटवर्क बदलता है, उस नोड पर कई रिकॉर्ड छोड़ता है। उदाहरण के लिए `IP COUNTRY is in [...]` जैसा नियम **सबसे नए** अवलोकन पर मूल्यांकित होता है - वही रिकॉर्ड जो सत्र के Device & IP Analysis पैनल में और decision payload के `ip_analyses` array में पहले दिखता है। जिन सत्रों में एक से अधिक अवलोकन होते हैं, उनमें `MULTIPLE_DEVICES_IN_SESSION` चेतावनी भी होती है, जो संकेत है कि केवल शाखा के परिणाम के बजाय पूरी सूची की समीक्षा करें।

**देश के मान।** देश की शर्तें देश के आधार पर मिलाई जाती हैं, नोटेशन के आधार पर नहीं। फ़ील्ड पिकर से देश चुनें, और Didit तुलना के दोनों पक्षों को सामान्य कर देता है, इसलिए ISO 3166-1 alpha-3 (`UKR`) में लिखा नियम भी alpha-2 (`UA`) में कैप्चर किए गए मान से मेल खाता है।

**गायब मान, खाली मान और नकारात्मक तुलनाएँ।** जिस फ़ील्ड में **कोई मान बिल्कुल नहीं** है (दस्तावेज़ में वह नहीं है, metadata key नहीं भेजी गई, या फ़ीचर चला ही नहीं), वह केवल `is empty` और `equals not_defined` से मेल खाता है; बाकी हर तुलना - `equals`, `contains`, `greater than`, और साथ ही `not equals` तथा `not in` - मेल नहीं खाती, और शाखा नोड अपनी अगली शाखा पर चला जाता है। जो फ़ील्ड **खाली स्ट्रिंग** रखता है, वह गायब फ़ील्ड नहीं बल्कि एक मान है: `"metadata": {"credential_state": ""}` के साथ बनाया गया सत्र `metadata.credential_state equals IL` में विफल होता है, पर `not equals IL`, `not in [IL, MA, NJ]` और `equals ""` में पास होता है (`is empty` दोनों स्थितियों से मेल खाता है)। इसलिए जो शाखा नकारात्मक तुलना पर स्वीकृत करती है, वह ऐसे सत्र को स्वीकृत कर देती है जिसकी स्थिति खाली भेजी गई थी, जबकि वही सत्र, जिसमें key छोड़ी गई थी, फ़ॉलबैक पर जाता है। जब आप `not equals` या `not in` पर रूट करें, तो उसी शाखा में `metadata.<key> is not empty` जोड़ें (AND लॉजिक) ताकि दोनों स्थितियाँ वहीं समाप्त हों जहाँ गायब मान समाप्त होना चाहिए। शाखाएँ क्रम से मूल्यांकित होती हैं और पहला मेल जीतता है; फ़ॉलबैक शाखा (वह शाखा जिसमें कोई शर्त नहीं) **केवल तब** ली जाती है **जब कोई अन्य शाखा मेल नहीं खाती**, इसलिए हर शाखा नोड को एक फ़ॉलबैक दें जो वहीं समाप्त हो जहाँ आप किसी अप्रत्याशित मान को समाप्त करना चाहते हैं। जो सत्र बिना किसी फ़ीचर की चेतावनी के समीक्षाधीन (In Review) में पहुँचता है, उसे किसी जाँच ने नहीं, बल्कि ग्राफ़ में किसी स्थिति नोड ने वहाँ भेजा है; शाखा नोड की फ़ॉलबैक शाखा इसका सामान्य कारण है।

**सत्र metadata।** सत्र बनाते समय `metadata` में भेजे गए मान हर शाखा के लिए `metadata.<key>` के रूप में उपलब्ध हैं और उनकी तुलना किसी निश्चित मान से या किसी अन्य सत्र फ़ील्ड से की जा सकती है (उदाहरण के लिए `metadata.min_age <= Age`)। संख्याओं की तुलना संख्याओं के रूप में होती है, इसलिए `18` और `"18"` एक ही तरह व्यवहार करते हैं।

**सैंडबॉक्स / परीक्षण मोड।** शाखा शर्तें, metadata और स्थिति नोड सैंडबॉक्स में भी वैसे ही चलते हैं जैसे लाइव में, और सैंडबॉक्स अपने आप किसी सत्र को समीक्षा में कभी नहीं भेजता। अंतर दस्तावेज़ का है: सैंडबॉक्स सत्र में एक गढ़ा गया दस्तावेज़ होता है जिसमें कोई US राज्य / क्षेत्र नहीं होता, इसलिए `Region` शर्तें वहाँ मेल नहीं खा सकतीं। राज्य-निर्भर फ़्लो का परीक्षण कैसे करें, यह देखने के लिए [गढ़े गए दस्तावेज़ में क्या नहीं होता](https://docs.didit.me/hi/integration/sandbox-testing.md#lo-que-no-incluye-el-documento-fabricado) देखें।

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

**देखें कि सत्र ने कौन-सी शाखा ली।** सत्र चलने के दौरान वर्कफ़्लो द्वारा लिया गया हर शाखा निर्णय, और हर परिणाम नोड जिस तक सत्र पहुँचता है, सत्र की इवेंट टाइमलाइन पर दर्ज होता है (Console session detail > Events, और `GET /v3/session/{id}/decision/?include=events`)। एक **वर्कफ़्लो रूटिंग** पंक्ति शाखा नोड का नाम बताती है, वह शर्त जो मेल खाई, और वह नोड जिस पर सत्र आगे बढ़ा - या बताती है कि **कोई शर्त मेल नहीं खाई** और नोड की फ़ॉलबैक एज ली गई। एक **वर्कफ़्लो परिणाम** पंक्ति उस स्थिति नोड का नाम बताती है जिसने सत्र की स्थिति तय की। जब कोई वर्कफ़्लो किसी सत्र को *समीक्षाधीन (In Review)* में भेजता है और कोई फ़ीचर उसे फ़्लैग नहीं करता, तो ये पंक्तियाँ दिखाती हैं कि उसने कौन-सा रास्ता लिया, जिसमें लिया गया फ़ॉलबैक एज और वह परिणाम नोड शामिल है जिस तक वह ले गया। बाद के मैन्युअल निर्णय वर्कफ़्लो इवेंट को फिर नहीं लिखते। गायब इनपुट एक संभावित कारण है: जो शर्तें किसी मौजूद `metadata.*` मान की माँग करती हैं, वे तब मेल नहीं खातीं जब सत्र बनाते समय key छोड़ी गई हो। जो शर्तें स्पष्ट रूप से गायब इनपुट की जाँच करती हैं, जैसे `is_empty` या `not_defined` के साथ `equals`, वे उसी गायब key से मेल खा सकती हैं। फ़ॉलबैक एज तभी ली जाती है जब कोई शाखा मेल नहीं खाती, जिसमें कोई else शाखा भी शामिल है, और वह डिफ़ॉल्ट आउटपुट से जुड़े नोड पर ले जाती है। इवेंट पेलोड के लिए [सत्र इवेंट](https://docs.didit.me/hi/sessions-api/retrieve-session.md#वर्कफ़्लो-राउटिंग-इवेंट) देखें।

## वर्कफ़्लो टेम्पलेट: आपका शुरुआती बिंदु

टेम्पलेट को कठोर प्रकारों के रूप में नहीं, बल्कि आम उपयोग के मामलों के लिए बनाए गए **स्मार्ट, पहले से कॉन्फ़िगर किए गए शुरुआती बिंदुओं** के रूप में समझें। Simple Mode में ये तुरंत उपयोग के लिए तैयार हैं। Advanced Mode में ये एक आधार देते हैं, जिसे आप विस्तार से कस्टमाइज़ कर सकते हैं।

![KYC, KYB और आयु सत्यापन उपयोग मामलों के लिए Didit KYC वर्कफ़्लो टेम्पलेट गैलरी](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-template.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=a727315368aa2f6bd096e873d7fbae6c)

### उपलब्ध टेम्पलेट

#### **1. KYC वर्कफ़्लो**

नए उपयोगकर्ताओं को ऑनबोर्ड करने और पूर्ण अपने ग्राहक को जानें (KYC) अनुपालन पूरा करने के लिए एक व्यापक समाधान।

* **इससे शुरू होता है:** Core ID Document Verification.
* **आमतौर पर जोड़ी जाने वाली सुविधाएँ:**
  * `[+]` **लाइवनेस डिटेक्शन:** सुनिश्चित करें कि उपयोगकर्ता वास्तव में मौजूद है और स्पूफिंग को रोकें।
  * `[+]` **चेहरा मिलान 1:1:** उपयोगकर्ता की सेल्फ़ी को उसकी ID फ़ोटो से बायोमेट्रिक रूप से मिलाएँ।
  * `[+]` **AML स्क्रीनिंग:** उपयोगकर्ताओं की वैश्विक प्रतिबंध, PEP और प्रतिकूल मीडिया सूचियों से जाँच करें।
  * `[+]` **NFC सत्यापन:** ई-पासपोर्ट/ई-ID चिप पढ़कर सरकारी स्तर की सुरक्षा की एक और परत जोड़ें।
  * `[+]` **पते का प्रमाण (PoA):** उपयोगकर्ता के निवास पते को सत्यापित करें।
  * `[+]` **फ़ोन सत्यापन:** अतिरिक्त कारक के रूप में फ़ोन नंबर के स्वामित्व को सत्यापित करें।
  * `[+]` **ईमेल सत्यापन:** अतिरिक्त कारक के रूप में ईमेल पते के स्वामित्व को सत्यापित करें।
  * `[+]` **डेटाबेस सत्यापन:** आधिकारिक सरकारी और क्रेडिट डेटाबेस के विरुद्ध सत्यापित करें।
  * `[+]` **प्रश्नावली:** अनुकूलन योग्य फ़ॉर्म के माध्यम से संरचित अटेस्टेशन और सहायक दस्तावेज़ एकत्र करें।
  * `[+]` **डिवाइस और IP विश्लेषण:** स्थान और कनेक्शन के जोखिम का विश्लेषण करें।

***

#### **2. अनुकूली आयु सत्यापन वर्कफ़्लो**

आयु-सीमित सेवाओं के लिए कम बाधा वाला, गोपनीयता-संरक्षित फ़्लो।

* **इससे शुरू होता है:** सेल्फ़ी-आधारित आयु अनुमान।
* **मुख्य तर्क:**
  * यदि अनुमानित आयु आपकी सीमा से स्पष्ट रूप से ऊपर है (उदाहरण के लिए, 18+ सेवा के लिए अनुमानित 25+), तो उपयोगकर्ता तुरंत उत्तीर्ण हो जाता है।
  * यदि अनुमान सीमा से कम है या "बफ़र ज़ोन" (उदाहरण के लिए, अनुमानित 16-20) में है, तो आप वर्कफ़्लो को जन्म तिथि की सटीक पुष्टि के लिए स्वचालित रूप से **पूर्ण पहचान सत्यापन पर फ़ॉलबैक** करने के लिए कॉन्फ़िगर कर सकते हैं।
* **आमतौर पर जोड़ी जाने वाली सुविधाएँ:**
  * `[+]` **डिवाइस और IP विश्लेषण:** भौगोलिक स्थान के आधार पर पहुँच सीमित करें।

***

#### **3. बायोमेट्रिक प्रमाणीकरण वर्कफ़्लो**

लौटने वाले उपयोगकर्ताओं को दोबारा दस्तावेज़ माँगे बिना तेज़ और सुरक्षित तरीके से पुनः सत्यापित करने का तरीका।

* **इससे शुरू होता है:** यह पुष्टि करने के लिए लाइवनेस डिटेक्शन जाँच कि उपयोगकर्ता मौजूद है।
* **मुख्य तर्क:**
  * सिस्टम नई लाइव सेल्फ़ी और उपयोगकर्ता के प्रारंभिक, स्वीकृत KYC सत्यापन से मिले भरोसेमंद बायोमेट्रिक टेम्पलेट के बीच चेहरा मिलान करता है।
  * यदि उपयोगकर्ता के पास उसी `vendor_data` के अंतर्गत पहले से सहेजा गया चेहरा है (स्वीकृत लाइवनेस चेहरा, ePassport फ़ोटो, ID दस्तावेज़ का पोर्ट्रेट, या नामांकित प्रोफ़ाइल चेहरा), तो आप सत्र बनाते समय `portrait_image` छोड़ सकते हैं, और Didit सहेजे गए चेहरे का स्वतः उपयोग करता है। अन्यथा `portrait_image` पास करें (Base64-एन्कोडेड इमेज, अधिकतम 2MB); दोनों में से कुछ भी न होने पर सत्र निर्माण `400` के साथ विफल हो जाता है।
* **आमतौर पर जोड़ी जाने वाली सुविधाएँ:**
  * `[+]` **फ़ोन सत्यापन:** पते को एक सत्यापित फ़ोन नंबर से जोड़ें।
  * `[+]` **ईमेल सत्यापन:** अतिरिक्त कारक के रूप में ईमेल पते के स्वामित्व को सत्यापित करें।
  * `[+]` **डिवाइस और IP विश्लेषण:** नए स्थानों से होने वाले संदिग्ध लॉगिन प्रयासों को चिह्नित करें।

***

#### **4. पता सत्यापन वर्कफ़्लो**

उन स्थितियों के लिए समर्पित फ़्लो जहाँ पते का प्रमाण (PoA) मुख्य आवश्यकता है।

* **इससे शुरू होता है:** उपयोगकर्ता द्वारा पते के प्रमाण का दस्तावेज़ (जैसे, उपयोगिता बिल, बैंक स्टेटमेंट) जमा करना।
* **मुख्य तर्क:** हमारा AI दस्तावेज़ से नाम और पता निकालता और सत्यापित करता है।
* **आमतौर पर जोड़ी जाने वाली सुविधाएँ:**
  * `[+]` **फ़ोन सत्यापन:** पते को एक सत्यापित फ़ोन नंबर से जोड़ें।
  * `[+]` **ईमेल सत्यापन:** अतिरिक्त कारक के रूप में ईमेल पते के स्वामित्व को सत्यापित करें।
  * `[+]` **डिवाइस और IP विश्लेषण:** अतिरिक्त भरोसे के लिए दस्तावेज़ के पते की उपयोगकर्ता के वर्तमान भौगोलिक स्थान से तुलना करें।

***

#### **5. प्रश्नावली सत्यापन वर्कफ़्लो**

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

* **इससे शुरू होता है:** प्रश्नावली।
* **मुख्य तर्क:** सिस्टम आपकी कॉन्फ़िगर की गई प्रश्नावली (सेक्शन, अनुवादित सामग्री, आवश्यक फ़ील्ड, अपलोड) प्रस्तुत करता है।
* **आमतौर पर जोड़ी जाने वाली सुविधाएँ:**
  * `[+]` **डिवाइस और IP विश्लेषण:** अपनी प्रश्नावली के सबमिशन में स्थान और कनेक्शन का संदर्भ जोड़ें।

> **पूर्ण कस्टमाइज़ेशन**
> वर्कफ़्लो के भीतर प्रत्येक सुविधा को आपकी सटीक आवश्यकताओं के अनुसार विशिष्ट पैरामीटर के साथ और कस्टमाइज़ किया जा सकता है। बिल्डर में हर जाँच की सेटिंग्स देखें।

***

## वैवाहिक स्थिति से नियम बनाना

**Advanced Mode** में, आप सशर्त शाखाओं और कस्टम स्टेटस नियमों में OCR फ़ील्ड `kyc.marital_status` का उपयोग कर सकते हैं। मान फ़ील्ड पिकर से चुनें, ताकि नियम मुक्त-रूप टेक्स्ट के बजाय समर्थित enum का उपयोग करे। यदि दस्तावेज़ में वैवाहिक स्थिति नहीं है, तो मान खाली रहता है और आपकी फ़ॉलबैक शाखा लागू होती है।

वर्कफ़्लो कोपायलट एक ही कार्रवाई में **Database Validation** चरण भी बना और कॉन्फ़िगर कर सकता है। जब आप इस जाँच को जोड़ने का अनुरोध करें, तो वे देश बताएँ जिनकी आपको आवश्यकता है; कंसोल हर देश के लिए समर्थित सेवा तय करता है और सहेजी गई कॉन्फ़िगरेशन कैनवास पर दिखाता है।

***

## सरल बनाम उन्नत मोड की तुलना

| क्षमता | Simple Mode | Advanced Mode |
| - | - | - |
| टेम्पलेट चयन | ✅ | ✅ |
| सुविधाओं को चालू/बंद करना | ✅ | ✅ |
| बुनियादी सुविधा कॉन्फ़िगरेशन | ✅ | ✅ |
| विज़ुअल ग्राफ़ एडिटर | ❌ | ✅ |
| शर्तीय शाखाएँ | ❌ | ✅ |
| कार्रवाई स्वचालन (टैग, मेटाडेटा) | ❌ | ✅ |
| समानांतर सत्यापन पथ | ❌ | ✅ |
| जोखिम-आधारित निर्णय | सीमित | ✅ पूर्ण नियंत्रण |
| Undo/Redo सहायता | ❌ | ✅ |
| कीबोर्ड शॉर्टकट | ❌ | ✅ |

***

## एकीकरण प्रवाह

Orchestrated Workflow का एकीकरण सरल है। आपका सर्वर Didit के साथ एक सत्र बनाता है, एक अद्वितीय URL प्राप्त करता है, और आपके उपयोगकर्ता को उस URL पर रीडायरेक्ट करता है। बाकी काम Didit संभालता है और परिणामों की सूचना webhooks के माध्यम से आपके सर्वर को देता है।

```mermaid theme={null}
sequenceDiagram
participant Customer
participant Client
participant Server
participant Didit
Customer->>Client: Go to verification page
Client->>Server: POST /create-verification-session
Server->>Didit: POST /v3/session/
Didit-->>Server: Return new verification session
Server-->>Client: Return verification session's url
Client->>Customer: Redirect customer to url
Customer->>Didit: Complete verification steps
Didit->>Server: Send status updates
Server->>Customer: Notify of status changes
Customer->>Customer: Return to callback URL
```

***

## सामान्य उपयोग के मामले

<table>
  <thead>
    <tr>
      <th>उपयोग का मामला</th>
      <th>अनुशंसित टेम्पलेट</th>
      <th>अनुशंसित मोड</th>
      <th>सुझाई गई सुविधाएँ</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>बुनियादी पहचान सत्यापन</td>
      <td>KYC</td>
      <td>Simple</td>
      <td>लाइवनेस, चेहरा मिलान</td>
    </tr>

    <tr>
      <td>उच्च-सुरक्षा ऑनबोर्डिंग</td>
      <td>KYC</td>
      <td>Advanced</td>
      <td>NFC, लाइवनेस, चेहरा मिलान, AML, फ़ोन सत्यापन</td>
    </tr>

    <tr>
      <td>आयु-सीमित सामग्री/सेवाएँ</td>
      <td>अनुकूली आयु सत्यापन</td>
      <td>Simple</td>
      <td>पहचान सत्यापन फ़ॉलबैक</td>
    </tr>

    <tr>
      <td>लौटने वाले उपयोगकर्ता का प्रमाणीकरण</td>
      <td>बायोमेट्रिक प्रमाणीकरण</td>
      <td>Simple</td>
      <td>डिवाइस और IP विश्लेषण</td>
    </tr>

    <tr>
      <td>पते का सत्यापन</td>
      <td>पते का प्रमाण</td>
      <td>Simple</td>
      <td>फ़ोन सत्यापन</td>
    </tr>

    <tr>
      <td>वित्तीय सेवाओं में ऑनबोर्डिंग</td>
      <td>KYC</td>
      <td>Advanced</td>
      <td>लाइवनेस, चेहरा मिलान, पते का प्रमाण, AML, डेटाबेस सत्यापन</td>
    </tr>

    <tr>
      <td>क्षेत्र-विशिष्ट अनुपालन</td>
      <td>KYC</td>
      <td>Advanced</td>
      <td>देश के आधार पर शर्तीय रूटिंग, प्रति क्षेत्र अलग जाँच</td>
    </tr>

    <tr>
      <td>जोखिम-आधारित सत्यापन</td>
      <td>KYC</td>
      <td>Advanced</td>
      <td>जोखिम स्कोर पर आधारित शर्तीय शाखाएँ, एस्केलेशन पथ</td>
    </tr>
  </tbody>
</table>

***

## शुरुआत कैसे करें

1. **Didit में नए हैं?** **Simple Mode** और पूर्व-निर्मित टेम्पलेट से शुरुआत करें
2. **अनुकूलन की ज़रूरत है?** शर्तीय तर्क जोड़ने के लिए **Advanced Mode** पर जाएँ

> कस्टम वर्कफ़्लो कॉन्फ़िगरेशन पर चर्चा करने या अपनी विशिष्ट आवश्यकताओं के लिए सबसे उपयुक्त सेटअप पर मार्गदर्शन पाने के लिए हमारी बिक्री टीम से संपर्क करें।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.