Field Encryption

Leadflip supports field-level encryption for sensitive data. When enabled, field values are encrypted at rest using AES-256-CBC and decrypted only when displayed or exported. This helps you comply with privacy regulations and protect PII (Personally Identifiable Information).

What Encryption Does

• At rest – Encrypted fields are stored as ciphertext in the database. Without the decryption key, the data is unreadable.
• In transit – Leadflip uses HTTPS for all traffic; encryption adds a second layer for data at rest.
• On display – When you view a lead in the CRM, export data, or use the API, encrypted fields are decrypted on demand for authorized users.
• Per account – Encryption keys are scoped per account. Data from one account cannot be decrypted by another.

Which Fields Can Be Encrypted

• Custom fields – Text, textarea, and other types that store sensitive strings can typically be encrypted.
• System fields – created_at, updated_at, and source cannot be encrypted. They are required for core functionality.

Good candidates for encryption:

• Social Security Number (SSN)
• Bank account or routing numbers
• Driver's license numbers
• Passport numbers
• Medical or health information
• Other PII that must be protected at rest

Field properties: Each field has an is_encrypted property. When set to true, the field is encrypted using the account's key.

How to Enable Encryption

1. Go to Entities in the sidebar.
2. Select the Entity and open Edit → Fields.
3. Add a new field or edit an existing one.
4. Find the Encryption or Encrypt this field option.
5. Toggle it On.
6. Click Save.

Important: Enabling encryption on an existing field with data may trigger a one-time migration to encrypt existing values. Ensure no critical operations are running during this process.

Limitations of Encrypted Fields

Encrypted fields have important restrictions:

No Search

• You cannot search or filter leads by encrypted field values in the CRM.
• Full-text search will not match encrypted content.
• Use non-encrypted fields (e.g., a lead ID or name) for search and filtering.

No Sort

• You cannot sort leads by the encrypted field in the CRM or exports.
• Sorting is done on the encrypted value, which is not meaningful.

No SQL/JSON Queries

• Encrypted fields cannot be used in:
  • SQL WHERE clauses
  • LIKE / JSON_EXTRACT queries
  • Custom report filters that rely on direct field comparison

No Conditional Logic on Encrypted Fields

• Distribution rules, automation conditions, and automations that need to read or compare encrypted field values may not work as expected.
• If you need to route or automate based on sensitive data, consider using a non-encrypted proxy field (e.g., "Region" derived from encrypted address) or a separate automation step.

Export and API

• Exported data and API responses do include decrypted values for authorized users.
• Ensure you control who has access to exports and API keys when using encrypted fields.

Best Practices

• Encrypt only what's necessary – Over-encrypting can limit search, sort, and automation.
• Use clear labels – Mark encrypted fields in the UI (e.g., "SSN (encrypted)") so users understand they're protected.
• Separate searchable fields – Keep a non-encrypted "Search ID" or "Reference" if you need to find leads quickly.
• Audit access – Restrict CRM and API access to users who need to see decrypted data.
• Key management – Leadflip manages keys per account. Do not share account credentials; use role-based access instead.

Technical Details

• Algorithm – AES-256-CBC
• Key storage – Keys are stored securely and never exposed in logs or responses.
• Scope – Per account; keys are not shared across accounts.
• Integration – The LeadEncryptionService handles encrypt/decrypt automatically when reading or writing leads.data.

For implementation details, see the project's docs/Encryption.md and LeadEncryptionService.

When to Use Encryption

Use encryption when:

• You store SSN, financial data, or other regulated PII.
• Compliance (e.g., GDPR, HIPAA-like requirements) demands encryption at rest.
• Your policy requires sensitive fields to be protected beyond standard access controls.

Consider alternatives when:

• You need to search, sort, or filter by the field—encryption prevents this.
• The field is used in distribution rules or automation conditions.
• The data is low sensitivity (e.g., generic notes).

Disabling Encryption

Disabling encryption on a field will decrypt existing values and store them in plain text. This is a one-way operation from a security perspective: previously encrypted data becomes readable in the database.

• Only disable if you no longer need protection for that field.
• Consider the compliance and policy implications before disabling.

Next Steps

• Manage fields – Add or edit fields and toggle encryption
• Overview of Entities – Understand the full data model
• Review your account's security and access settings