Application archive strategy: যত্নের সঙ্গে record সংরক্ষণ করুন

পুরোনো রেকর্ডের জন্য পরিষ্কার জায়গা কেন দরকার

বেশিরভাগ টিমের ধারণার চেয়ে application দ্রুত ভরে যায়। বন্ধ support case, সম্পন্ন order, পুরোনো user profile, audit log এবং draft record দৈনন্দিন কাজে আর প্রয়োজন না থাকলেও অনেক দিন দৃশ্যমান থাকে। Search result অপ্রয়োজনীয়ভাবে ভরে যায়, screen দেখে তথ্য খুঁজে নিতে বেশি সময় লাগে, আর কর্মীরা ভুল record খুলে ফেলতে পারেন।

সক্রিয় data এখনকার কাজকে সহায়তা করে। Archived data-এর উদ্দেশ্য আলাদা। কোনো আইন, customer request, financial check বা আগের সিদ্ধান্তের কারণে পরে প্রয়োজন হতে পারে বলেই টিম সেটি রেখে দেয়। এই দুই ধরনের data আলাদা রাখলে অপ্রয়োজনীয় তথ্য ফেলে না দিয়েও কর্মীদের workspace পরিষ্কার রাখা যায়।

সবকিছু একই জায়গায় রাখলেও ঝুঁকি বাড়ে। File জমতে থাকলে storage cost বাড়ে। Report-এ পুরোনো entry ঢুকে manager-দের কাছে বাস্তব পরিস্থিতির ভুল ছবি তুলে ধরতে পারে। প্রয়োজনের চেয়ে বেশি সময় personal detail রেখে দিলে privacy সমস্যা তৈরি হতে পারে, বিশেষ করে পুরোনো customer বা employee-রা যদি প্রতিদিন ব্যবহৃত tool-এ দেখা যেতে থাকেন।

একটি কার্যকর archive policy প্রতিটি record type-এর জন্য দুটি প্রশ্নের উত্তর দেয়: কেন আমরা এটি রাখছি, এবং কত দিন এটি দরকার? Active use শেষ হলে record কোথায় যাবে, সেটিও policy-তে উল্লেখ থাকা উচিত। Archive কোনো ভুলে যাওয়া folder নয়। বৈধ কারণে কর্মীদের পুরোনো record খুঁজে পাওয়ার সুযোগ থাকতে হবে, আবার routine search যেন বর্তমান কাজেই focused থাকে।

ধরা যাক, একটি support team open ও সম্প্রতি বন্ধ হওয়া case-গুলো main workspace-এ রাখে। ১৮ মাসের বেশি আগে বন্ধ হওয়া case archive-এ চলে যেতে পারে, যেখানে complaint review-এর সময় supervisor সেটি ফিরিয়ে আনতে পারবেন। এতে agent-রা বছরের পর বছর সমাধান হয়ে যাওয়া issue বাদ দিয়ে current case খুঁজতে পারবেন।

AppMaster-এ internal tool তৈরি করলে record-এর সংখ্যা বাড়ার আগেই এই বিভাজনের পরিকল্পনা করুন। Active ও archived record-এর জন্য আলাদা view তৈরি করা যায়, business process দিয়ে উপযুক্ত record সরানো যায় এবং role অনুযায়ী archive access সীমিত করা যায়। প্রতিটি record একটি পরিষ্কার কারণে রাখুন, সংরক্ষণের সময় সুরক্ষিত রাখুন এবং সেই কারণ শেষ হলে সরিয়ে দিন।

আপনার record-এর inventory তৈরি করুন

Application-এ কী data রয়েছে তা কেউ না জানলে archive policy কার্যকর হবে না। একটি ব্যবহারিক inventory দিয়ে শুরু করুন। App-এ যে record type ঢোকে, বের হয় বা থেকে যায়, সব তালিকাভুক্ত করুন।

সাধারণ entry-এর মধ্যে customer request, invoice, support case, user profile, contract, payment record, exported report ও audit log থাকে। Abandoned form submission ও draft order-এর মতো temporary record-ও যুক্ত করুন। এগুলো অনেক সময় নজর এড়িয়ে যায়, যতক্ষণ না storage, privacy বা search সমস্যা তৈরি হয়।

