Attachments and files in CRM: storage, limits and versioning without chaos

Why attachments become a problem

Attachments in a CRM almost always start "small": one scan, one contract, a couple of photos. After a few months it’s thousands of files sitting next to customer cards, invoices and tasks, managed by ad-hoc rules.

The file layer grows fast for a simple reason: it's easier for people to attach something “as is” than to decide where to put it, how to name it and which version is current. If rules aren’t set in advance, the system accumulates chaos automatically.

Typically it looks like this: files take a long time to open (especially from branches or via VPN), search is almost useless because of random names, duplicates appear (it's easier to upload again than find the original), it's unclear which version is current and who edited it. Often the same document exists in CRM, ERP and EDMS in different variants.

At the same time, systems have different requirements.

In CRM the file is needed “right now” next to a deal or request. So speed, simplicity and preview are important.

In ERP files are tied to accounting operations. There you need tracking, retention periods, role-based access and linkage to primary documents.

In EDMS the priority is compliance: versions, approval routes, signatures, immutability and provable history.

When all this is mixed without rules, risks grow: leaks due to overly broad permissions, viruses via uploads, lost edit history, extra storage and backup costs. In practice it looks like this: the contract is “probably available,” but it’s in three places and no one knows which copy is signed and which is a draft. For organizations with distributed structures—common among large companies and public-sector customers in Kazakhstan—this mismatch quickly turns into constant reconciliations and manual checks.

What to define before choosing a solution

Before choosing storage and enabling attachments in the CRM, list which files participate in your processes. For some it’s PDF contracts and invoices; for others—scans with seals, site photos, correspondence, exports from accounting, drawings. File types determine size, open speed, need for OCR and whether previews will work well.

Next, describe what people actually do with the files. “Upload and download” is rarely enough. Usually they need to find quickly, open without downloading, see the current version, compare changes, restrict access, and sometimes delete according to policy.

Consider working conditions: office, branches, remote employees, contractors. If a contract is scanned in a branch with unstable internet, plan for resumed uploads, integrity checks and clear error messages. If there are many workstations, verify that hardware and network handle mass previews and indexing (this is often critical for public organizations in Kazakhstan).

It helps to answer and record in advance:

• the 5–7 most common file types and their average size;
• which operations are daily necessities and which are rare but important;
• roles and access levels needed (who can view, edit, delete);
• retention periods, audit and logging requirements;
• mandatory integrations: CRM, ERP, EDMS, mail, scanners, MFPs.

A 1–2 page document like this saves time and makes the file layer predictable rather than a “black hole.”

Where to store files: main options

To prevent the file layer next to CRM from becoming a slow and costly warehouse, decide in advance where the actual file will live and where the metadata will be kept (what the document is, what it relates to, who and when changed it).

Option 1: store files inside the database

This is done when attachments are small and few, and integrity matters most: one backup contains both data and files. It’s convenient for scans up to a few megabytes, templates and small acts.

Drawbacks usually appear later: the database grows fast, backups become heavy, and updates, migrations and restores take longer.

Option 2: separate file storage alongside the DB

A common choice for large attachments. Files reside on a file server or dedicated storage, while the DB keeps a link and descriptive fields. The advantage is the database doesn’t bloat.

The downside is the need to diligently manage permissions and backups so “the link exists, the file doesn’t” doesn’t become normal.

Option 3: object storage

Suitable when there are many large files and load fluctuates. Object storage is easier to scale and is usually cheaper to expand than classic file servers. It fits previews, versions and serving files to different systems (CRM, ERP, EDMS) under unified rules.

The choice typically comes down to five questions:

• how many files and what average size will you have in a year;
• what speed is needed: upload, download, bulk operations;
• how are backups and recovery organized (how much can you afford to lose and how fast to restore);
• security requirements: encryption, isolation, audit, permissions;
• do you need horizontal scaling without downtime.

Keep metadata in the entity’s card: document, counterparty, deal, request. Example: the contract is stored in the storage, while CRM keeps the number, status, responsible person, deadlines, current version and list of related tasks. The file remains a “heavy object” in one place, while business logic stays where it belongs.

If you manage your own infrastructure, check whether the chosen model can handle growth. It's easier to plan disk and backup capacity in advance than to move terabytes in an emergency.

Limits and upload rules to avoid conflicts

If you don’t set rules in advance, working with attachments will quickly become a debate about why “it uploaded yesterday but not today” and who’s to blame: the user, the network or the system. Limits aren’t punishment—they make upload, backup, search and exports predictable.

Limits that actually help

A per-file limit is almost always necessary. “No limit” usually ends with someone uploading a multi-gigabyte video. That stalls processing queues, backups multiply and support gets stuck fixing uploads. Practical approach: set size limits by task type. Several dozen megabytes is enough for signed contract scans and acts; technical documentation or project archives may need more.

You also need an overall quota, otherwise one active department can consume the space. Quotas by role and context—user, department, project, entity type (deal, contract, ticket, equipment card)—are convenient: finance won’t argue with IT about “everything is full,” and admins can see which areas grow.

A minimal set of rules that reduces conflicts:

• allow clear formats (PDF, DOCX, XLSX, PNG, JPG) and block executables and containers (EXE, JS, BAT, ISO) unless there is an approval process;
• limit the number of files per upload to avoid clogging processing queues;
• show clear errors specifying what was exceeded (size, quota, file type);
• make role-based exceptions (e.g., lawyers can upload large packages but in a separate context);
• record who and when uploaded so disputes are resolved by logs, not conversations.

Another pain point is file names and path length. If users name files like “Contract (final) (really final) #12/3 dated 01.02.2026 version 7.docx”, exports, integrations and archiving break. A practical rule: short names without special characters and a clear template (date, number, counterparty).

Archive and retention periods

To stop storage from growing endlessly, set up auto-archiving: what counts as “inactive” (e.g., a deal closed 12 months ago), where it goes (archive storage) and what is deleted only according to policy.

Deletion should be rare and controlled; archiving should be bulk and safe. In public and corporate processes contracts and closing documents often must be kept for years, while temporary files (drafts, intermediate exports) can be removed sooner under clear rules.

Antivirus and security: minimum mandatory set

Files often enter the system from email, messengers and USB drives. If the attachment layer isn’t protected, an infection can start from a single invoice or scan.

Virus scanning is best performed at the entry point, before files become accessible to users and integrations. A “successful check” means more than a “clean” status: the antivirus engine was reachable, signature databases were up to date, the file was fully scanned and not skipped due to an error. If a check didn’t complete (no response, timeout, error), treat the file as suspicious.

Quarantine is always needed. This is a separate place for files that triggered rules or failed checks. Decide who makes the call—usually InfoSec or a designated admin, not the uploader. Inform the user with a simple message like “File under review,” without details that could aid an attacker.

Practical rules against dangerous types and macros:

• block executables and password-protected archives unless business needs require them;
• for Office files with macros use a special mode: only from trusted sources or only after manual approval;
• restrict double extensions (e.g., .pdf.exe) and overly long names;
• check file content, not just the extension (MIME/signatures);
• for external files force "read-only" on first open.

Event logs should answer “who, what and when”: who uploaded, from where, which file (hash, size), what the antivirus did, what was blocked, who released and why. This helps during incident investigations and disputes.

Agree in advance with InfoSec and legal on log and quarantine retention, notification procedures, access rules by role, and what counts as personal or confidential data and how it may be transmitted between CRM, ERP and EDMS. For public organizations and large companies in Kazakhstan this is especially important: audit and liability requirements are usually stricter.

Previews, OCR and search: so files can be found

If a user must download a file every time to check whether it’s the right one, chaos begins. Previews solve half the problem: the deal or contract card shows what’s inside the attachment. This is vital for PDFs, images, scans and office files.

Create previews automatically after upload: keep the original and generate a lightweight viewing copy (page images, reduced-size thumbnails). This saves time and reduces the chance someone opens a file on a personal device just to “take a look.”

OCR isn’t always necessary. If you have many scanned acts, invoices and letters, OCR brings real benefit: you can search by number, IIN/BIN, amount or company name. If most files are already digital (PDFs from accounting, ERP exports), OCR just consumes resources and budget.

To find a document in three months you need search across two layers: metadata and content. A minimal set of fields that usually helps:

• document type (contract, act, invoice, letter);
• number and date;
• counterparty and project;
• uploader and department;
• status (draft, signed, archived).

Index both text (after OCR or from native PDF) and key card fields. Then a query like “contract 17 from 12.03 with ТОО Альфа” will work even with different file names.

Heavy files (200 MB scans, photos, videos) shouldn’t “kill” the UI. Typical remedies: size limits, background processing (previews and OCR don’t block the user), and for very large attachments store them in a separate storage with the same access rules and fast thumbnails.

Scan quality affects readability and storage cost. A practical compromise:

• 300 dpi for documents with fine text, 200 dpi for simple forms;
• black-and-white or grayscale instead of color when seals and diagrams aren’t needed;
• compressed PDF rather than photos of each page at maximum quality.

Example: accounting uploads a scanned act, the CRM manager immediately sees a preview, search finds the act by amount after OCR, and a quarter later the lawyer retrieves the document by number and counterparty without sifting through dozens of similar files.

Versions and change history without confusion

A file version is the same document that changes over time: edits to text, details, amounts, signatures. A “new file” is a separate object: a different contract, appendix or act. Explain to users simply: if the meaning is the same it's a version; if the subject changed, it’s a new file.

To avoid confusion you need clear versioning rules. The version number should appear automatically and each version should have a short comment explaining what and why it changed. This reduces disputes and helps during audits: you see who edited, when and why.

A practical minimum that almost always works:

• auto-numbering: v1, v2, v3 or 1.0, 1.1, 2.0 (no manual entry);
• a short comment required when saving a new version (1–2 sentences);
• author and timestamp recorded automatically;
• one "current" version marked clearly and opened first;
• old versions are not deleted and remain available in the history.

The main cause of lost edits is parallel editing “on USB drives” and in messengers. Provide a simple locking mode: a user checks out a document for editing and others see it as locked. If collaborative editing is necessary, separate stages: drafts can be edited together, while the final is closed and can only be changed by creating a new version.

Set retention for old versions in advance: e.g., drafts 90 days, signed versions 5–7 years (or according to your policy). Access to the current version must be fast via the card, status and date.

For legally significant documents the rule is simple: you cannot replace a signed file. Only a new version with justification or a separate document (for example, an amendment) is allowed so the history stays honest and auditable.

Step-by-step plan to implement the file layer

Files rarely “break” the CRM by themselves. Usually order breaks: who uploads what, where it’s stored, how to search, what counts as the current version. Implement the file layer as a small separate project.

Steps to take in order

Agree on rules first, then enable features:

• Define scenarios and roles: who uploads, who edits, who approves, who has view-only access. Decide which files must be in the system (e.g., signed contract) and which can be kept outside.
• Choose a storage model and estimate volumes for at least one year: number of files, average size, peaks (quarter close, tenders). This determines budget, speed and infrastructure requirements.
• Configure limits and upload rules: allowed types, max size, number of attachments, duplicate handling. Add antivirus checks and quarantine.
• Enable previews and indexing so users can see content without downloading and search finds documents by fields and full text. Test on real documents, not only sample PDFs.
• Plan backups and recovery: it’s not just a checkbox—verify restore on a separate staging environment.

Then run a pilot. Take 1–2 processes (for example, contracts and invoices), launch with a small group, collect issues and only then scale. If your organization requires sovereignty and supply-chain transparency, run the pilot on your own infrastructure and verify how the file layer behaves under real loads and regulations.

Common mistakes that break everything

The file layer breaks not because of “technology” but because small decisions were never formalized as rules. As a result, access is random, structure varies, and “the latest version” differs by person.

Most common mistakes

The most dangerous habit is dumping everything into one folder "Misc" or a single "Files" field. Without structure (document type, process, owner, retention) permissions get lost and it’s hard to prove who uploaded what and when.

Second mistake: allow any file types. Executables, password-protected archives, macro files and junk enter the system. Infection and leak risks grow and security starts blocking everything.

Third: no agreement on versions. Without naming rules, statuses (draft, under approval, signed) and a change log, staff send files like "final_2_really_final" and then argue which is real.

Fourth: search only by file name. A month later you need an act by IIN/BIN, amount or contract number, but the file is named "scan_0312.pdf" and can’t be found.

Fifth: assuming backup is "set and forget." Until you test restore (with permissions, versions and links to cards) you don’t know if the system will recover after an incident.

Another risk: storing everything on a single server without growth and monitoring plans. Files grow fast and the problem is usually sudden: disk fills, performance drops and previews fail.

Short example: accounting uploaded a contract and signature scan, lawyers added edits, procurement saved their copy. Two months later an audit requests the original, approval history and final signed version; the system shows three different “finals” and no verified source.

If you treat this as a systems integration project, these mistakes are easier to catch early: document rules for file types, versions, search and recovery before the pilot, then open uploads to everyone.

Quick check: 10 minutes before launch

Before go-live, walk the path as a normal user: upload a document, open the card, view preview, download, update the version, try to delete. If there’s a snag here, after launch it becomes a flood of support requests.

10-minute checklist

Check six things that most often break operations:

• Limits: the maximum file size and total per object (deal, contract, request) are clear and exceeded uploads show a helpful message.
• Type control and scanning: forbidden extensions are blocked and antivirus scanning runs automatically before the file is available to others.
• Preview: common formats (PDF, images, office files) open for viewing without downloading or endless loading.
• Versions: the current version is visible, who and when uploaded an update is recorded, and you cannot accidentally overwrite an important file without trace.
• Access and audit: permissions match roles and downloads/deletions are logged.

Then run the often-skipped test: restore from backup on a staging system—not just "we have a backup" but a real recovery check: did the file, links to cards and versions come back?

A small scenario: a manager attaches a 25 MB contract, a lawyer opens preview and adds a new version, a director downloads it, and an admin restores a deleted file. If this flows without issues, go-live usually goes smoothly.

Example: one contract passing through CRM, ERP and EDMS

A typical situation: sales run the deal and correspondence in CRM, accounting issues invoices and closing documents in ERP, and legally significant contracts live in EDMS. Without rules you quickly get three copies with different edits and no one knows which is current.

A rule that often saves the day: “one source of truth for the final version.” Usually EDMS becomes that source because it handles approvals, signatures, retention and audit. CRM and ERP then store not the file but a link to the document card in EDMS plus metadata (contract number, counterparty, amount, status, term). This greatly reduces confusion around attachments.

How to distribute files

Drafts and working materials can be kept near where people work, but the final is single:

• CRM: commercial offers, correspondence, draft contract before approval, deal metadata.
• EDMS: contract versions, approval sheet, final PDF, signed copies.
• ERP: invoices, acts, postings, printable forms; the contract appears as a link and key details.

To avoid three copies, enforce unified rules: name template (e.g., Contract_Counterparty_Number_Date), versioning (auto-versions in EDMS or v1/v2/v3) and consistent role permissions. Sales get view access, lawyers edit during approval, accounting accesses the final.

User flow in reality

A manager uploads a draft in CRM and sends it for approval—the system creates a card in EDMS. The lawyer edits, each edit becomes a new version. Antivirus checks uploads, users see previews and search finds relevant items. After signing the status “Final” is set in EDMS and CRM/ERP are updated only with a link and key fields.

After launch measure a few metrics, otherwise issues are noticed too late:

• storage growth and forecast for 6–12 months;
• average time to open and generate previews;
• duplicate rate (by hash or matching name/metadata);
• number of antivirus blocks and types of detections;
• number of access conflicts ("I can’t open").

Next steps: lock in results and scale

To keep the file layer from becoming a mess, start with facts: how many files, which types, average size, how many scans, photos and archives. Then estimate growth for 12–24 months: new projects, branches, more users and more attachments per process.

Most important is agreeing on unified rules that work across systems (CRM, ERP, EDMS), not just in one. Otherwise people will find workarounds: duplicates, "final_new2" files and messenger transfers.

Ensure you’ve locked down at least:

• size and type limits and a clear path for “heavy” attachments;
• versioning rules: who can create a new version, how the final is named and what counts as a draft;
• retention and who triggers deletion or archiving;
• ownership: a process owner and a file-layer administrator;
• a short onboarding rulebook (1–2 pages, plain language).

Scaling is easier through pilots: one clear process (for example contracts or invoices), stable operation for 2–4 weeks, then the next process. This transfers rules gradually rather than forcing a big rework.

If infrastructure is the bottleneck, estimate it early. In Kazakhstan this is often solved on-premises: pick servers and storage for growth, then configure integrations and support. For example, GSE.kz as a domestic manufacturer and system integrator covers both hardware (servers, workstations) and implementation with 24/7 support, which is convenient when the file layer becomes business-critical.

A good sign you nailed it: a new employee understands in one day where a contract is stored, which version is current and who is responsible. If this happens without "personal folders" and chats, the system truly scales.