CSV ইম্পোর্ট কলাম ম্যাপিং UI: নিরাপদ মিল, ডিফল্ট মান, প্রিভিউ

কেন CSV ইম্পোর্ট হতাশাজনক লাগে

অধিকাংশ মানুষ একটি CSV ইম্পোর্টের দিকে একটাই আশা নিয়ে এগোয়: “শুধু আমার স্প্রেডশীট অ্যাপে নেমে আসুক।” তারপর প্রথম স্ক্রিনে এমন সিদ্ধান্ত চাইতে থাকে যা তারা বুঝতে পারে না, এবং ইম্পোর্ট এমন কারণে ব্যর্থ হয় যা র‍্যান্ডম মনে হয়।

CSV ফাইলগুলো অনেক সময় যতটা পরিষ্কার দেখায় তার চেয়েও নোংরা থাকে। হেডারগুলো অনুপস্থিত থাকতে পারে, আপনার ফিল্ডগুলোর চেয়ে অন্যভাবে লেখা থাকতে পারে, বা ডুপ্লিকেট হতে পারে ("Email", "email", "Email Address"). তারিখগুলো অদ্ভুত ফরম্যাটে থাকতে পারে, ফোন নাম্বারগুলোর শূন্য শুরু হারিয়ে যেতে পারে, এবং ঠিকানার ভেতরে কমা কলাম ভেঙে দিতে পারে। এমনকি “পরিষ্কার” এক্সপোর্টেও নোট, অভ্যন্তরীণ ID বা খালি ট্রেইলিং কলামের মত অতিরিক্ত কলাম থাকতে পারে।

ভয় সত্যিই আছে: যদি আপনি ভুল অনুমান করেন, তাহলে এটি কি ভালো ডেটা ওভাররাইট করবে, শত শত ভাঙা রেকর্ড তৈরি করবে, নাকি সিস্টেম জুড়ে আবর্জনা ছড়িয়ে দেবে? একটি ভাল CSV ইম্পোর্ট কলাম ম্যাপিং UI এই উদ্বেগ কমায় কারণ এটি কোন কিছু লেখার আগে দেখায় কি হবে।

"ম্যাপিং" মানে হলো মিল করানো। অর্থাৎ: CSV-র এই কলামটা আপনার অ্যাপের ওই ফিল্ডে যাবে। উদাহরণ: CSV কলাম "Company" মাপ হবে ফিল্ড "Account name"-এ, আর "Start Date" মেপ হবে "Customer since"-এ। তাত্ত্বিকভাবে সহজ, কিন্তু নামগুলো মিলে না গেলে ভুল হওয়া সহজ।

একটি নিরাপদ ইম্পোর্ট স্পষ্ট প্রত্যাশা সেট করে এবং একটি পূর্বনির্ধারিত ক্রম অনুসরণ করে:

• কলামগুলোকে ফিল্ডে ম্যাচ করা (ম্যাপিং)
• যখন ডেটা অনুপস্থিত থাকবে তখন কী করা হবে ঠিক করা (ডিফল্ট)
• সমস্যাগুলো পরীক্ষা করা (ভ্যালিডেশন)
• ফলাফল দেখানো (প্রিভিউ)
• তারপরই রেকর্ড লেখা

যখন ব্যবহারকারীরা ওই ক্রমটা বুঝে, ইম্পোর্ট আর ফাঁদের মতো লাগে না। এটি একটি গাইডেড চেকলিস্ট হয়ে ওঠে: ম্যাচগুলো করুন, ফাঁকগুলো পূরণ করুন, যে ত্রুটিগুলো আপনি দেখতে পাচ্ছেন সেগুলো ঠিক করুন, এবং আত্মবিশ্বাসের সাথে ইম্পোর্ট করুন।

একটি ভাল কলাম-ম্যাপিং স্ক্রিনকে কি করতে হয়

CSV ইম্পোর্ট কলাম-ম্যাপিং UI-র একটাই কাজ: কিছু লেখার আগে কি ঘটতে যাচ্ছে তা পরিষ্কারভাবে বোঝানো। ব্যবহারকারীদের আন্দাজ করতে হবে না যে আপনি কি নতুন রেকর্ড তৈরি করছেন, বিদ্যমানগুলো আপডেট করছেন, নাকি সারি বাদ দিচ্ছেন।

