Metadata in SaaS backups: why comments, fields and attachments matter more than you think

Ask what is in your CRM and you will hear about contacts and deals. But open any real record and look at what makes it useful: the comment thread explaining why the deal stalled, the custom field driving your reporting, the attachment with the signed quote, the link connecting the contact to the company. That surrounding layer is metadata, and it is precisely what disappears in most backup and export approaches. This piece explains what metadata means in SaaS platforms, where it silently gets lost, and how to judge whether a backup actually protects it.

What counts as metadata in a SaaS platform

In work platforms, five categories carry most of the value:

• Comments and updates: the decision trail. Often the only record of why something happened.
• Custom fields: your business logic encoded into the platform: deal stages, priorities, territories, statuses.
• Attachments: contracts, briefs, screenshots, deliverables, frequently existing nowhere else.
• Relationships: the links between records: contact to deal, task to project, item to linked board, record to record.
• History and assignments: who owns what, what changed, and when.

Lose the records but keep this layer, and you can reconstruct your business. Lose this layer but keep the records, and you have a phone book.

Where metadata quietly dies

CSV exports flatten everything. An export gives you field values in rows. Comments, attachments and revision history are simply absent, and relationships survive only as text labels with no functional links behind them.

Native deletion takes metadata first. As of September 2026: delete a Trello card and its comments and attachments are purged immediately and permanently, with no recovery window. Delete a ClickUp task and its time entries are permanently gone even though the task itself sits in the Trash for 30 days, and individually deleted attachments cannot be restored at all. Metadata consistently has weaker native protection than the records it belongs to.

Native restores drop the links. Restore a deleted Airtable record from base trash and the record returns with its field values, but connections to linked records are severed and must be rebuilt by hand. Restore a HubSpot contact and you may find its workflow memberships and parts of its activity timeline did not come along. The record is back; the context is not.

Snapshots are all-or-nothing. Airtable snapshots restore an entire base as a new copy. Getting one record's metadata back means restoring everything and manually copying across, losing every change made elsewhere since.

What metadata-aware backup looks like

A backup solution that takes metadata seriously shows it in the restore behaviour, not the marketing. Concretely, it should be able to restore comments back into the related task or record, reattach files to the item they belonged to, recreate custom fields together with their values across existing records, and bring a project or board back with its tasks, comments, files and field values as one coherent structure rather than a pile of rows.

This is where honesty about limits matters too. Every backup tool works through the platform's public API, and APIs do not expose everything: monday.com's API will not return files uploaded directly to an item, several Airtable computed field types (formulas, rollups, lookups) cannot be written back, and Asana's read-only computed fields are skipped on restore. A trustworthy vendor tells you exactly which metadata falls outside the API's reach for each platform, before you need to find out during an incident.

How to evaluate any backup for metadata coverage

1. Ask for the restore matrix. Which data types can be restored, at what granularity, and what returns with them?
2. Test a comment. Restore a deleted task on a trial and check whether its comment thread and attachments came back to the right place.
3. Check relationship handling. Restore a record with links and see whether the connections survive.
4. Read the limitations page. A vendor with no documented API limitations has not documented them, not escaped them.
5. Compare against your real dependency. List what your team would actually need after an incident: it is almost never just the field values.

Conclusion

Teams evaluate backup tools by asking whether their data is covered, and vendors answer yes, because the records usually are. The losses that hurt come from the layer around the records: the comment that held the decision, the attachment that held the contract, the link that held the pipeline together. Judge any backup, including ours, by what comes back attached to a restored record. That is where continuity actually lives.

‍👉 Start your 7-day free trial at ProBackup: https://app.probackup.io/onboarding

This guide is written for operations leads and IT decision-makers evaluating data protection for SaaS work platforms. Platform behaviour was checked against vendor documentation in September 2026 and may change.