Soft delete και restore σε CRM και portals: πότε η διαγραφή πρέπει να αναστρέφεται

Ένας χρήστης διαγράφει κατά λάθος έναν πελάτη, μια υπόθεση ή ένα έγγραφο. Αν η εγγραφή αφαιρεθεί αμέσως και οριστικά, η επαναφορά απαιτεί backup ή χειροκίνητη επέμβαση. Το soft delete κρατά την εγγραφή σε μη ενεργή κατάσταση ώστε να μπορεί να αποκατασταθεί.

Ακούγεται απλό: προσθέτουμε ένα deleted_at. Στην πράξη, η διαγραφή επηρεάζει αναζητήσεις, μοναδικά πεδία, σχέσεις, permissions, αναφορές και πολιτικές retention. Χρειάζεται να σχεδιαστεί ως πλήρης κατάσταση του domain.

Πότε έχει νόημα το soft delete

Είναι χρήσιμο όταν η διαγραφή από χρήστη μπορεί να είναι λάθος, όταν υπάρχουν συνδεδεμένες εγγραφές ή όταν η ομάδα χρειάζεται σύντομο παράθυρο επαναφοράς. Παραδείγματα είναι CRM contacts, projects, portal accounts και αρχεία εργασίας.

Δεν είναι κατάλληλο για κάθε δεδομένο. Προσωρινά tokens, cache entries ή δεδομένα που πρέπει να διαγραφούν άμεσα μπορεί να χρειάζονται hard delete. Επίσης μια νομική υποχρέωση διατήρησης ή διαγραφής δεν λύνεται αυτόματα με μία τεχνική σημαία.

Κρύψτε σωστά τις διαγραμμένες εγγραφές

Μετά το soft delete, η εγγραφή δεν πρέπει να εμφανίζεται σε κανονικές λίστες, autocomplete, APIs ή counts. Ο ασφαλέστερος σχεδιασμός είναι default scope που αποκλείει deleted records και ρητή, περιορισμένη λειτουργία για trash ή admin views.

Ελέγξτε joins και reports. Ένα διαγραμμένο contact μπορεί να συνεχίσει να εμφανίζεται μέσω παλιάς παραγγελίας. Μερικές φορές αυτό είναι επιθυμητό για ιστορικό· άλλες φορές πρέπει να εμφανίζεται ανωνυμοποιημένη ένδειξη. Ο κανόνας πρέπει να είναι συγκεκριμένος ανά σχέση.

Ποιος μπορεί να διαγράψει και ποιος να επαναφέρει

Η δυνατότητα restore δεν πρέπει να είναι διαθέσιμη απλώς επειδή ο χρήστης γνωρίζει το ID. Εφαρμόστε server-side authorization για delete, view deleted, restore και permanent delete ως ξεχωριστές ενέργειες.

Σε multi-tenant εφαρμογή, η διαγραμμένη εγγραφή παραμένει στον ίδιο tenant και δεν πρέπει να γίνει ορατή αλλού. Αν ο χρήστης έχασε τον ρόλο του μετά τη διαγραφή, δεν αποκτά αυτόματα δικαίωμα επαναφοράς.

Cascade rules χωρίς εκπλήξεις

Τι συμβαίνει όταν διαγράφεται ένας πελάτης που έχει projects, invoices και notes; Το αυτόματο cascade soft delete μπορεί να κρύψει πολύ περισσότερα δεδομένα από όσα περίμενε ο χρήστης. Το αντίθετο, να μείνουν όλα ενεργά χωρίς parent, δημιουργεί broken flows.

Πριν την επιβεβαίωση δείξτε τον αντίκτυπο: ποιες child εγγραφές θα κρυφτούν, ποιες θα παραμείνουν και ποιες δεν επιτρέπεται να διαγραφούν. Στο restore, εξετάστε αν πρέπει να επανέλθουν όλες οι children ή μόνο όσες διαγράφηκαν από την ίδια πράξη. Ένα deletion batch ID βοηθά στη σωστή συσχέτιση.