স্ক্রিনটি এই প্রশ্নগুলোর পরিষ্কার উত্তর দিতে হবে:

• কী তৈরি হবে (নতুন রেকর্ড) এবং কোন টেবিল বা অবজেক্টে
• কী আপডেট হবে, এবং কোন ফিল্ডটি ম্যাচ খুঁজতে ব্যবহার হচ্ছে (যেমন Email বা external ID)
• কী বাদ পড়বে, এবং কেন (প্রয়োজনীয় ফিল্ড অনুপস্থিত, ডুপ্লিকেট, অবৈধ মান)
• আপলোডকৃত ফাইল থেকে প্রকৃত কাউন্ট ব্যবহার করে প্রতিটি গ্রুপে কত সারি প্রভাবিত হচ্ছে
• যদি কোনো মান খালি থাকে সিস্টেম কী করবে (ফাঁকা রাখবে, ডিফল্ট ব্যবহার করবে, বিদ্যমান মান রাখবে)

প্রয়োজনীয় ফিল্ডগুলোর বিশেষ হ্যান্ডেলিং দরকার। এগুলোকে উপরে দেখান, required হিসেবে চিহ্নিত করুন, এবং ব্যবহারকারী প্রতিটি প্রয়োজনীয় ফিল্ড ম্যাপ না করে বা একটি স্পষ্ট ডিফল্ট না দিলে ম্যাপিং শেষ হতে দিবেন না। ঐচ্ছিক ফিল্ডগুলো অনম্যাপ করা যেতে পারে, কিন্তু UI-তে ব্যবহারকারী কি উপেক্ষা করছে তা জানাতে হবে।

মান ছোঁড়া ছাড়াও ব্যবহারকারীরা সাধারণ ক্লিনআপ আশা করে। ম্যাপিং চালু থাকা অবস্থায়ই সহজ রূপান্তর দিতে বলুন, যেমন অতিরিক্ত স্পেস ট্রিম করা, নম্বর ফরম্যাট কনভার্ট করা, এবং একটি তারিখ ফরম্যাট বেছে নেওয়া। উদাহরণস্বরূপ, যদি CSV-তে " New York " থাকে, একটি trim অপশন প্রিভিউতে দেখাবে এটি কিভাবে "New York" হবে।

প্রতিটি ইস্যুই ইম্পোর্ট বন্ধ করা উচিত এমন নয়। সমস্যাগুলোকে ব্লক এবং ওয়ার্নিং এ বিভক্ত করুন, এবং পার্থক্য সোজাসাপ্টা কথায় বুঝিয়ে বলুন।

• ব্লক যখন একটি প্রয়োজনীয় ফিল্ড মিসিং, একটি তারিখ পার্স হচ্ছে না, বা আপডেট ম্যাচ কী খালি
• ওয়ার্ন যখন একটি ফোন নাম্বার অদ্ভুত ফরম্যাটে আছে, একটি মান কাটানো হচ্ছে, বা একটি অজানা ফিল্ড থাকবে যে উপেক্ষা করা হবে
• ওয়ার্ন থাকলে ইম্পোর্ট চলতে দিতে হবে, কিন্তু কত সারি প্রভাবিত হবে তা দেখান

এই মৌলিকগুলো সঠিক করলে বাকি ইম্পোর্ট ফ্লো অনেক শান্ত হয়: ব্যবহারকারীরা নিয়ন্ত্রণে থাকে, এবং “কেন এটি ভুলভাবে ইম্পোর্ট হলো?” ধরনের সাপোর্ট টিকিট কম আসে।

ব্যবহারকারীদের CSV কলামগুলো ফিল্ডের সাথে মিল করাতে সাহায্য করা

