Se non archivi oggi…
Disponibile anche in 19 lingue
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modulo 4 di 4 del capitolo Progettare per la scala, capitolo 7 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Quando il volume incontra il modello di condivisione · Successivo: il prossimo capitolo, Architettura delle query e del recupero dei dati
La domanda a cui risponde questo modulo: Come si pianificano archiviazione ed eliminazione definitiva?
When somebody tells me “we’ll archive the old records later,” I ask one question: if you’re not archiving today, are you ever going to archive? “Later” often becomes after the next release, after the migration, after the reorganization, after we fix performance, after we run out of storage. Then five years on, someone finally asks why there are 80 million records in this object. I don’t want to discover archiving after large data volume has become the problem. If I know the data will grow, I decide its lifecycle when I design it. Salesforce’s own guide says the same: “if your volume of data is increasing, performance can degrade as time goes by. A policy of archiving or discarding data at the same rate at which it comes into the system can prevent this effect” (Best Practices for Deployments with Large Data Volumes (si apre in una nuova scheda), Winter ‘27). ⟲
Ogni record ha un ciclo di vita
Sezione intitolata “Ogni record ha un ciclo di vita ”Ci siamo chiesti come nasce un record, chi ne è titolare, chi può modificarlo, cosa fa fede. Ora un’altra domanda: come esce? Un record può passare da attivo a inattivo ad archiviato a eliminato definitivamente. Non ogni record ha bisogno di ogni fase, ma ogni oggetto ad alto volume ha bisogno di un ciclo di vita. Una consegna di Steve Trucking serve di continuo finché è in corso: alla squadra, al coordinamento, all’assistenza clienti, al partner, all’automazione. Una settimana dopo la chiusura è ancora utile. Sei mesi dopo è soprattutto storico del servizio. Tre anni dopo è soprattutto analitica, audit o l’occasionale contestazione. Dieci anni dopo, forse nessuno ha più un motivo legittimo per tenerla. Il valore dei dati cambia nel tempo; l’architettura dovrebbe cambiare con esso.
L’eliminazione è inevitabile, quindi decidila dal primo giorno
Sezione intitolata “L’eliminazione è inevitabile, quindi decidila dal primo giorno ”Prima o poi dovrai eliminare dati. Quindi voglio politiche di conservazione ed eliminazione definite all’inizio del progetto, non quando lo spazio diventa caro. La conservazione è dettata da requisiti di business e normativi: per quanto tempo deve restare operativo, per quanto tempo dobbiamo tenerlo, perché, chi potrebbe averne bisogno, in quanto tempo deve ottenerlo, può essere eliminato prima o poi, e la privacy dice che dovrebbe sparire prima? Il capitolo 5 ha mostrato che tenere tutto per sempre non è automaticamente più sicuro; a volte il rischio è proprio tenere i dati più a lungo.
Tieni separate tre decisioni. Conservazione: per quanto tempo lo teniamo? Archiviazione: dove e come teniamo ciò che non appartiene più al carico di lavoro attivo? Eliminazione definitiva: quando e come viene rimosso per sempre? Avere bisogno di sette anni di dati non significa sette anni attivi. Magari diciotto mesi attivi, poi archiviati per il resto del periodo, poi eliminati. Ora il ciclo di vita è esplicito.
Purging at volume has its own mechanics, and Salesforce spells them out. Deleting a record doesn’t remove it at once: it goes to the Recycle Bin for 15 days, and while it’s there it “still affects database performance because the data is still resident, and deleted records have to be excluded from any queries.” For a purge of a million records or more, Salesforce’s advice is the hard delete option of Bulk API 2.0, which skips the Recycle Bin, and when records have many children, to delete the children first (Deleting Data (si apre in una nuova scheda); Best Practices: Deleting Data (si apre in una nuova scheda)). A purge is a data operation like any other at scale: plan it, run it in batches, and check it. ⟲
Test knowledge. Know how to purge at volume: soft-deleted records stay in the Recycle Bin for 15 days and still slow queries; for a million records or more, use Bulk API 2.0 hard delete; delete children before parents. ⟲
Retain for seven years doesn’t mean keep active for seven years. ⟲
Fai il backup prima di eliminare
Sezione intitolata “Fai il backup prima di eliminare ”Archiviare prima o poi significa rimuovere record dal sistema attivo, quindi, prima di progettare l’eliminazione, voglio la storia del ripristino: possiamo ripristinare, in quanto tempo, sappiamo esattamente cosa è stato tolto, possiamo ripristinare le relazioni, l’abbiamo testato? I backup sono in piedi prima che si elimini qualsiasi cosa. Backup e archivio sono capacità diverse: un backup protegge dalla perdita; un archivio sposta di proposito i dati fuori dalla popolazione attiva mantenendo l’accesso di cui il business ha ancora bisogno. Eliminare dieci record per errore è fastidioso. Eliminarne dieci milioni è un incidente. Il Numero di Zeri vale anche per gli errori.
Entrambi ora vengono da Salesforce stessa. Own, l’azienda dietro OwnBackup, fa parte della Salesforce Platform: Own Recover è ora Salesforce Backup & Recover (backup giornalieri e su richiesta di dati e metadati, ripristini a livello di campo, record o oggetto, ripristino a un punto nel tempo), e Archive sposta i dati usati di rado su un’archiviazione a basso costo mantenendoli accessibili dall’interno di Salesforce, secondo politiche di archiviazione e conservazione (Own From Salesforce Product Suite FAQ (si apre in una nuova scheda); Own’s tools, now part of Salesforce (si apre in una nuova scheda)).
Un archivio che nessuno trova è quasi un’eliminazione
Sezione intitolata “Un archivio che nessuno trova è quasi un’eliminazione ”Un team sposta i dati vecchi in un posto più economico. Archiviazione completata. Poi chiama una cliente: “Ho avuto una consegna quattro anni fa e mi serve la prova di consegna.” L’assistenza cerca in Salesforce: niente. Ora servono un altro sistema, la tabella giusta, un identificativo, un amministratore, una richiesta, due giorni. Non è granché come archivio. I dati archiviati non devono comportarsi come dati attivi. Possono essere più lenti, in sola lettura, mostrati in un componente diverso. Ma i dati archiviati devono restare reperibili, come il business richiede.
I’ve seen this done well at a service chain. At the very beginning of the project they told me, “We only do a hundred appointments a day at a store.” A hundred, no big deal. But they had a thousand stores, open six days a week. Do the quick math: that’s about 31 million appointments a year. Then they created two appointment records for every visit, one at the front office and one at the back, so 62 million. And they needed five years: over 300 million records. I could see large data volume coming before we’d even gone live. So right from the beginning we said: there has to be archiving before we collect a single appointment. We put the archive in big objects and built it in from the ground up. When a user searched a customer, the live appointments came first, and below them, the archived ones. The archive didn’t pretend to be active data, and nobody had to become a database administrator to find history. Active data where the operational system needs it; archived data somewhere suited to its volume; a path from the business context to both. Much better than either extreme: everything active forever, or moved somewhere nobody can find. ⟲
Dove deve vivere l’archivio?
Sezione intitolata “Dove deve vivere l’archivio? ”Keeping data in core is like keeping it at the front of the office, where it’s in the way of today’s work. Somewhere in the future of any object with tens of millions of records there’s a move to the back: a box in an archive, the shed (big objects), or a hologram (virtualization, the data shown in Salesforce but living elsewhere). There’s no single answer; I choose the destination by constraint. When the customer doesn’t want an external store, I’ve used big objects: on-platform, built for very large volumes, but with no standard UI or reporting, Apex-only access and querying through the index, so plan the access path before you choose them (chapter 3’s “shed out back”). Plan the storage too: most editions are allocated storage for 1 million big object records per org, and more has to be arranged with Salesforce (Data and File Storage Allocations (si apre in una nuova scheda)). Two more facts matter for an archive. Big objects support only object and field permissions, not sharing rules, and triggers and flows don’t run on them. And inserting an identical record twice creates only one, so writes can be idempotent, which helps when an archive run has to restart (Big Objects (si apre in una nuova scheda)). ⟲
A big object: the archive stays inside Salesforce, and you build the window users see it through. ⟲
When an external store is fine, I’ve used an off-platform database surfaced through Salesforce Connect, so archived records appear in Salesforce without being copied back. Precisely: Salesforce Connect reaches external data through OData services, other Salesforce orgs, a custom adapter built with the Apex Connector Framework, or specific adapters for Amazon DynamoDB, GraphQL and SQL (the SQL adapter supports Snowflake and Amazon Athena), so a general database usually needs an OData layer or a custom adapter in front of it (Choose Which Salesforce Connect Adapter to Use (si apre in una nuova scheda)). ⟲
An external store: the archive leaves Salesforce, and Salesforce Connect brings it back into view. ⟲
The archive doesn’t have to be a database. It can be files in low-cost file storage, such as Amazon S3, and Salesforce Connect’s SQL adapter for Amazon Athena lets users “analyze data directly in Amazon Simple Storage Service (Amazon S3)” from Salesforce. One catch for an archive: that adapter is available “not for high-data-volume external objects,” so check what your volume needs before you choose it (Salesforce Connect SQL Adapter for Amazon Athena (si apre in una nuova scheda)). ⟲
File storage: the same move, with files in place of a database. ⟲
And now Salesforce’s Archive is the built-in option, keeping archived records reachable from Salesforce. Third-party tools such as GRAX are in the market too. ⟲
Test knowledge. Know the archive destinations and what big objects are: built for very large volumes (consistent performance from a million records to a billion); reached through Apex, APIs and their index, not the standard UI; object and field permissions only, no sharing rules; no triggers or flows. Know the alternatives: an external store through Salesforce Connect, and Salesforce’s Archive. ⟲
Il prodotto non è la lezione. Le caratteristiche sì: quanti dati, quanto spesso vengono recuperati, quanto in fretta devono comparire, se hanno bisogno di accesso relazionale, se gli utenti devono trovarli da Salesforce, se possono essere in sola lettura, chi può vederli, per quanto tempo si conservano, quanto costano e come verranno infine eliminati. Queste risposte scelgono la tecnologia. E ricorda: dove i dati vivono fisicamente e dove un utente può scoprirli sono domande diverse. La consegna di cinque anni fa non appartiene all’oggetto attivo. Non significa che l’assistenza clienti non debba poterla trovare.
L’archiviazione in tre passaggi
Sezione intitolata “L’archiviazione in tre passaggi ”When I’m moving large volumes out of an operational system, I don’t like copy, then delete in one step. There’s too much trust in it. And before the first real run, I rehearse it: a dry run that shows which records would move, ideally in a full copy sandbox, deleting nothing. Salesforce’s Archive app lets you preview an archive policy before you publish it (Archive App (si apre in una nuova scheda)), and other archiving tools offer a dry-run mode for the same reason. Then I use three steps: ⟲
- Copy and flag. Copy the records to the archive and mark them in the source as pending archive. Don’t delete anything yet. Now both copies exist. On the service chain, this was a batch that ran on the weekend. ⟲
- Verify. Re-query the source and the archive and prove the archive is right: counts, identifiers, relationships, totals or other reconciliation; can we retrieve them? For extra assurance, add checksums, or restore a sample back and compare it. Then flag them as validated. Trust but verify. Users still find the records in the source, because they aren’t archived yet. ⟲
- Delete and flip. Only after verification, and only for records that aren’t under a legal hold, delete the active records and mark the archive complete, so the search screens now pull them from the archive. The deletion doesn’t have to follow at once; it could happen a week later. ⟲
What could go wrong with one pass, copy and delete? It didn’t copy, and you’ve deleted the records. The point is that you don’t cross the destructive boundary until you’ve proved the copy. And with the states, you can report on every archive run. ⟲
This isn’t just my habit; it’s how the serious archiving tools work. Oracle’s archive and purge, for example, validates the records, copies them to archive tables, and then purges from what it archived, with a restart program for when a run fails partway (Archive and Purge (si apre in una nuova scheda)). Tools that copy and delete in a single pass come with a warning to test with a dry run first (AWS Prescriptive Guidance: Archiving data from unpartitioned tables (si apre in una nuova scheda)). Salesforce’s Archive app respects legal holds: records under a legal hold can’t be deleted or removed (Archive App). ⟲
Don’t cross the destructive boundary until you’ve proved the copy. ⟲
E progettalo per ripartire. Archivi 20 milioni di record e il job fallisce al record 14.382.711. Se la risposta è “si ricomincia da capo”, il progetto non mi piace. Le grandi operazioni falliscono: le connessioni cadono, i job vanno in timeout, un record strano lancia un errore. Il processo deve sapere cosa è già riuscito, ed è a questo che servono gli stati dell’archivio (in attesa, verificato, archiviato, fallito), così può ripartire senza duplicare dati, perderne, o eliminare qualcosa che non era stato archiviato in sicurezza. Su larga scala, la capacità di ripartire fa parte dell’affidabilità.
One more thing to know before you call a purge done: deleting the active records isn’t the same as erasing the data. Backups, caches, replicas and analytics copies may still hold it. That’s fine for an archive, and it’s exactly what chapter 5 asks you to account for when privacy law says the data must go. ⟲
Don’t Archive Everything Forever
Sezione intitolata “Don’t Archive Everything Forever”L’archiviazione può diventare una scusa per evitare di decidere di eliminare. “Potrebbe servirci un giorno.” Forse no. Il capitolo 5 chiede possiamo tenerlo? Questo capitolo aggiunge c’è valore nel tenerlo attivo? Alcuni record vanno in un archivio; alcuni vengono riassunti, alcuni anonimizzati, alcuni eliminati. L’obiettivo non è preservare ogni byte. È tenere ciò di cui il business ha legittimamente bisogno, per tutto il tempo in cui ne ha legittimamente bisogno.
I file cambiano il Numero di Zeri
Sezione intitolata “I file cambiano il Numero di Zeri ”Unstructured data is a different scale problem. Steve Trucking expects four to five million photos a year. Purely for magnitude, at about 4 MB a photo, five million is about 20 TB in one year, before growth. The real size will vary; the zeros tell you the binary content needs its own architecture. That’s why Checkpoint 1 separated the business record about a photo from the photo itself. Salesforce may need the photo’s type, its delivery, when and by whom it was taken, where it’s stored and its retention state, or even just a count and a “required photos complete” flag. The image belongs in storage built for millions of large objects. It’s the same principle as FleetLink’s GPS: keep in core what the operational process needs, and don’t copy every high-volume artifact into core because Salesforce takes part in the process. ⟲
L’archivio deve comunque essere sicuro
Sezione intitolata “L’archivio deve comunque essere sicuro ”Data leaving the active object doesn’t leave its security requirements behind. Redrock saw only Redrock’s deliveries while they were active; archive them, and Redrock still doesn’t get Keystone’s history. The archive needs an authorization model too, for Recipient personal data, photos, financial data, service history and agent access. A big-object archive doesn’t help on its own here: big objects don’t support sharing rules, so the access path you build has to carry the partner boundary. One design question for every archive: how do the original security requirements survive the move? The implementation may change; the requirement doesn’t. ⟲
Gli agenti e i dati archiviati
Sezione intitolata “Gli agenti e i dati archiviati ”Un destinatario chiede a un agente: “Dove è stato consegnato il mio frigorifero quattro anni fa?” La risposta esiste, ma è archiviata. L’agente deve poterla raggiungere? La mia posizione: è una decisione importante, e spetta al business. L’architetto espone le opzioni e quanto costa ciascuna: quale archivio, come lo raggiunge un agente, la latenza, il consumo, cosa può dire un agente sui dati vecchi, e i limiti di conservazione e privacy. Poi decide il business. Se i dati archiviati devono restare raggiungibili, costruisci un percorso di recupero autorizzato. Se no, lascia che sia il confine dell’archivio a imporlo. Quello che non voglio è che la tecnologia prenda la decisione per caso.
Oltre l’esame: cosa cambia l’IA. L’archiviazione ora include una decisione di contesto: se lo storico resta raggiungibile dagli agenti. Un archivio non fa automaticamente parte del contesto di un agente solo perché i dati esistono ancora. Porta la decisione al business, poi applica le stesse regole di autorizzazione e conservazione dell’accesso umano.
Steve Trucking: decidi il ciclo di vita prima che serva
Sezione intitolata “Steve Trucking: decidi il ciclo di vita prima che serva ”A cinque anni: circa 9 milioni di ordini di lavoro, 14,5 milioni di voci, milioni di foto, più lo storico degli stati e il GPS che abbiamo tenuto di proposito fuori dal core. Non voglio che Steve Trucking aspetti il quinto anno per decidere cosa significa “vecchio”. I periodi esatti magari non sono ancora fissati; va bene. Ma l’architettura dovrebbe già chiedersi: per quanto tempo una consegna completata resta operativa? Quali dettagli deve vedere subito l’assistenza clienti? Quando gli ordini di lavoro e le loro voci passano all’archivio, e dove? Quale storico appartiene a Snowflake? Dove vivono le foto vecchie, e quando vengono eliminate? Quali record archiviati vedono ancora i partner retail? Un agente può raggiungere le consegne archiviate? Non sono domande di pulizia. Sono domande di architettura.
Per ogni oggetto ad alto volume voglio cinque risposte. Quando smette di essere attivo? Dove va? Come dimostriamo che ci è arrivato? Come lo trova qualcuno dopo? Quando viene eliminato definitivamente? Se non sai rispondere a queste domande, non hai una strategia di archiviazione. Hai una speranza.
Five answers, or you have a hope. ⟲
Cosa decide qui un architetto
Sezione intitolata “Cosa decide qui un architetto ”- Il ciclo di vita attivo, archiviato, conservato ed eliminato di ogni oggetto ad alto volume, deciso prima che lo impongano spazio o prestazioni.
- Quali backup e quale ripristino devono essere in piedi prima di qualsiasi archiviazione o eliminazione distruttiva.
- Dove vivono i dati archiviati (big object, un archivio esterno tramite Salesforce Connect, l’Archive di Salesforce), in base a volume, recupero, latenza, sicurezza, costo ed eliminazione.
- Come le esecuzioni di archiviazione vengono verificate e rese capaci di ripartire prima che i record attraversino il confine dell’eliminazione.
- Quale contenuto non strutturato vive fuori dal core mentre il suo record di business resta in Salesforce, e se i dati archiviati restano raggiungibili dagli agenti.
Passiamo molto tempo su come i dati entrano in un sistema: API, importazioni, integrazioni, migrazioni, utenti, agenti. Passane altrettanto su come escono, perché i dati che creiamo oggi sono il problema di grandi volumi di domani. L’archiviazione magari non comincerà prima di tre anni. Il ciclo di vita dovrebbe esistere adesso. Progetta l’uscita quando progetti l’entrata.
Per approfondire
Sezione intitolata “Per approfondire ”- Trailhead, Explore Archival Versus Purge in Data Cleanup (si apre in una nuova scheda): back up before cleaning or moving data; archive versus purge, checked 2026-11-01. ⟲
- Salesforce Help, Archive App (si apre in una nuova scheda): archive policies and preview, job sessions, Log Failures and Continue, purge policies, legal holds, Archive Search and the Archive component, checked 2026-11-01. ⟲
- ISO, ISO 15489-1:2016, Records management: Concepts and principles (si apre in una nuova scheda) (current; confirmed 2021), checked 2026-11-01. ⟲
- Industry examples of the same pattern: Oracle, Archive and Purge (si apre in una nuova scheda) (Oracle Receivables: validate, archive, then purge from the archive tables, with a restart program), and AWS Prescriptive Guidance, Archiving data from unpartitioned tables (si apre in una nuova scheda) (a one-pass archiver; test with a dry run first), checked 2026-11-01. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (Winter ‘27): Best Practices (si apre in una nuova scheda), Deleting Data (si apre in una nuova scheda) and Best Practices: Deleting Data (si apre in una nuova scheda), checked 2026-11-01. ⟲
- Salesforce Help, Data and File Storage Allocations (si apre in una nuova scheda), checked 2026-11-01. ⟲
- Salesforce Help, Own From Salesforce Product Suite FAQ (si apre in una nuova scheda), and Salesforce, Own’s tools, now part of Salesforce (si apre in una nuova scheda), checked 2026-11-01. ⟲
- Salesforce Help, Salesforce Connect SQL Adapter for Amazon Athena (si apre in una nuova scheda), checked 2026-11-01. ⟲
- Salesforce Help, Choose Which Salesforce Connect Adapter to Use (si apre in una nuova scheda), checked 2026-11-01. ⟲
- Salesforce Developers, Big Objects Implementation Guide (si apre in una nuova scheda), checked 2026-11-01. ⟲
- SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy. ⟲