CSV इम्पोर्ट कॉलम-मैपिंग UI: सुरक्षित मिलान, डिफ़ॉल्ट और पूर्वावलोकन

CSV इंपोर्ट क्यों कष्टप्रद महसूस होता है

ज़्यादातर लोग CSV इम्पोर्ट के साथ एक साधारण उम्मीद लेकर आते हैं: “बस मेरी स्प्रेडशीट ऐप में चली जाये।” फिर पहली स्क्रीन पर ऐसे फैसले माँगे जाते हैं जिन्हें वे समझते नहीं हैं, और इम्पोर्ट ऐसे कारणों से फेल हो जाता है जो यादृच्छिक लगते हैं।

CSV फाइलें अक्सर जितनी साफ़ दिखती हैं उससे कहीं अधिक बेचैन होती हैं। हेडर गायब हो सकते हैं, आपके फ़ील्ड नामों से अलग तरीके से लिखे हुए हो सकते हैं, या डुप्लिकेट हो सकते हैं ("Email", "email", "Email Address")। तारीखें अजीब फॉर्मैट में हो सकती हैं, फोन नंबरों के आगे के शून्य गायब हो सकते हैं, और पतों के अंदर के कॉमा कॉलम तोड़ देते हैं। यहां तक कि "साफ़" एक्सपोर्ट में भी नोट्स, आंतरिक IDs, या खाली ट्रेलिंग कॉलम जैसे अतिरिक्त कॉलम होते हैं।

डर वास्तविक है: अगर आप गलत अंदाज़ा लगाते हैं, तो क्या यह अच्छे डेटा को ओवरराइट कर देगा, सैकड़ों टूटे रिकॉर्ड बनाएगा, या सिस्टम में कचरा फैला देगा? एक अच्छा CSV इम्पोर्ट कॉलम-मैपिंग UI वही चिंता दूर कर देता है—यह दिखाकर कि कुछ भी लिखने से पहले क्या होने वाला है।

"मैपिंग" बस मिलान करना है। मतलब: CSV की यह कॉलम आपके ऐप के उस फ़ील्ड में जाएगी। उदाहरण के लिए, CSV कॉलम "Company" को फ़ील्ड "Account name" से मैप किया जाता है, और "Start Date" को "Customer since" से। सिद्धांत में आसान, पर नाम मेल न खाने पर गलती होना आसान है।

एक सुरक्षित इम्पोर्ट स्पष्ट अपेक्षाएँ सेट करता है और एक अनुमाननीय क्रम का पालन करता है:

• कॉलम्स को फ़ील्ड्स से मिलाएँ (मैपिंग)
• तय करें कि डेटा गायब होने पर क्या किया जाएगा (डिफ़ॉल्ट)
• समस्याओं की जांच करें (वैलिडेशन)
• परिणाम दिखाएँ (पूर्वावलोकन)
• तभी रिकॉर्ड लिखें

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

एक अच्छी कॉलम-मैपिंग स्क्रीन को क्या करना चाहिए

CSV इम्पोर्ट कॉलम-मैपिंग UI का एक ही काम है: यह स्पष्ट कर देना कि कुछ भी सेव होने से पहले क्या होने वाला है। उपयोगकर्ताओं को अनुमान नहीं लगाना चाहिए कि आप नए रिकॉर्ड बना रहे हैं, मौजूदा को अपडेट कर रहे हैं, या पंक्तियों को स्किप कर रहे हैं।

स्क्रीन को इन सवालों का स्पष्ट उत्तर देना चाहिए:

• क्या बनाया जाएगा (नए रिकॉर्ड) और किस तालिका या ऑब्जेक्ट में
• क्या अपडेट किया जाएगा, और मिलान के लिए कौन सा फ़ील्ड उपयोग किया जाएगा (जैसे ईमेल या एक्सटर्नल ID)
• क्या स्किप किया जाएगा, और क्यों (आवश्यक फ़ील्ड गायब है, डुप्लिकेट, अमान्य मान)
• प्रत्येक समूह में कितनी पंक्तियाँ प्रभावित होंगी, अपलोड की गई फ़ाइल से वास्तविक काउंट के साथ
• यदि कोई मान खाली है तो सिस्टम क्या करेगा (खाली रखेगा, डिफ़ॉल्ट उपयोग करेगा, मौजूदा मान रखेगा)

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