প্রতিটি record type-এর জন্য চারটি তথ্য লিখুন:

• কোন team এটি তৈরি করে বা ব্যবহার করে, যেমন support, finance, sales বা operations
• দৈনন্দিন কাজে এটি দরকার, নাকি মাঝে মাঝে reference হিসেবে দরকার
• কোন application, database, shared folder বা external service-এ এটি থাকে
• অন্য record এটি ব্যবহার করে কি না, যেমন customer account-এর সঙ্গে যুক্ত invoice

দৈনন্দিন ব্যবহারের data সহজে search ও open করা উচিত। যেসব পুরোনো reference data খুব কমই দরকার হয়, সেগুলো main workspace থেকে সরানো যায়। এখানে শুধু বয়স নয়, ব্যবহারের ধরন বেশি গুরুত্বপূর্ণ। Agent-রা সাম্প্রতিক conversation প্রায়ই দেখলে closed support case ছয় মাস দৃশ্যমান থাকতে পারে। কিন্তু দশ বছর আগের case হয়তো কেবল customer পুরোনো কোনো issue নিয়ে আপত্তি জানালে দরকার হবে।

Main application-এর বাইরে থাকা record-ও অন্তর্ভুক্ত করুন। Finance invoice accounting service-এ রাখতে পারে, আর support case note রাখতে পারে help desk tool-এ। Team-গুলো প্রায়ই report shared storage-এ export করে, কিন্তু সেই copy-গুলোরও আলাদা retention rule দরকার হতে পারে।

AppMaster দিয়ে তৈরি internal tool-এর ক্ষেত্রে data model, generated API record, uploaded file এবং payment বা messaging-এর মতো connected module অন্তর্ভুক্ত করুন। Deployment-এর পর প্রতিটি item কোথায় যাবে, তা লিখে রাখুন। যে record-এর হিসাবই রাখা হয়নি, সেটি সুরক্ষিত রাখা সম্ভব নয়।

প্রথম inventory-এর জন্য প্রতি record type-এ একটি row যথেষ্ট। যারা record ব্যবহার করেন, তাদের সঙ্গে এটি review করুন। Application owner-এর চোখ এড়িয়ে যাওয়া dependency ও পুরোনো file সম্পর্কে তারা প্রায়ই বেশি জানেন।

সহজে মানা যায় এমন data retention period নির্ধারণ করুন

Retention period বলে দেয়, delete করার বা long-term storage-এ সরানোর আগে টিম কত দিন record রাখবে। আইন, customer contract, tax rule, dispute ও দৈনন্দিন কাজের বাস্তব প্রয়োজনের ভিত্তিতে period নির্ধারণ করুন। যে নিয়ম কেউ ব্যাখ্যা বা প্রয়োগ করতে পারে না, record জমতে শুরু করলে সেটি ব্যর্থ হবে।

প্রতিটি file ও database row-এর জন্য একই নিয়ম ব্যবহার করবেন না। আলাদা record-এর ঝুঁকিও আলাদা। Signed customer agreement বহু বছর রাখতে হতে পারে, যেখানে duplicate import report কয়েক সপ্তাহের বেশি কাজে নাও লাগতে পারে। আপনার application archive strategy-তে প্রতিটি record group-এর নাম ও পরিষ্কার retention period থাকা উচিত।

একটি সহজ policy এমন হতে পারে:

• Tax ও accounting rule অনুযায়ী যত দিন প্রয়োজন, invoice ও payment record তত দিন রাখুন
• Contract চলাকালীন এবং claim সামলানোর জন্য প্রয়োজনীয় অতিরিক্ত সময় customer contract রাখুন
• Closed support case নির্দিষ্ট সংখ্যক বছর রাখুন, তবে active dispute থাকলে আরও বেশি সময় রাখা যেতে পারে
• Temporary upload, failed import ও test record অল্প সময় পর delete করুন