ভালো CSV ইম্পোর্ট কলাম-ম্যাপিং UI যেন একটি সহায়ক অ্যাসিস্ট্যান্টের মতো লাগে, ধাঁধা নয়। প্রথম সারিটি হেডার হিসেবে পড়ে নিয়ে তৎক্ষণাৎ সুপারিশ করা শুরু করুন। নামের সাদৃশ্য ("email" -> "Email") এবং একটি ছোট সিনোনিম তালিকা ("Phone" বনাম "Mobile", "Zip" বনাম "Postal code", "Company" বনাম "Organization") ব্যবহার করুন।

সাজেশনগুলো সবচেয়ে ভাল কাজ করে যখন সেগুলো শান্ত ও স্পষ্ট। মিলগুলোকে exact, likely, অথবা unsure হিসাবে চিহ্নিত করুন। টীকা সাবলীল রাখুন (একটি ছোট লেবেল বা আইকন), যাতে ব্যবহারকারীরা দ্রুত স্ক্যান করতে পারে এবং বিরক্ত না হয়।

ব্যবহারকারীদের সহজ উপায় দিন যে তারা যেকোনো কিছু ওভাররাইড করতে পারে। একটি dropdown ঠিক আছে, কিন্তু একটি সার্চ বক্স যোগ করুন যাতে তারা "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-তে খালি" এবং "ফিল্ড অন্তর্ভুক্ত করা হয়নি" আলাদা ভাবে বিবেচনা করুন। যদি ব্যবহারকারী ফিল্ডটি ম্যাপ করেছে এবং "Leave empty" পছন্দ করেছে, তারা সম্ভবত মানকে "ক্লিয়ার" করতে চাইছে। যদি তারা ফিল্ডটি মোটেই ম্যাপ করেনি, তারা সাধারণত চায় সেটি অটাচ করা না হোক।

অবশেষে, ডিফল্ট মানটি ম্যাপ করা ফিল্ডের ঠিক পাশে দেখান, সেটিং আইকনের পেছনে লুকিয়ে না রাখুন। একটি ছোট ইনলাইন পিল (উদাহরণ: "Default: Active") এবং এক-লাইনের হিন্ট ("শুধুমাত্র খালি থাকলে ব্যবহৃত") বিস্ময় প্রতিরোধ করে এবং সাপোর্ট টিকিট কমায়।

ডেটা লেখার আগে ফলাফল এবং ত্রুটির প্রিভিউ করা

প্রিভিউই সেই মুহূর্ত যখন একটি CSV ইম্পোর্ট কলাম-ম্যাপিং UI বিশ্বাস অর্জন করে। ব্যবহারকারীদের কিছু লেখার আগে কি হবে তা দেখা উচিত, এবং তাদের মনে হওয়া উচিত যে সমস্যাগুলো বোঝা যায় এবং ঠিক করা যায়।

একটি ছোট, দ্রুত স্যাম্পল প্রিভিউ দিয়ে শুরু করুন (উদাহরণ: প্রথম 20–50 সারি) এবং পুরো ফাইলের জন্য একটি সহজ কাউন্ট সারাংশ দিন। সারাংশটি মানুষ যে প্রশ্নগুলো আসে সেগুলো উত্তর দেবে: কত সারি তৈরি বা আপডেট হবে, কতটির সমস্যা আছে, এবং কতটি বাদ দেওয়া হবে।

ত্রুটিগুলো ভিজ্যুয়াল এবং নির্দিষ্ট করুন। নির্দিষ্ট যে সেলগুলো ব্যর্থ হবে সেগুলো হাইলাইট করুন এবং সেলের পাশে বা সাইড প্যানেলে একটি সংক্ষিপ্ত কারণ দেখান। যদি একটি সারিতে একাধিক সমস্যা থাকে, প্রথমটি স্পষ্টভাবে দেখান এবং ব্যবহারকারী বাকি দেখতে এক্সপ্যান্ড করতে পারে।

সাধারণ কারণগুলো সহজ ভাষায় ব্যাখ্যা করুন:

• প্রয়োজনীয় মান নেই (উদাহরণ: Email প্রয়োজন)
• ভুল ফরম্যাট (উদাহরণ: অবৈধ তারিখ ফরম্যাট: YYYY-MM-DD ব্যবহার করুন)
• ভুল টাইপ (উদাহরণ: Quantity অবশ্যই একটি সংখ্যা হতে হবে)
• অজানা মান (উদাহরণ: Status অবশ্যই Active, Paused, Closed-এর একটি হতে হবে)
• খুব লম্বা (উদাহরণ: Notes সর্বোচ্চ 500 ক্যারেক্টার হতে পারে)