लोग बेसिक क्लीनअप भी उम्मीद करते हैं बिना फ़ॉर्मूला लिखे। मैपिंग के स्थान पर ही सरल ट्रांसफ़ॉर्मेशन ऑफर करें, जैसे अतिरिक्त स्पेस हटाना, नंबर फॉर्मैट बदलना, और तारीख फॉर्मैट चुनना। उदाहरण के लिए, अगर CSV में " New York " है, तो एक ट्रिम विकल्प पूर्वावलोकन में उसे "New York" दिखाना चाहिए।

हर समस्या इम्पोर्ट को रोकना नहीं चाहिए। समस्याओं को ब्लॉक बनाम वॉर्निंग में बाँटें, और साधारण शब्दों में अंतर समझाएँ:

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

अगर आप ये बेसिक्स सही कर लेते हैं, तो इम्पोर्ट फ्लो शांत हो जाता है: उपयोगकर्ता नियंत्रित महसूस करते हैं, और "क्यों गलत इम्पोर्ट हुआ?" वाले सपोर्ट टिकट कम आते हैं।

उपयोगकर्ताओं को CSV कॉलम्स फ़ील्ड्स से मिलाने में मदद करना

एक अच्छी CSV इम्पोर्ट कॉलम-मैपिंग UI सहायक की तरह महसूस होनी चाहिए, पहेली की तरह नहीं। पहले रो को हेडर के रूप में पढ़ना शुरू करें और तुरंत सुझाए गए मिलानों की पेशकश करें। सरल संकेतों का उपयोग करें जैसे नाम समानता ("email" -> "Email") और एक छोटा साइननॉनिम सूची ("Phone" बनाम "Mobile", "Zip" बनाम "Postal code", "Company" बनाम "Organization")।

सुझाव तब सबसे बेहतर काम करते हैं जब वे शांत और स्पष्ट हों। मेलों को exact, likely, या unsure के रूप में मार्क करें। हिन्ट सूक्ष्म रखें (एक छोटा लेबल या आइकन), ताकि उपयोगकर्ता तेजी से स्कैन कर सकें बिना परेशान हुए।

उपयोगकर्ताओं को किसी भी चीज़ को ओवरराइड करने का आसान तरीका दें। एक ड्रॉपडाउन ठीक है, पर एक सर्च बॉक्स जोड़ें ताकि वे "status" टाइप कर के सेकंड में सही फ़ील्ड चुन सकें। अगर आपके प्रोडक्ट में कई फ़ील्ड्स हैं, तो उन्हें समूहित करें (Contact, Address, Billing) ताकि सूची भारी न लगे।

अनचाहे खराब इम्पोर्ट्स रोकने के लिए, कन्फ्लिक्ट बनाना मुश्किल करें:

• डिफ़ॉल्ट रूप से केवल एक CSV कॉलम को ही एक टारगेट फ़ील्ड के लिए अनुमति दें
• यदि उपयोगकर्ता किसी फ़ील्ड को चुनता है जो पहले से मैप्ड है, तो स्पष्ट चेतावनी दिखाएँ और पूछें कि क्या मौजूदा मैपिंग बदलनी है
• केवल तभी स्पष्ट "combine" विकल्प दें जब वह सपोर्टेड हो (उदाहरण: First name + Last name)
• जिन आवश्यक टारगेट फ़ील्ड्स का मैप नहीं हुआ है उन्हें हाईलाइट करें

एक छोटा उदाहरण: उपयोगकर्ता स्प्रेडशीट से "Mobile" और "Phone" इम्पोर्ट करता है। अगर दोनों को एक ही "Phone" फ़ील्ड से मैप किया गया है, तो UI उन्हें रोकना चाहिए, समझाना चाहिए कि एक ओवरराइट होगा, और विकल्प सुझाना चाहिए (एक को "Mobile" पर मैप करें, या एक को इग्नोर करें)।

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