Clock কখন শুরু হবে, তা বছরের সংখ্যার মতোই গুরুত্বপূর্ণ। বিষয়টি সরাসরি লিখুন। Contract period upload করার দিন থেকে নয়, agreement শেষ হওয়ার দিন থেকে শুরু হতে পারে। Support case-এর period case close হওয়ার দিন থেকে শুরু হতে পারে। Employee record-এর ক্ষেত্রে employment শেষ হওয়ার দিনটি শুরু তারিখ হতে পারে।

Application-এ নিয়ম ব্যবহারযোগ্য করে তুলুন

Start event এমন একটি field-এ রাখুন যা application track করতে পারে, যেমন «case closed date» বা «contract end date»। হাতে হিসাব করলে সিদ্ধান্তে অসঙ্গতি আসে। AppMaster-এ Data Designer-এ এই তারিখ model করা যায় এবং visual business process দিয়ে retention date পৌঁছালে record flag করা যায়।

Exception-গুলো দৃশ্যমান রাখুন। Legal hold, audit বা open customer complaint স্বাভাবিক deletion থামাতে পারে। কে hold দিয়েছে, কেন দিয়েছে এবং কখন review করতে হবে, তা লিখুন। Private note বা inbox-এ এই তথ্য লুকিয়ে রাখবেন না।

Legal, compliance, finance বা privacy-এর দায়িত্বে থাকা ব্যক্তিকে organization-কে প্রভাবিত করে এমন period review করতে বলুন। Automation চালুর আগে তারা local requirement ও contract duty নিশ্চিত করতে পারবেন। নতুন market-এ প্রবেশ, contract template পরিবর্তন বা নতুন record type যোগ করার সময় policy review করুন।

কর্মীদের জন্য নির্দেশনাটি পুনরাবৃত্তিযোগ্য হওয়া উচিত: এই record এই তারিখ পর্যন্ত রাখুন, তারপর policy অনুযায়ী archive বা remove করুন।

পরিষ্কার archive criteria বেছে নিন

একটি application archive strategy-এর নিয়ম মানুষ ও software উভয়েরই একইভাবে প্রয়োগ করা দরকার। «পুরোনো» খুব অস্পষ্ট। Case বন্ধ হওয়া, contract শেষ হওয়া বা account inactive হওয়ার মতো application-এ আগে থেকেই থাকা event-এর সঙ্গে archive decision যুক্ত করুন।

Agent case closed mark করার পর ৯০ দিন কেউ reopen না করলে support case archive-এর উপযুক্ত হতে পারে। Contract end date পেরোনোর পর এবং finance final payment record করার পর customer contract সরানো যেতে পারে। এতে প্রতিটি move-এর পরিষ্কার কারণ থাকে এবং ভুল করে archive হওয়ার ঝুঁকি কমে।

নতুন manual checklist তৈরির আগে existing field ব্যবহার করুন। Status, close date, payment state, contract end date, last login date ও dispute flag প্রায়ই যথেষ্ট তথ্য দেয়। AppMaster-এ Data Designer-এ এই field model করে schedule অনুযায়ী business process দিয়ে পরীক্ষা করা যায়।

কোনো record তার type-এর সঙ্গে যুক্ত সব শর্ত পূরণ করলেই archive হবে। Closed support case ও completed payment-এর business এবং legal প্রয়োজন এক নয়।

Automation শুরুর আগেই exception যোগ করুন

কিছু record storage-এর জন্য প্রস্তুত মনে হলেও active রাখতে হয়। Open dispute, audit, refund request, legal hold বা linked active case archive আটকাবে। এই block একটি নির্দিষ্ট field-এ রাখুন, যাতে কর্মীদের comment বা স্মৃতির ওপর নির্ভর করতে না হয়।

প্রতিটি নিয়ম সহজ ভাষায় লিখুন। যেমন:

• Reopen না করে ৯০ দিন বন্ধ থাকা support case archive করুন, তবে dispute বা audit open থাকলে নয়।
• End date-এর ৩০ দিন পর final payment status complete হলে contract archive করুন।
• ১২ মাস sign-in না করা inactive account archive করুন, তবে সেটির active subscription বা unresolved request থাকলে নয়।
• Legal hold-এ থাকা record authorized ব্যক্তি hold সরানো পর্যন্ত active system-এ রাখুন।

