> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # What is CRM? > Discover how the optional CRM layer enriches Midaz Ledger accounts with customer identity, contact details, and business context outside the ledger. CRM is **not part of the ledger's transactional domain**. It adds business attributes to ledger accounts. It does not change the ledger's logic, consistency, or performance. CRM is where user metadata lives. It does not hold balances, transfers, or fees. It records who is behind an account and what you need to run your business. ## Versioned with Midaz *** CRM ships inside the Midaz ledger and needs **no separate license**. Midaz is source-available. CRM shares the Midaz version. For example, Midaz `v3.5.0` uses CRM `v3.5.0`. CRM runs in the same binary as the ledger. It is always available. You choose whether to store holder data and call its endpoints. **Test CRM locally** You can run CRM with the Midaz stack locally, without Kubernetes, using our [plugins-docker-compose repository](https://github.com/LerianStudio/plugins-docker-compose). ## Why use the CRM? *** Midaz ledger accounts are generic by design. They are transaction-first and domain-agnostic. CRM adds meaning to those accounts and links each one to a user profile and a business context. You do not have to use CRM. You can adopt it later, only when your use case needs customer or business metadata beyond the ledger. ### Example use cases * **Banking (individuals and businesses)**: CRM stores identifiers like CPF or CNPJ, an address, contact details, or account numbers. Midaz runs the same transaction logic for both customer types. * **Supply chains (supplier, factory, retailer)**: CRM tracks metadata like supplier IDs, warehouse locations, or contract details. This data does not belong in the transaction, but it drives business decisions. CRM ships inside the Midaz ledger, so there is no separate service to deploy. Use it only if your product or regulatory context needs customer or business metadata. ## Entities *** CRM has two core entities: * **[Holder](/en/midaz/crm/holders)** – The main entity in CRM. It represents the persona for a Midaz ledger account. It stores identity attributes and individual traits. * **[Alias Account](/en/midaz/crm/alias-accounts)** – The business context for a [Ledger Account](/en/midaz/accounts) in **Midaz Ledger**. It holds financial details such as bank account information. *Figure 1* shows how the CRM entities connect to Midaz. How CRM entities, the Holder and the Alias Account, connect to accounts in the Midaz ledger ## Design principles *** CRM focuses on: * **Separation of concerns**: It keeps user profile data out of transaction logic. * **System performance**: It adds no user-level orchestration inside Midaz core services. * **Simpler deployment**: CRM ships inside the ledger binary, with no separate service to run. * **Clear domain boundaries**: It evolves with Midaz without coupling to ledger internals. CRM does not validate ledger-level rules or compliance processes such as KYC. It is a neutral, persistent data layer. ## API behavior *** CRM runs inside the Midaz ledger binary. It exposes a registry API for non-transactional data linked to Midaz accounts. * It does **not** enforce validations such as user status, risk profile, or document verification. * It is **agnostic to the asset, ledger, or grouping logic** used in Midaz accounts. * It gives consistent access to holder metadata without loading the transaction layer. ## Security & compliance *** Lerian ships Midaz and its components for on-premise deployment. **You keep control** of your infrastructure, compliance policies, and user-data lifecycle. CRM ships with Midaz and follows the same security standards as the rest of the platform: * **Data in transit**: Midaz encrypts it with industry-standard protocols. * **Data at rest**: Midaz protects it with encryption and fine-grained access control. You own encryption key management. Use a secret-management service to store, rotate, and control access to keys. You define and enforce your own policies for LGPD, GDPR, and other regional data-protection rules. CRM provides the structure. Review the [Security recommendations](/en/midaz/security-recommendations) before you deploy any component into your environment. Apply security best practices to every component — **Access Manager**, **Fees Engine**, **Pix**, and **CRM**. Secure network boundaries, manage secrets, apply patches, and enforce strict access control. ## Data deletion strategies *** CRM gives you full control over how it removes data. It offers two options: * **Soft delete** (default): CRM flags the record as deleted but keeps it in the database. Use it to keep an audit trail or to recover data later. * **Hard delete**: Where your policy permits removal, you can request deletion of the data. Physical removal depends on your retention, compliance, and legal-hold configuration. Your policies define the behavior. CRM adapts to your compliance requirements. ## Access control *** To restrict who can access your CRM data, enable our [Access Manager](/en/platform/access-manager/access-manager). ### Enabling Access Manager First, install **Access Manager**. Then open the Midaz ledger `.env` file and set these environment variables: ```text Text theme={null} ## AUTH --- PLUGIN_AUTH_HOST=http://plugin-auth:4000 PLUGIN_AUTH_ENABLED=true ``` After you enable it, CRM enforces access permissions from your authentication setup. Access Manager is available under the Enterprise model. To evaluate it, [contact our team](https://lerian.studio/contact). Ready to start? See [Getting started with CRM](/en/midaz/crm/crm-getting-started) for a step-by-step guide. ## Next steps *** Understand the key entities managed by CRM: Holders and Alias Accounts. Browse endpoints for holders, alias accounts, and related parties. Learn how to register holders and link them to ledger accounts.