खाली या गलत रिकॉर्ड्स को रोकने वाले डिफ़ॉल्ट्स

कॉलम-मैपिंग स्क्रीन केवल फ़ील्ड्स को मिलाने तक सीमित नहीं होनी चाहिए। इसे यह भी तय करना चाहिए कि CSV सेल खाली होने पर क्या किया जाएगा। अगर आप इसे छोड़ देते हैं, तो अक्सर आधे भरे रिकॉर्ड या बदतर—गलत डेटा जो वैध दिखता है—बन जाते हैं।

प्रत्येक मैप्ड फ़ील्ड के लिए स्पष्ट "जब खाली हो" विकल्प दें। इसे उसी रो में प्रेडिक्टेबल और दिखने योग्य रखें ताकि लोग स्कैन करते समय इसे न चूकें।

यहाँ तीन व्यवहार हैं जिनकी ज़्यादातर टीमों को ज़रूरत पड़ती है:

• खाली रहने दें (रो इम्पोर्ट हो, फ़ील्ड खाली रहे)
• एक डिफ़ॉल्ट मान उपयोग करें (रो इम्पोर्ट हो, ज्ञात फॉलबैक के साथ)
• रो को रिजेक्ट करें (उस रो को फेल करें और कारण बताएं)

डिफ़ॉल्ट्स को सरल और सामान्य मामलों का सपोर्ट करना चाहिए बिना अतिरिक्त सेटअप के। उदाहरण: status = Active, country = US, owner = current user, source = "CSV import"। CSV इम्पोर्ट कॉलम-मैपिंग UI में ये डिफ़ॉल्ट्स अक्सर पहले इम्पोर्ट की सफाई और घंटों के क्लीनअप के बीच फर्क पैदा करते हैं।

एक ऐसा विवरण जो लोगों को उलझाता है वह है create बनाम update। यदि आपका इम्पोर्ट मौजूदा रिकॉर्ड्स को अपडेट कर सकता है (उदाहरण के लिए ईमेल या ID के द्वारा), तो यह स्पष्ट करें कि डिफ़ॉल्ट्स कैसे व्यवहार करेंगे:

• Create पर: डिफ़ॉल्ट्स नए रिकॉर्ड्स के लिए गायब मान भरते हैं।
• Update पर: डिफ़ॉल्ट्स आमतौर पर मौजूदा डेटा को ओवरराइट नहीं करना चाहिए जब तक उपयोगकर्ता इसमें ऑप्ट-इन न करे।

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

अंत में, डिफ़ॉल्ट मान को मैप्ड फ़ील्ड के बगल में ही दिखाएँ, सेटिंग आइकन के पीछे छिपाकर नहीं। एक छोटा इनलाइन पिल (उदाहरण: "Default: Active") और एक एक-लाइन हिन्ट ("केवल खाली होने पर उपयोग होगा") सरप्राइज़ कम करता है और सपोर्ट टिकट घटाता है।

डेटा लिखने से पहले परिणाम और त्रुटियों का पूर्वावलोकन

पूर्वावलोकन वह क्षण है जब CSV इम्पोर्ट कॉलम-मैपिंग UI भरोसा जीतता है। उपयोगकर्ताओं को कुछ भी सेव होने से पहले यह दिखना चाहिए कि क्या होगा, और उन्हें यह महसूस होना चाहिए कि समस्याएँ समझने योग्य और ठीक करने योग्य हैं।

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

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

आम कारण जिन्हें साधारण भाषा में समझाया जाना चाहिए:

• आवश्यक मान गायब है (उदाहरण: ईमेल आवश्यक है)
• गलत फॉर्मैट (उदाहरण: अमान्य तारीख फॉर्मैट: उपयोग करें YYYY-MM-DD)
• गलत प्रकार (उदाहरण: Quantity को नंबर होना चाहिए)
• अज्ञात मान (उदाहरण: Status में केवल Active, Paused, Closed होने चाहिए)
• बहुत लंबा (उदाहरण: Notes 500 कैरेक्टर तक हो सकते हैं)