Manual approval নির্ধারণ করুন

Automation সব পরিস্থিতি সামলাতে পারবে না। Records manager বা team lead-এর মতো manual archive অনুমোদন করতে পারে এমন role নির্ধারণ করুন। সেই ব্যক্তিকে reason, date ও record ID লিখতে বাধ্য করুন। এই permission অল্প কয়েকজনের মধ্যে সীমিত রাখুন।

কেউ record নির্ধারিত সময়ের আগেই archive করতে চাইলে একই নিয়ম প্রযোজ্য। Sales manager request করতে পারেন, তবে authorized approver-কে আগে connected invoice, open task ও retention requirement পরীক্ষা করতে হবে। এই review-এর ফলে দেখতে সম্পূর্ণ মনে হওয়া কোনো record এমন সময় হারিয়ে যাবে না, যখন অন্য team-এর এখনও সেটি দরকার।

কোন তথ্য archive-এ যাবে তা নির্ধারণ করুন

Archive-এর উদ্দেশ্য clutter কমানো, পুরোনো কাজ খুঁজে পাওয়া অসম্ভব করা নয়। বেশিরভাগ কর্মীর দরকার না হলে inactive record default search result থেকে বাদ দিন। এতে sales ও support team বছরের পর বছর বন্ধ item-এর বদলে current work আগে দেখতে পারবে।

প্রয়োজনীয় retrieval detail ছাড়া কোনো record সরাবেন না। Stable record ID, linked person বা account, গুরুত্বপূর্ণ date, current status ও archive date সংরক্ষণ করুন। সংক্ষিপ্ত closure reason থাকলে পরে record-এর প্রয়োজন বোঝা সহজ হয়।

Related information-এর জন্য পরিষ্কার নিয়ম দরকার। Closed support case-এ message, uploaded screenshot, payment detail ও customer profile-এর link থাকতে পারে। পুরো case একসঙ্গে যাবে, কিছু file active storage-এ থাকবে, নাকি sensitive item আলাদা retention rule অনুসরণ করবে, তা নির্ধারণ করুন।

একটি সাধারণ archive package-এ থাকে main record ও তার identifier, created ও archived date, status ও owner, closure reason, related message ও file এবং active থাকা connected record-এর reference।

কারণ ছাড়া একটি business event-কে কয়েকটি জায়গায় ভাগ করবেন না। পুরোনো order archive-এ চলে গেলেও refund note active system-এ থাকলে কর্মীরা অসম্পূর্ণ history দেখতে পারেন। পুরোনো case daily view থেকে সরে গেলেও active customer profile সাধারণত available রাখা উচিত।

Report-এরও নিজস্ব নিয়ম দরকার। Finance, compliance ও trend report-এ archived record লাগতে পারে, কিন্তু daily workload report-এ সাধারণত শুধু active item দরকার। Routine reporting-এর জন্য monthly archive summary যথেষ্ট হতে পারে, আর audit বা investigation-এর সময় full detail রাখা যাবে।

AppMaster-এ Data Designer-এ archive status ও date model করে business process দিয়ে eligible record সরানো যায় এবং কোন view-এ সেগুলো থাকবে তা নিয়ন্ত্রণ করা যায়। বহু বছরের history-তে প্রয়োগের আগে অল্প কিছু বাস্তবধর্মী record দিয়ে নিয়ম পরীক্ষা করুন।

প্রয়োজনের আগে restore step লিখে রাখুন

মানুষ যেন বিভ্রান্তি ছাড়াই record ফিরিয়ে আনতে পারে, তবেই archive কার্যকর হবে। Team এখনও record structure, permission ও business rule ভালোভাবে জানে থাকতেই data restore process লিখুন।

কে restore request করতে পারবে, তা নির্ধারণ করুন। Customer follow-up-এর জন্য support agent-এর closed case দরকার হতে পারে, কিন্তু finance record-এর জন্য manager বা compliance owner-এর approval লাগতে পারে। Request সহজ রাখুন, তবে reason অবশ্যই নিন, যাতে বারবার হওয়া সমস্যা বা অস্বাভাবিক access শনাক্ত করা যায়।