ফিল্টারিং একটি বড় মান-সম্মত ফিচার। একটি "শুধু ত্রুটিযুক্ত সারি" টগল এবং একটী সার্চ বক্স যোগ করুন যা প্রিভিউয়ের মধ্যে কাজ করে। এটি ব্যবহারকারীদের শত শত ঠিক সারির মাঝে না গিয়ে যা প্রয়োজন তা ফোকাস করতে সাহায্য করে।

প্রযুক্তিগত শব্দ ব্যবহার থেকে বিরত থাকুন। ব্যবহারকারীরা কখনোই "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-এর আশা নয়।

সাধারণ ফাঁদগুলো থেকে বাঁচুন

একটি কলাম-ম্যাপিং স্ক্রিন তখনই "সম্পন্ন" মনে হতে পারে যখন ব্যবহারকারীরা ফিল্ড মিলিয়ে Import ক্লিক করতে পারে। প্রকৃত সমস্যা তখনই দেখা দেয় যখন ডেটা সিস্টেমে নেমে আসে: ডুপ্লিকেট, চুপ করে পরিবর্তন, এবং ত্রুটি যা কেউ ঠিক করতে পারে না।

ক্লাসিক একটি ফাঁদ হলো ব্যবহারকারীদের আপডেট স্টাইল ইম্পোর্ট চালাতে দেয়া যখন একটি ইউনিক আইডেন্টিফায়ার নেই। যদি ব্যবহারকারীরা Customer ID, Email, বা অন্য কোনো গ্যারান্টি-যুক্ত ইউনিক ফিল্ড ম্যাপ করতে না পারে, তারা বিদ্যমান রেকর্ড নির্ভরযোগ্যভাবে আপডেট করতে পারবে না। ফলশ্রুতিতে প্রায়ই একেকটি রেকর্ড ডুপ্লিকেট হয়ে যায়। যদি একটি আইডেন্টিফায়ার অনুপস্থিত থাকে, UI-তে এটি স্পষ্টভাবে বলুন এবং একটি পছন্দ দিন: "নতুন রেকর্ড হিসেবে ইম্পোর্ট করুন" বা "বন্ধ করুন এবং একটি ID যোগ করুন"।

আরেকটি সূক্ষ্ম সমস্যা হলো নীরব টাইপ কনভার্শন। "00123" এর মতো একটি মান আসলে একটি কোড হতে পারে, সংখ্যা নয়। যদি ইম্পোর্ট এটিকে 123-এ রূপান্তর করে, আপনি লিডিং জিরো হারাবেন এবং পরে ম্যাচ ভাঙবে। ZIP/postal কোড, SKU, এবং account code-এর জন্য "নম্বার-লুকিং" স্ট্রিংগুলো সাবধানে আচরণ করুন। যদি টাইপ পরিবর্তন আবশ্যক হয়, প্রিভিউতে আগে/পরে দেখান।

ভ্যালিডেশন দুই বিপরীত উপায়ে ব্যর্থ হতে পারে। বেশি কড়া হলে আপনি মারাত্মক নয় এমন সারি ব্লক করবেন (যেমন একটি ঐচ্ছিক ফোন নম্বর মিসিং)। খুব ঢিলা হলে আপনি আবর্জনা তৈরি করবেন (খালি নাম, অবৈধ ইমেইল, বা অর্থবহ নয় এমন তারিখ)। একটি ভাল পন্থা হল আলাদা করা:

• ব্লকিং এরর (ইম্পোর্টের জন্য ঠিক করা বাধ্যতামূলক)
• ওয়ার্নিং (ইম্পোর্ট করা যাবে, কিন্তু ব্যবহারকারী পর্যালোচনা করা উচিত)
• অটো-ফিক্স (স্পেস ট্রিম, কেস স্বাভাবিককরণ) যা প্রিভিউতে দৃশ্যমান