फ़िल्टरिंग एक बड़ी गुणवत्ता-वृद्धि सुविधा है। "केवल त्रुटि वाली पंक्तियाँ" जैसा एक टॉगल और एक सर्च बॉक्स जोड़ें जो पूर्वावलोकन के अंदर काम करे। यह उपयोगकर्ताओं को सैकड़ों OK पंक्तियों के बीच स्क्रॉल करने की बजाय जिस पर ध्यान देना है उस पर फोकस करने में मदद करता है।

टेक्निकल शब्दावली से बचें। उपयोगकर्ता कभी "Parse exception" या "Constraint violation" न देखें। बताएं क्या गलत है, कहाँ है (रो और कॉलम), और अगला कदम क्या होना चाहिए। AppMaster में, यह तरह का पूर्वावलोकन विशेष रूप से उपयोगी है क्योंकि लोग अक्सर रियल बिज़नेस लॉजिक और वेलिडेशंस में इम्पोर्ट कर रहे होते हैं, सिर्फ़ फ्लैट टेबल में नहीं।

इम्पोर्ट के भीतर उपयोगकर्ता डेटा कैसे सुधार सकते हैं

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

ट्रबलिंग कॉलम के बगल में इनलाइन फिक्सेस से शुरू करें। अगर सिस्टम तारीखें पार्स नहीं कर पाता, तो उपयोगकर्ता को अपेक्षित तारीख फॉर्मैट चुनने दें (जैसे MM/DD/YYYY बनाम DD/MM/YYYY) और तुरंत पूर्वावलोकन फिर से चलाएँ। अगर किसी कॉलम में "Yes/No" है पर आपका फ़ील्ड true/false चाहता है, तो एक सरल कन्वर्ज़न टॉगल दें।

जिन फ़ील्ड्स के फ़िक्स्ड सेट के मान होते हैं (status, state, plan), वैल्यू मैपिंग सबसे ज़्यादा समय बचाती है। जब इम्पोर्ट में "NY" दिखे पर आपका ऐप "New York" स्टोर करता है, उपयोगकर्ता को एक बार मैप करने और सभी पंक्तियों पर लागू करने का विकल्प होना चाहिए। वही तरीका केसिंग और नेमिंग में भी मदद करता है, जैसे "active", "Active", और "ACTIVE" को एक ही अनुमत मान में बदलना।

क्विक एक्शन्स सामान्य गंदगी जल्दी साफ़ करने में मदद करते हैं:

• अग्रणी और पीछे के स्पेस ट्रिम करें
• खाली जगहों को डिफ़ॉल्ट से बदलें (जैसे "Unknown")
• हजारों विभाजक हटाएँ ("1,200" -> "1200")
• फोन नंबर सामान्य करें (सिर्फ डिजिट रखें)
• नामों के लिए टेक्स्ट को Title Case में बदलें

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

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

एक सरल उदाहरण: यदि 600 पंक्तियों में "CA " के साथ ट्रेलिंग स्पेस है, एक क्लिक में उसे साफ़ करें और आपकी वैलिडेशन पास हो जाएगी बिना फ़ाइल को फिर से एक्सपोर्ट किए।

एक सरल स्टेप-बाय-स्टेप इम्पोर्ट फ्लो

एक अच्छी CSV इम्पोर्ट कॉलम-मैपिंग UI शांत महसूस कराती है क्योंकि यह काम को कुछ छोटे निर्णयों में तोड़ देती है, एक फिक्स्ड ऑर्डर में। उपयोगकर्ताओं को हमेशा पता होना चाहिए कि अगला क्या होगा, और उनके डेटा के साथ क्या होगा।

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

फिर पूछें कि इम्पोर्ट कैसे व्यवहार करे। कुछ उपयोगकर्ता नए रिकॉर्ड बना रहे होते हैं, कुछ मौजूदा को अपडेट कर रहे होते हैं, और कई को upsert चाहिए। अगर update या upsert चुना गया है, तो एक आइडेंटिफ़ायर (उदाहरण: email, external ID, या order number) ज़रूरी करें और चेतावनी दिखाएँ अगर आइडेंटिफायर कॉलम में ब्लैंक्स या डुप्लिकेट्स हैं।

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