একটি নির্দিষ্ট request path কার্যকর:

1. Requester record শনাক্ত করে এবং কেন দরকার তা ব্যাখ্যা করে।
2. Assigned owner approval দরকার কি না পরীক্ষা করে।
3. System বা administrator record-টি নির্ধারিত জায়গায় restore করে।
4. Team request, reason, approver ও restore date record করে।
5. Active review period শেষ হলে record আবার archive-এ ফিরে যায়।

Record কোথায় ফিরবে তা স্পষ্টভাবে লিখুন। Restored support case নতুন case-এর সঙ্গে নীরবে মিশে না গিয়ে «Archived record restored» status-সহ restricted review area-তে দেখা যেতে পারে। এটি কত দিন available থাকবে, যেমন ১৪ বা ৩০ দিন, এবং কী কারণে আরও আগে archive-এ ফিরবে, তা নির্ধারণ করুন।

Request log service ও accountability দুটোই সমর্থন করে। এতে record ID, requester, business reason, প্রয়োজন হলে approver, request date ও return-to-archive date রাখুন। Chat message বা স্মৃতি এই কাজের নির্ভরযোগ্য record নয়।

বাস্তব archive sample দিয়ে procedure পরীক্ষা করুন। Related contact, note, payment entry বা attachment-সহ একটি record restore করুন। Link ঠিক আছে কি না এবং ব্যবহারকারীরা অনুমোদিত field-ই দেখছেন কি না পরীক্ষা করুন। Missing attachment ও broken relationship setup-এর সময় নয়, testing-এর সময়ই বেশি ধরা পড়ে।

AppMaster application-এ data model-এ archive status ও restore request model করা যায়। এরপর visual business process দিয়ে approval পাঠানো এবং প্রতিটি action record করা যায়। Policy অনুযায়ী অতিরিক্ত approval দরকার হলে একই workflow routine ও sensitive request দুটোই সামলাতে পারে।

Archive access rule নির্ধারণ করুন

Archived record-এ active থাকার সময়কার মতোই personal, financial বা confidential detail থাকতে পারে। Daily view থেকে record সরালেই সবার access খুলে দেওয়া নিরাপদ হয় না। বিস্তৃত team membership নয়, একজনের কাজের প্রয়োজন অনুযায়ী permission দিন।

Follow-up-এর সময় support staff-এর পুরোনো customer case পড়ার দরকার হতে পারে। কিন্তু প্রতিটি archived invoice, internal note বা personnel file দেখার প্রয়োজন সাধারণত নেই। Request সামলানোর মতো view দিন এবং কাজে না লাগা field লুকিয়ে রাখুন।

Sensitive archive নির্দিষ্ট role-এর মধ্যে সীমিত রাখুন। Finance manager archived payment record খুলতে পারবেন, কিন্তু support agent হয়তো শুধু case number, customer name, status ও অনুমোদিত account history দেখতে পারবেন। ছোট permission set review করা সহজ এবং accidental exposure কমায়।

Export ও bulk access নিয়ন্ত্রণ করুন

Screen-এ একটি record দেখার চেয়ে export-এর ক্ষেত্রে কঠোর নিয়ম দরকার। Spreadsheet copy, email বা application-এর বাইরে storage করা যায়। Archived record-এ personal বা financial detail থাকলে approval নিন। কে export চেয়েছে, কেন দরকার, কোন date range এবং কে অনুমোদন করেছে, তা record করুন।

AppMaster দিয়ে তৈরি internal tool-এ role model করে business process দিয়ে export request approver-এর কাছে পাঠানো যায়। Busy day-তেও কর্মীরা যাতে নিয়মটি অনুসরণ করতে পারেন, তা যথেষ্ট সহজ রাখুন।

কয়েকটি access level সহায়ক হতে পারে:

• Support staff তাদের customer request-এর সঙ্গে যুক্ত archived case search ও view করতে পারবে।
• Escalation বা audit-এর জন্য manager-রা বিস্তৃত case history দেখতে পারবে।
• Finance বা privacy role payment বা sensitive personal data-সহ record খুলতে পারবে।
• Administrator permission manage করতে পারবে, তবে তার মানেই প্রতিটি archive export করার permission থাকা উচিত নয়।

