Records retention schedule by system: CRM, helpdesk, email and ERP

What is a records retention schedule by system?#

A records retention schedule by system is a matrix that maps every business application to the records it holds and the rules that govern them. A traditional schedule lists record categories, such as contracts or personnel files; a system schedule adds where those records live and the mechanism that keeps or removes them.

That second layer is what makes a policy work. A rule for customer correspondence means little if nobody has written down that the correspondence is spread across a CRM, a helpdesk, shared mailboxes and an ERP's customer notes, each with its own deletion behavior.

This page is general information, not legal advice. Retention periods depend on your industry, customer contracts and the jurisdictions you operate in, so set them with counsel and use the template for structure.

The template columns and what goes in each#

The template columns cover what a COO needs to operate the schedule and what a general counsel needs to defend it. Keep one row per system and record type pair, since a single system often needs several rows with different owners or triggers.

Sample rows for CRM, helpdesk, email and ERP#

Sample rows for the four systems most companies run show how differently one policy plays out in practice. The period column is left out on purpose; fill it in with counsel.

Notice that the triggers differ even inside one system. A CRM account and a closed opportunity start their clocks at different events, and an email platform usually applies rules per mailbox type rather than per message topic.

How to fill in the schedule system by system#

Filling in the schedule works best as a short interview with each system owner, using the same questions every time.

• 1List every system that holds business records, including retired ones still running somewhere and SaaS tools bought by a single team.
• 2For each system, name record types at the level people search for them: tickets, internal notes and call recordings, not just support data.
• 3Name an owner per row who can explain how deletion works in that tool.
• 4Write the retention trigger as an event the system records, such as ticket closed or invoice posted.
• 5Have counsel set the periods and note which contract or regulation drives each one.
• 6Test the deletion method once and record what it removes and what it leaves behind, such as attachments or audit entries.
• 7Record where every export, archive and backup sits, and give each its own row.

Where retention schedules break down#

Retention schedules usually break down in the copies, not in the primary system. Ad hoc exports on shared drives, a helpdesk export taken before a migration, old database backups and departed employees' mailboxes kept just in case all sit outside the rules unless the schedule names them.

Retired systems are the second gap. When a CRM or ERP is replaced, the old database often survives as a backup on a server nobody owns. Give each legacy archive a row with an owner and a decision date, and treat it like a live system.

Deletion itself is the third. Many tools soft-delete first, hold records in a recycle bin, or keep audit entries that still quote deleted text. HubSpot, for example, lets users restore deleted records and activities such as notes and calls for up to 90 days before they are permanently deleted. Zendesk admins can create ticket deletion schedules that delete archived tickets after a set period; deleted tickets cannot be restored, and the schedules keep deleting every ticket that matches. Record those behaviors in the deletion method column, and confirm that a legal hold actually stops automated deletion in each system.

Illustrative: one schedule across four systems#

Illustrative: a fictional B2B software company runs Salesforce for sales, Zendesk for support, Google Workspace for email and NetSuite for finance. A customer security questionnaire asks for its retention schedule, and the general counsel finds only a one-page policy listing record categories.

The COO and counsel build a system schedule in a few working sessions. They find that Zendesk has no deletion rule at all, that a full ticket export from an earlier helpdesk migration sits on a shared drive, that several founders' old mailboxes were kept indefinitely, and that NetSuite holds every transaction since launch.

Counsel sets periods by record class. The stray export moves into a controlled archive with an owner, the departed mailboxes get a documented decision, and Zendesk gets a rule that exports before purging. When the board later asks what support history could be reviewed for data licensing, the schedule already shows which years exist and where.

Retention, deletion and data licensing: how they connect#

Retention rules and data licensing connect in both directions. Records can only be licensed if they were kept, and a license may oblige the buyer to delete delivered data at the end of its term, which your schedule should track as an obligation of its own.

A system schedule also answers the first rights questions quickly: which records exist, under which customer terms they were collected, and whether deletion requests or holds apply. In the SourceX five-step transaction, that information feeds the Rights step, and anything licensed is documented in a SourceX Evidence Packet covering provenance, permitted use, the privacy record and release authorization.

Records under a deletion obligation stay out of scope whatever their potential value. SourceX begins with a metadata-only fit check, so no records leave your systems while you decide.