एक सरल फ्लो कुछ इस तरह दिखता है:

• फ़ाइल अपलोड करें और कुछ रो का पूर्वावलोकन देखें
• मोड चुनें: create, update by key, या upsert (और की चुनें)
• मैपिंग और डिफ़ॉल्ट कन्फर्म करें, फिर validate करें
• त्रुटियों की समीक्षा करें और उन्हें ठीक करें (या सिर्फ़ एरर रो एक्सपोर्ट करें)
• इम्पोर्ट चलाएँ और एक समापन सारांश दिखाएँ

एरर रिव्यू स्टेप पर, उपयोगकर्ता को आगे बढ़ाते रहें। एरर प्रकार के हिसाब से काउंट दिखाएँ, केवल खराब रो फ़िल्टर करने दें, और अगला कार्य स्पष्ट बनायें: इन-प्लेस ठीक करें, किसी रो को इग्नोर करें, या प्रॉब्लम रो डाउनलोड करके एडिट कर फिर से अपलोड करें।

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

बचने योग्य सामान्य जाल

एक कॉलम-मैपिंग स्क्रीन "हो गया" तब लग सकती है जब उपयोगकर्ता फ़ील्ड्स मैप कर पाते हैं और इम्पोर्ट पर क्लिक कर देते हैं। असली समस्याएँ तब सामने आती हैं जब डेटा सिस्टम में उतर जाता है: डुप्लिकेट्स, मौन परिवर्तन, और ऐसी त्रुटियाँ जिन्हें कोई ठीक नहीं कर सकता।

एक क्लासिक जाल है उपयोगकर्ताओं को अपडेट-स्टाइल इम्पोर्ट चलाने देना बिना किसी यूनिक आइडेंटिफ़ायर के। अगर उपयोगकर्ता कुछ भी मैप नहीं कर पाते जैसे Customer ID, Email, या कोई अन्य गारंटीड-यूनिक फ़ील्ड, तो वे मौजूदा रिकॉर्ड्स को विश्वसनीय तरीके से अपडेट नहीं कर सकते। परिणाम अक्सर ऐसे डुप्लिकेट रिकॉर्ड होते हैं जो सही लगते हैं, बस दोहराए हुए। अगर आइडेंटिफ़ायर गायब है, तो UI को इसे साफ़ शब्दों में बताना चाहिए और विकल्प देना चाहिए: "नए रिकॉर्ड के रूप में इम्पोर्ट करें" या "रुकें और ID जोड़ें।"

एक और सूक्ष्म समस्या मौन प्रकार बदलना है। "00123" जैसा मान असल में एक कोड हो सकता है, नंबर नहीं। अगर इम्पोर्ट इसे 123 में बदल देता है, तो आप आगे के मिलानों के लिए लीडिंग ज़ीरो खो देते हैं और मैच टूट जाते हैं। "नंबर-जैसा" स्ट्रिंग्स के साथ सावधानी बरतें, खासकर ZIP/Postal कोड्स, SKUs, और अकाउंट कोड्स के लिए। अगर प्रकार बदलना अनिवार्य है, तो पूर्वावलोकन में पहले और बाद दिखाएँ।

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

• ब्लॉकिंग एरर (इम्पोर्ट के लिए ठीक करना ज़रूरी)
• चेतावनियाँ (इम्पोर्ट हो सकती है, पर उपयोगकर्ता को समीक्षा करनी चाहिए)
• ऑटो-फिक्सेस (स्पेस हटाना, केस सामान्य करना) जो पूर्वावलोकन में दिखें

एरर मेसेज अक्सर बेकार बन जाते हैं क्योंकि वे ठीक सेल नहीं बताते। फीडबैक हमेशा किसी विशेष रो और कॉलम से जुड़ा होना चाहिए, और मूल मान शामिल होना चाहिए। "Row 42, Email: 'bob@' एक वैध ईमेल नहीं है" इससे बेहतर है कि सिर्फ़ "Invalid data found." कहना।

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