Job পরিবর্তনের সময় access review করুন

মানুষ team বদলায়, temporary duty নেয় এবং organization ছেড়ে যায়। Annual cleanup-এর অপেক্ষা না করে তখনই archive access review করুন। কারও শেষ কর্মদিবসে access সরান এবং পুরোনো record আর প্রয়োজন না হলে role অনুযায়ী permission বদলান।

Sensitive archive-এর জন্য basic access log রাখুন। কে কখন record খুলেছে এবং কিছু export করেছে কি না, এতে দেখা উচিত। Customer পুরোনো case কে দেখেছে জানতে চাইলে inbox ঘেঁটে নয়, log দেখে তথ্যভিত্তিক উত্তর দেওয়া যাবে।

উদাহরণ: বন্ধ support case archive করা

Support team কিছু সময় closed case কাছে রাখতে চায়। Agent-রা সাম্প্রতিক case দেখে আগের উত্তর যাচাই করে, repeat issue খুঁজে পায় এবং customer conversation আবার শুরু করলে সাহায্য করে। সব case চিরকাল active রাখলে daily search ধীর হয় এবং প্রয়োজনের চেয়ে বেশি পুরোনো customer information দৃশ্যমান থাকে।

ধরা যাক, customer refund পাওয়ার পর ১৪ মে ২০২৪-এ একটি case বন্ধ হয়েছে। Policy অনুযায়ী final closure date থেকে দুই বছর closed case active থাকবে। এই সময় authorized support staff case search, message পড়া ও refund record দেখতে পারবে।

Archive trigger পরিষ্কার: case দুই বছর ধরে বন্ধ, এবং কোনো legal hold, open dispute বা linked investigation নেই। ১৫ মে ২০২৬-এ application case ও তার attachment archive-এ সরিয়ে দেয়। Normal support queue-তে এটি আর দেখা যায় না, তবে retention period-এর বাকি সময় archive-এ থাকে।

Policy-তে বলা থাকতে পারে, closed case দুই বছর active থাকবে, কোনো hold বা investigation না থাকলেই archive হবে, message ও attachment সংরক্ষিত থাকবে এবং search approved support manager, compliance staff ও complaint reviewer-এর মধ্যে সীমিত থাকবে।

ছয় মাস পর customer refund decision নিয়ে complaint করেন। Complaint reviewer case number দিয়ে case খুঁজে temporary restore request করেন। Reviewer complaint reference ও access-এর কারণ লেখেন। Original conversation ও refund timeline দরকার হওয়ায় support manager request approve করেন।

Application case-এর read-only copy restricted review area-তে restore করে। Staff এটি পরীক্ষা করতে পারে, কিন্তু history পরিবর্তন করতে, case reopen করতে বা normal support queue-তে ফেরত দিতে পারে না। Review শেষ হলে copy archive-এ ফিরে যায়, অথবা restore rule অনুযায়ী application সেটি সরিয়ে দেয়।

Access log-এ কে case search করেছে, কে restore চেয়েছে, কে অনুমোদন করেছে, কেন access নেওয়া হয়েছে এবং application কখন review copy তৈরি ও সরিয়েছে, সব থাকা উচিত। «শুধু manager» যথেষ্ট নয়। Role-এর নাম দিন, sensitive restore-এর জন্য reason নিন এবং restored record দৈনন্দিন কাজ থেকে আলাদা রাখুন।

যে ভুলগুলো পরে সমস্যা তৈরি করে

সাধারণ shortcut-এর কারণে archive policy প্রায়ই ব্যর্থ হয়। Team প্রতিটি record-এর জন্য একটি date বেছে নেয়, storage খালি করতে file delete করে অথবা একজনকে informal monthly cleanup করতে বলে। কারও case history, payment record বা কোনো সিদ্ধান্তের প্রমাণ দরকার হওয়া পর্যন্ত এসব সহজ মনে হয়।

একটি retention period খুব কমই সব record type-এর জন্য উপযুক্ত। Closed support case-এর active life invoice, contract, consent record বা audit log-এর চেয়ে ছোট হতে পারে। প্রতিটি type-এর জন্য আলাদা period, owner ও reason দিন।