Unique fields και επαναχρησιμοποίηση

Αν ένα διαγραμμένο account κρατά email ή κωδικό πελάτη, μπορεί να εμποδίζει τη δημιουργία νέας εγγραφής. Αν επιτρέψετε επαναχρησιμοποίηση, τι συμβαίνει όταν αργότερα γίνει restore;

Ορίστε πολιτική ανά πεδίο. Μπορείτε να διατηρείτε μοναδικότητα και στις διαγραμμένες εγγραφές, να τροποποιείτε ελεγχόμενα το value κατά τη διαγραφή ή να απαιτείτε merge αντί για restore όταν υπάρχει σύγκρουση. Η επιλογή πρέπει να είναι προβλέψιμη και να διατηρεί audit trail.

Retention και οριστική διαγραφή

Το soft delete δεν σημαίνει ότι τα δεδομένα μπορούν να μείνουν για πάντα. Η ευρωπαϊκή αρχή storage limitation απαιτεί χρονικά όρια διαγραφής ή review με βάση τον σκοπό και τυχόν νομικές υποχρεώσεις. Η ακριβής περίοδος πρέπει να καθορίζεται από την επιχείρηση με κατάλληλη νομική καθοδήγηση.

Μετά το retention window, background job μπορεί να κάνει permanent delete ή anonymization. Ελέγξτε attachments, search indexes, caches και derived data, όχι μόνο την κύρια γραμμή της βάσης. Τα backups ακολουθούν ξεχωριστή πολιτική κύκλου ζωής και restore.

Audit trail και UI

Καταγράψτε ποιος διέγραψε, πότε, προαιρετικό reason, ποιος επανέφερε και ποια related records επηρεάστηκαν. Τα logs δεν πρέπει να περιέχουν περιττό προσωπικό περιεχόμενο.

Στο interface, χρησιμοποιήστε σαφή labels: «Μεταφορά στον κάδο», «Επαναφορά» και «Οριστική διαγραφή». Δείξτε μέχρι πότε μπορεί να γίνει restore. Για μεγάλη επίδραση ή permanent delete, ζητήστε επιβεβαίωση που περιγράφει το αποτέλεσμα.

Πώς το υλοποιεί η Ai Foundry

Στην Ai Foundry σχεδιάζουμε delete και restore με βάση το domain της εφαρμογής. Καταγράφουμε relationships, retention, permissions και conflicts πριν προσθέσουμε τη λειτουργία, ώστε η διαγραφή να μη δημιουργεί κρυφές ασυνέπειες.

Σε CRM και customer portals υλοποιούμε trash views, server-side authorization, deletion groups, audit trail και ελεγχόμενο purge. Έτσι η ομάδα μπορεί να διορθώσει ανθρώπινο λάθος χωρίς το soft delete να γίνει μόνιμη αποθήκη ξεχασμένων δεδομένων.

Checklist

• Ποιες εγγραφές υποστηρίζουν restore;
• Κρύβονται παντού by default οι deleted records;
• Υπάρχουν ξεχωριστά permissions για restore και purge;
• Είναι σαφές τι συμβαίνει στα related records;
• Έχουν λυθεί οι συγκρούσεις unique fields;
• Υπάρχει retention window και automated purge;
• Καθαρίζονται attachments και indexes;
• Καταγράφονται delete και restore actions;

Συμπέρασμα

Το soft delete είναι δίχτυ ασφαλείας, όχι τελική πολιτική δεδομένων. Όταν συνδυάζεται με σωστά permissions, cascade rules και retention, προσφέρει επαναφορά χωρίς να θυσιάζει συνέπεια και ιδιωτικότητα.

Πηγές: OWASP Authorization Cheat Sheet, European Commission: GDPR principles and storage limitation.