उपयोगकर्ता के इम्पोर्ट पर क्लिक करने से ठीक पहले की त्वरित जाँचें

किसी के क्लिक करने से ठीक पहले उनका एक साधारण सवाल होता है: "क्या मैं अपना डेटा बिगाड़ने वाला हूँ?" एक अच्छा CSV इम्पोर्ट कॉलम-मैपिंग UI उस प्रश्न का उत्तर देता है एक स्पष्ट, भरोसा बढ़ाने वाले चेकलिस्ट से।

एक छोटा, वास्तविक पूर्वावलोकन दिखाना शुरू करें। 10–20 रो का सैंपल ज़्यादातर लोगों के लिए पर्याप्त है ताकि वे स्पष्ट समस्याएँ जैसे शिफ्ट हुए कॉलम, अजीब तारीख फॉर्मैट, या अतिरिक्त स्पेस देख सकें। पूर्वावलोकन को करंट मैपिंग लागू करके दिखाना चाहिए, ना कि रॉ CSV, ताकि उपयोगकर्ता वही देखे जो लिखा जाएगा।

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

खाली सेल्स के लिए एक स्पष्ट-साधारण नियम चाहिए। उपयोगकर्ताओं को बताएं कि खाली किस तरह ट्रीट होंगे: खाली बनें रहेंगे, (अपडेट में) मौजूदा मान रहेंगे, या किसी डिफ़ॉल्ट से भरे जाएंगे। मैपिंग रो में छोटा टेक्स्ट जैसे "Blank = keep existing value" बहुत सारे गलत इम्पोर्ट रोकता है।

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

यहाँ एक छोटा प्री-इम्पोर्ट चेकलिस्ट है जिसे आप अंतिम बटन के ऊपर रख सकते हैं:

• पूर्वावलोकन वर्तमान मैपिंग लागू करके सैंपल रो दिखा रहा है
• सभी आवश्यक फ़ील्ड्स मैप्ड हैं या उनका डिफ़ॉल्ट सेट है
• क्रिएट और अपडेट दोनों के लिए खाली-सेल व्यवहार स्पष्ट है
• आप सिर्फ़ समस्याग्रस्त पंक्तियों को फ़िल्टर कर समीक्षा कर सकते हैं
• समरी में create vs update vs skip के काउंट और एरर काउंट दिख रहे हैं

अगर आप AppMaster में बना रहे हैं, तो इन जाँचों को "अंतिम सुरक्षा स्क्रीन" समझें जो बैकएंड कुछ भी लिखने से पहले दिखाई दे। यहां एक ख़राब इम्पोर्ट रोकना बाद में हजारों रिकॉर्ड साफ़ करने से सस्ता होता है।

उदाहरण परिदृश्य: स्प्रेडशीट से कस्टमर्स इम्पोर्ट करना

एक सपोर्ट लीड स्प्रेडशीट से एक कस्टमर लिस्ट एक्सपोर्ट करता है और उसे सरल CRM में लोड करना चाहता है। CSV कॉलम हैं: Name, Email, Phone, Status, और Signup Date।

CSV इम्पोर्ट कॉलम-मैपिंग UI पर वे कॉलम्स इस तरह मैप करते हैं:

• Name -> Customer name
• Email -> Email (आवश्यक)
• Phone -> Phone (वैकल्पिक)
• Status -> Status (ड्रॉपडाउन)
• Signup Date -> Signup date (तारीख)

कुछ समस्याएँ तुरंत दिखती हैं। कुछ पंक्तियों में Email नहीं है। Status वैल्यू असंगत हैं (Active, ACTIVE, actv)। Signup Date मिश्रित है: कुछ रो 2025-01-03 का उपयोग करते हैं, कुछ 01/03/2025, और कुछ में 3 Jan 2025 जैसा फॉर्मैट है।