কাজ শেষ না হওয়া পর্যন্ত record archive করবেন না। Unpaid invoice, disputed charge বা review-এর অপেক্ষায় থাকা case-এ দ্রুত access দরকার। Record archive criteria-তে status check যোগ করুন। যেমন, support case তখনই archive হবে যখন team সেটি close করেছে, refund window শেষ হয়েছে এবং কোনো review flag নেই।

Deletion ও archiving আলাদা সমস্যা সমাধান করে। Archive পুরোনো information tighter access rule-এর অধীনে available রাখে। Deletion তা সরিয়ে দেয়। Policy-তে সাত বছর retention দরকার হলে daily list-এ আর দেখা যায় না বলে এক বছর পর record delete করা policy ভঙ্গ করবে এবং business-কে প্রমাণহীন করে দিতে পারে।

Manual work আরেকটি দুর্বল জায়গা। কোন filter চালাতে হবে, export কোথায় যায় এবং record কীভাবে restore করতে হবে, তা যদি কেবল একজন employee জানেন, তিনি অনুপস্থিত বা organization ছাড়লে process থেমে যাবে। ধাপগুলো সহজ ভাষায় লিখুন, backup owner নির্ধারণ করুন এবং বাস্তব sample দিয়ে data restore process পরীক্ষা করুন।

AppMaster-এ memory-এর ওপর নির্ভর না করে business process-এর অংশ হিসেবে এই check করা যায়। Status, date, payment state ও review flag পরীক্ষা করে তারপর record-এর archive status বদলানো যায়। এতে repeatable rule এবং কী ঘটেছে তার পরিষ্কার history তৈরি হয়।

Exception নিয়মিত review করুন। Dispute বা review-এর জন্য hold করা record অনির্দিষ্টকাল limbo-তে থাকা উচিত নয়। Held record পরীক্ষা করার জন্য কাউকে দায়িত্ব দিন। Hold শেষ হলে সেগুলো active work-এ ফেরত দিন, archive করুন, অথবা documented retention period শেষ হলে delete করুন।

প্রকাশের আগে policy পরীক্ষা করুন

মানুষ অনুমান না করেই প্রয়োগ করতে পারলে policy কার্যকর হয়। Publish বা revise করার আগে এটি review করুন, বিশেষ করে application-এ নতুন record type যোগ হলে।

প্রতিটি record type-এর named owner ও retention period দরকার। «Customer support case» খুব বিস্তৃত হতে পারে, যদি এর মধ্যে billing dispute, routine question ও account deletion request থাকে এবং এগুলোর নিয়ম আলাদা হয়। Group-গুলো আলাদা করে নাম দিন ও পরিষ্কার deadline নির্ধারণ করুন।

Archive trigger এমন event-এর সঙ্গে যুক্ত কি না নিশ্চিত করুন, যা কর্মীরা সত্যিই দেখতে পারেন। «Inactive হলে archive করুন» কথাটি মতভেদ তৈরি করে, কারণ team-গুলো inactive আলাদাভাবে সংজ্ঞায়িত করে। «Case close হওয়ার ৯০ দিন পর archive করুন» অনেক সহজ। Reopened record-এর ক্ষেত্রে clock আবার শুরু হবে, নাকি original closure date-ই নিয়ন্ত্রণ করবে, তা ঠিক করুন।

Policy publish করার আগে:

• প্রতিটি record type-এর owner, retention period ও deletion decision নির্ধারণ করুন।
• প্রতিটি archive trigger-কে বাস্তব event-এর সঙ্গে মিলিয়ে নিন, যেমন closed case, completed order বা ended contract।
• File, note ও related activity-সহ একটি sample record restore করুন।
• কে archived record view, restore বা export করতে পারবে, তা review করুন।
• Software, business process বা legal duty পরিবর্তনের জন্য review date নির্ধারণ করুন।

Restore test গুরুত্বপূর্ণ, কারণ record সাধারণত একা থাকে না। Attachment ও linked record-সহ sample বেছে নিন। যে ব্যক্তি archive rule তৈরি করেননি, তাকে লিখিত process অনুসরণ করে record খুঁজে restore করতে বলুন। কত সময় লাগে এবং কী ফিরিয়ে আনা যায় না, তা লিখে রাখুন।