ত্রুটি বার্তাগুলো প্রায় বেকার হয়ে পড়ে কারণ সেগুলো নির্দিষ্ট সেলকেই নির্দেশ করে না। সবসময় প্রতিক্রিয়াকে একটি নির্দিষ্ট সারি এবং কলামের সাথে যুক্ত করুন, এবং মূল মান দেখান। "Row 42, Email: 'bob@' is not a valid email" কথাটাই "Invalid data found"-এর চেয়ে অনেক ভাল।

অবশেষে, শেষ কনফার্মেশনটা অস্পষ্ট কইরো না। ব্যবহারকারীরা দেখতে চায় কি হবে: কতটি তৈরি হবে, কতটি আপডেট হবে, এবং কতটি বাদ পড়বে। যদি আপডেট জড়িত থাকে, যে আইডেন্টিফায়ার ফিল্ডে ম্যাচ করবেন সেটা দেখান যাতে মানুষ খারাপ ম্যাপিং ধরে ফেলতে পারে আগে কোনো ডেটা ওভাররাইট না হয়।

ব্যবহারকারী Import ক্লিক করার ঠিক আগের দ্রুত চেকলিস্ট

কোনো ব্যবহারকারী Import ক্লিক করার ঠিক আগেই একটাই প্রশ্ন করে: "আমি কি আমার ডেটা নষ্ট করতে যাচ্ছি?" একটি ভাল CSV ইম্পোর্ট কলাম-ম্যাপিং UI সেই প্রশ্নের উত্তর দেয় একটি পরিষ্কার, নিস্তেজ, আত্মবিশ্বাস তৈরি করা চেকলিস্ট দিয়ে।

একটি ছোট, বাস্তব প্রিভিউ দেখান। 10–20 সারি স্যাম্পল বেশিরভাগ মানুষের জন্য যথেষ্ট যাতে তারা ঘর বদলে যাওয়া কলাম, অদ্ভুত তারিখ ফরম্যাট, বা অতিরিক্ত স্পেস মত অসঙ্গতি শনাক্ত করতে পারে। প্রিভিউটি বর্তমান ম্যাপিং প্রতিফলিত করবে, কাঁচা CSV নয়, যাতে ব্যবহারকারী যা লেখা হবে ঠিক তাও দেখতে পায়।

পরেরটি—প্রয়োজনীয় ফিল্ডগুলোকে নজরে আনা অসম্ভব করুন। যদি একটি প্রয়োজনীয় ফিল্ড ম্যাপ না থাকে, একটি সিদ্ধান্ত জোর করে নিন: এটিকে ম্যাপ করুন, একটি ডিফল্ট সেট করুন, বা বন্ধ করুন। ব্যবহারকারীরা কেবল ব্যর্থ ইম্পোর্টের পরেই কখনো কখনো আবিষ্কার করুক না যে প্রয়োজনীয় মান মিস ছিল।

খালি সেলগুলোর জন্য একটি সহজ-ভাষার নিয়ম দিন। ব্যবহারকারীদের বলুন খালি গুলো ফাঁকা থাকবে, বিদ্যমান মান রাখবে (আপডেট ক্ষেত্রে), বা ডিফল্ট ট্রিগার করবে কিনা। ম্যাপিং সারির পাশে ছোট টেক্সট যেমন "Blank = keep existing value" অনেক খারাপ ইম্পোর্ট প্রতিরোধ করে।

অবশেষে, ব্যবহারকারীদের সমস্যা উপর ফোকাস করতে দিন, নিখুঁততায় নয়। যদি সমস্যা থাকে, একটি ভিউ দিন যা শুধুই ত্রুটিযুক্ত বা ওয়ার্নিং-যুক্ত সারিগুলো দেখায়, সাথে সারির পাশে কারণ। এতে ঠিক করা গ্রহণযোগ্য মনে হয়।

এখানে একটি দ্রুত পূর্ব-ইম্পোর্ট চেকলিস্ট যা আপনি চূড়ান্ত বাটনের উপরে রাখতে পারেন:

• প্রিভিউ বর্তমান ম্যাপিং প্রয়োগ করে স্যাম্পল সারি দেখায়
• সকল প্রয়োজনীয় ফিল্ড ম্যাপ করা আছে বা ডিফল্ট আছে
• create এবং update-এ খালি সেল আচরণ স্পষ্টভাবে বলা আছে
• আপনি শুধুই সমস্যা-যুক্ত সারিগুলোতে ফিল্টার করতে ও দ্রুত পর্যালোচনা করতে পারেন
• সারাংশে create বনাম update বনাম skip-এর কাউন্ট (এবং ত্রুটি কাউন্ট) দেখানো আছে

AppMaster-এ যদি আপনি এটি তৈরি করেন, তবে এই চেকগুলোকে "শেষ নিরাপত্তার স্ক্রিন" হিসেবে ভাবুন আপনার ব্যাকএন্ড কিছু লেখার আগে। খারাপ ইম্পোর্ট এখানে বন্ধ করা হাজার হাজার রেকর্ড পরিস্কার করার চাইতে সস্তা।

উদাহরণ পরিস্থিতি: স্প্রেডশীট থেকে কাস্টমার ইম্পোর্ট করা

একজন সাপোর্ট লিড একটি কাস্টমার তালিকা স্প্রেডশীট থেকে এক্সপোর্ট করে এবং সেটি একটি সরল CRM-এ লোড করতে চান। CSV-তে কলাম আছে: Name, Email, Phone, Status, এবং Signup Date।

CSV ইম্পোর্ট কলাম-ম্যাপিং UI-তে তারা কলামগুলো ফিল্ডে মিলায় এইভাবে:

• Name -> Customer name
• Email -> Email (required)
• Phone -> Phone (optional)
• Status -> Status (dropdown)
• Signup Date -> Signup date (date)

কয়েকটি ইস্যু তৎক্ষণাৎ দেখায়। কিছু সারিতে Email নেই। Status মানগুলো inconsistent (Active, ACTIVE, actv)। Signup Date মিশ্রিত ফরম্যাটে আছে: কিছু 2025-01-03, কিছু 01/03/2025, এবং কয়েকটিতে 3 Jan 2025।

সারা ফাইলটাকে নিজে থেকেই ঠিক করতে বাধ্য না করে, ম্যাপিং ধাপ ব্যবহারকারীদের নিরাপদ ডিফল্ট এবং নিয়মগুলো ঠিক করতে দেয়। তারা Status-এর জন্য ডিফল্ট "Active" বেছে নেয় কেবল তখনই যখন কলামটি খালি, না যখন এতে ইতিমধ্যেই মান আছে। Signup Date-এর জন্য তারা প্রত্যাশিত ফরম্যাট বেছে নেয় (উদাহরণ: YYYY-MM-DD) এবং অন্য ফরম্যাটগুলোকে ত্রুটি হিসেবে ধরার নির্দেশ দেয়।

প্রিভিউ এখন সিদ্ধান্তের বিন্দু। এটি দেখাতে পারে:

• 12 সারি ব্লক: Email অনুপস্থিত
• 7 সারি ফ্ল্যাগ: অজানা Status মান "actv"
• 5 সারি ফ্ল্যাগ: অবৈধ তারিখ ফরম্যাট

প্রিভিউ থেকে ব্যবহারকারী দ্রুত অনুমান না করে সমস্যাগুলো ঠিক করে। তারা bulk-এ "actv" কে "Active"-এ ম্যাপ করে, এবং পাঁচটি ভুল তারিখ ইন-প্লেস ঠিক করে। মিসিং ইমেইলগুলোর জন্য তারা সেই সারিগুলো স্কিপ করতে পারে বা ইম্পোর্ট বন্ধ করে টিমকে ভরাতে বলবে।

AppMaster-এর মতো টুলগুলো ম্যাপিং স্ক্রিনকে স্পষ্ট ভ্যালিডেশন এবং এমন একটি প্রিভিউর সাথে জোড়া দিলে এটি স্বাভাবিক মনে করিয়ে দিতে পারে, ফলে ব্যবহারকারী যেকোনো কিছু লেখার আগেই ইম্পোর্টে বিশ্বাস রাখে।

পরবর্তী ধাপ: ইম্পোর্ট UI লঞ্চ করুন এবং সেটিকে নিরাপদ রাখুন