पूरी फ़ाइल ठीक करने के लिए उपयोगकर्ता को मजबूर करने के बजाय, मैपिंग स्टेप उन्हें सुरक्षित डिफ़ॉल्ट्स और नियम सेट करने देता है। वे Status का डिफ़ॉल्ट "Active" चुनते हैं केवल तब जब कॉलम खाली हो, न कि जब उस में कोई मान हो। Signup Date के लिए वे अपेक्षित फॉर्मैट चुनते हैं (उदाहरण: YYYY-MM-DD) और कहते हैं कि अन्य फॉर्मैट्स को एरर माना जाए।

पूर्वावलोकन अब निर्णय का बिंदु बन जाता है। यह दिखा सकता है:

• 12 पंक्तियाँ ब्लॉक: Email गायब है
• 7 पंक्तियाँ फ़्लैग्ड: unknown Status value "actv"
• 5 पंक्तियाँ फ़्लैग्ड: अमान्य तारीख फॉर्मैट

पूर्वावलोकन से उपयोगकर्ता जल्दी समस्याएँ ठीक कर लेते हैं बिना अनुमान लगाए। वे "actv" को bulk में "Active" से मैप कर देते हैं, और पांच ख़राब तारीखें इन-प्लेस ठीक कर देते हैं। गायब ईमेल के लिए वे या तो उन पंक्तियों को स्किप कर सकते हैं या इम्पोर्ट रोककर टीम से भरवाने के लिए कह सकते हैं।

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

अगले कदम: इम्पोर्ट UI रिलीज़ करें और सुरक्षित रखें

अपनी पहली रिलीज़ को एक नियंत्रित प्रयोग की तरह मानें। एक छोटी टेस्ट फ़ाइल (10–50 रो) से शुरू करें और पूरा फ्लो end-to-end चलाएँ: मैपिंग, डिफ़ॉल्ट्स, पूर्वावलोकन, और फाइनल राइट। अगर परिणाम सही दिखते हैं, तो उपयोगकर्ताओं को मैपिंग सेव करने दें ताकि अगला इम्पोर्ट तेज़ और अधिक संगत हो। एक सेव्ड मैपिंग सुरक्षा जाल भी है क्योंकि यह "वन-ऑफ" क्रिएटिव मैच्स को कम कर देती है।

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

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

क्या रिकॉर्ड करें और क्या दिखायें

डिबग करने के लिए पर्याप्त डिटेल कैप्चर करें बिना लोगों को ओवरवेल्म किए। एक अच्छा पोस्ट-इम्पोर्ट समरी शामिल करता है:

• प्रोसेस्ड, बनाए गए, अपडेट हुए, और स्किप किए गए रो
• एरर काउंट के साथ एक डाउनलोड करने योग्य या कॉपी करने योग्य एरर रिपोर्ट (रो नंबर, कॉलम, संदेश)
• किस सेव्ड मैपिंग और डिफ़ॉल्ट्स का उपयोग हुआ इसकी नोट
• समय (शुरुआत, समाप्ति) और किसने चलाया
• बदले गए रिकॉर्ड्स पर फ़िल्टर करने का त्वरित लिंक (अगर आपका ऐप इसका समर्थन करता है)

अगर आप AppMaster में बना रहे हैं, तो आप Data Designer में डेटा मॉडल कर सकते हैं, विज़ुअल UI बिल्डर्स से मैपिंग और पूर्वावलोकन स्क्रीन बना सकते हैं, और बिज़नेस प्रोसेस में वेलिडेशन लागू कर सकते हैं इससे पहले कि कुछ भी PostgreSQL में लिखा जाए। उस विभाजन से "पूर्वावलोकन" को सुरक्षित और "इम्पोर्ट" को सख़्त रखना आसान होता है।

अंत में, लॉन्च से पहले एक और गार्डरेल जोड़ें: हर एनवायरनमेंट में एक टेस्ट इम्पोर्ट आवश्यक करें (पहले staging, फिर production) और इम्पोर्ट्स को किसी भूमिका या परमिशन के पीछे रखें। इससे फीचर उपयोगी बना रहेगा बिना रिस्की बनाए।