একইভাবে access rule পরীক্ষা করুন। Support agent-এর পুরোনো case পড়ার প্রয়োজন হতে পারে, কিন্তু কেবল manager সেটি restore বা একসঙ্গে অনেক case export করতে পারবেন। Export সতর্কতার সঙ্গে পরিচালনা করুন, কারণ downloaded file application-এর স্বাভাবিক permission ও retention control-এর বাইরে থাকে।

AppMaster দিয়ে তৈরি no-code app ব্যবহার করলে record close বা archive করা business process-এর পাশে এই check-গুলো document করুন। Team status বদলালে, নতুন file type যোগ করলে বা user role তৈরি করলে একই সময়ে archive rule update করুন।

Policy-কে দৈনন্দিন কাজে ব্যবহার করুন

দ্রুত বাড়তে থাকা একটি record type দিয়ে শুরু করুন, যেমন closed support case বা completed order request। প্রথম version সংক্ষিপ্ত রাখুন। কখন record move হবে, exception কে approve করবে এবং staff কীভাবে restore request করবে, শুধু এগুলো পরিষ্কারভাবে লিখুন।

প্রথম rollout ছোট রাখুন। Archive criteria পূরণ করে এমন প্রায় ৫০টি closed record বেছে নিন। Case number, date, customer name, attachment ও audit note-সহ পরে প্রয়োজন হতে পারে এমন detail archive-এ আছে কি না পরীক্ষা করুন। Active record archive-এ ঢোকেনি, তা নিশ্চিত করুন।

যারা process ব্যবহার করবেন, তাদের সঙ্গে পুরো workflow পরীক্ষা করুন। কোনো customer আগের response নিয়ে আপত্তি করায় support manager গত বছরের case চাইতে পারেন। Approver-এর কাছে request পৌঁছানো, reason record করা, সঠিক জায়গায় case restore করা এবং requester-কে জানানো উচিত। Exercise-এর সময় মাপুন। অতিরিক্ত ধাপ থাকলে বা audit trail তৈরি না হলে staff-এর ওপর নির্ভর করার আগে process বদলান।

কর্মীদের এমন guidance দিন যা দৈনন্দিন প্রশ্নের উত্তর দেয়:

• কোন record স্বয়ংক্রিয়ভাবে move হবে এবং কোনটির review দরকার
• Application-এ archived record কোথায় দেখা যাবে
• কে পুরোনো record view, change বা restore করতে পারবে
• Restore request-এ কী reason দিতে হবে
• Archived record না পাওয়া গেলে কে সহায়তা করবে

Role বা legal requirement বদলালে guidance update করুন। কয়েক মাস পরপর ছোট review করলে কাগজে যুক্তিসঙ্গত মনে হওয়া কিন্তু বাস্তবে কাজ ধীর করে দেওয়া rule ধরা পড়ে।

AppMaster team-কে code না লিখেই internal application-এর মধ্যে archive workflow তৈরি করতে সাহায্য করতে পারে। Active, Closed, Archive review ও Archived-এর মতো status তৈরি করুন। Visual Business Process Editor ব্যবহার করে record move করার আগে date ও status পরীক্ষা করুন, তারপর role-based access প্রয়োগ করুন, যাতে শুধু অনুমোদিত user পুরোনো data view বা restore করতে পারে।

Shared spreadsheet-এর বদলে বাস্তব permission-এর ওপর process তৈরি করুন। Support agent restore request করতে পারেন, team lead approve করতে পারেন এবং administrator action সম্পন্ন করতে পারেন। প্রতিটি ধাপে কে কখন কাজ করেছে, তা record করা যায়।

প্রথম record type ভালোভাবে কাজ করলে একই pattern পরের type-এ প্রয়োগ করুন। ছোট, পরীক্ষিত পরিবর্তন archive rule-কে এমন routine work-এ পরিণত করে, যা সবাই পিছিয়ে রাখে এমন cleanup project হয়ে থাকে না।