আপনার প্রথম রিলিজকে একটি নিয়ন্ত্রিত পরীক্ষার মতো ভাবুন। একটি ছোট টেস্ট ফাইল (10–50 সারি) দিয়ে পুরো ফ্লো end-to-end চালান: ম্যাপিং, ডিফল্ট, প্রিভিউ, এবং চূড়ান্ত লেখা। ফলাফল ঠিক থাকলে ব্যবহারকারীদের ম্যাপিং save করতে দিন যাতে পরের ইম্পোর্ট দ্রুত এবং ধারাবাহিক হয়। একটি সংরক্ষিত ম্যাপিংও একটি নিরাপত্তা নেট কারণ এটি এক-অফ ক্রিয়েটিভ ম্যাচ কমায়।

CSV ইম্পোর্ট কলাম-ম্যাপিং UI-কে যেখানে তা স্বাভাবিকভাবে থাকা উচিত সেখানে রাখুন: একজন অ্যাডমিন প্যানেল বা যে অন্তর্ভুক্ত টুলটি ডেটা নিয়ন্ত্রণ করে সেখানে। উদাহরণস্বরূপ, একটি সাপোর্ট লিডের আলাদা পারমিশন বা আলাদা সিস্টেম ছাড়া কাস্টমার যোগ করার প্রয়োজন থাকা উচিত না। এটা সেই লিস্ট ভিউর কাছে রাখুন যেখানে তারা ফলাফল নিশ্চিত করার জন্য তৎক্ষণাৎ যাচাই করতে পারে।

ইম্পোর্ট শেষ হলে, একটি সংক্ষিপ্ত, সোজাসাপ্টা রিপোর্ট দেখান এবং তা পরে রিভিউ করার জন্য উপলব্ধ রাখুন। ব্যবহারকারীদের কি হয়েছে তা অনুমান করতে হবে না।

কি রেকর্ড করবেন এবং কি দেখাবেন

ডিবাগ করার জন্য পর্যাপ্ত বিবরণ ক্যাপচার করুন কিন্তু মানুষকে অভিভূত করবেন না। একটি ভাল পোস্ট-ইম্পোর্ট সারসংক্ষেপে অন্তর্ভুক্ত থাকা উচিত:

• প্রক্রিয়াজাত সারি, তৈরি, আপডেট, এবং স্কিপ
• ত্রুটি গণনা সহ ডাউনলোডযোগ্য বা কপিযুক্ত ত্রুটি রিপোর্ট (সারি নম্বর, কলাম, মেসেজ)
• কোন সংরক্ষিত ম্যাপিং এবং ডিফল্ট ব্যবহার করা হয়েছে তার নোট
• সময় (শুরু ও শেষ) এবং কে চালিয়েছে
• পরিবর্তিত রেকর্ডগুলোর জন্য ফিল্টার করা দ্রুত লিংক (যদি আপনার অ্যাপ তা সমর্থন করে)

যদি আপনি এটি AppMaster-এ তৈরি করেন, আপনি Data Designer-এ ডেটা মডেল করতে পারেন, ভিজ্যুয়াল UI বিল্ডার দিয়ে ম্যাপিং ও প্রিভিউ স্ক্রিন তৈরি করতে পারেন, এবং ব্যবসায়িক প্রক্রিয়াতে ভ্যালিডেশন জোর করতে পারেন যাতে কিছুই PostgreSQL-এ লেখার আগে নিরাপদ থাকে। সেই বিভাজন প্রিভিউকে নিরাপদ এবং ইম্পোর্টকে কঠোর রাখা সহজ করে।

অবশেষে, লঞ্চের আগে আরেকটি গার্ডরেইল যোগ করুন: প্রতিটি এনভায়রনমেন্টে (staging, তারপর production) একটি টেস্ট ইম্পোর্ট বাধ্যতামূলক করুন এবং ইম্পোর্টগুলিকে একটি রোল বা পারমিশনের পেছনে রাখুন। এটি ফিচারটিকে ব্যবহারযোগ্য রাখবে কিন্তু ঝুঁকি কমাবে।