Security guide · Data scope
A CRM mirror should carry only the data the application can justify reading.
Security starts before the connection is configured. Define the product use case, limit the source identity, choose fields deliberately, and put the worker in the network boundary that matches the destination database.
Start with the reason a local row is needed.
Data minimization becomes practical when each field has a product reason. An account identifier and entitlement status may be necessary for a customer portal; a full Contact record might not be. Write down the application behavior, objects, fields, and retention expectation before setting up any source access.
This exercise also creates a cleaner mapping and simpler incident response. If a field is not needed for the application workflow, do not make it part of the mirror simply because it is available in Salesforce.
Use dedicated, least-privilege identities.
Run the sync with a dedicated Salesforce integration user rather than a personal administrator account. Grant only the selected object and field permissions, and validate the mapping under that identity. Do the same in the destination database: the worker should have access only to the mirror schema and the statements it needs to apply the sync.
Source: dedicated Salesforce integration user with the minimum selected-object and field permissions.
Destination: dedicated database user restricted to the mirror schema or tables.
Secrets: store credentials in the existing secret manager; rotate them through a tested runbook.
Review: revisit object/field scope when the application use case changes.
Put the worker where the destination is allowed to be.
For a cloud database with approved access, a managed connector may be the simplest path. For a private VPC, private subnet, or on-premises destination, run the worker inside the customer network. The worker can initiate outbound connections while the database remains off the public internet.
Document the actual egress destinations, database path, encryption requirements, and runtime owner. A worker in a private network still needs observability, patching, and a recovery plan.
Make the data path explainable.
Keep a useful activity record: connection configuration changes, mapped objects, source access failures, worker health, replay position, failed records, and reconciliation outcomes. This is not merely an audit feature—it gives the application and platform teams a way to answer why a local row is missing, stale, or different.
Do not place field values or work-email addresses into product analytics events. Track the operational shape of the sync—lag, counts, error categories, and consented conversion events—without turning analytics into another replica of CRM data.
Security checklist
Write the use case: tie every mapped object and field to an application behavior.
Limit identities: dedicated source and destination users with minimum privileges.
Protect transport and storage: use the encryption and secret-management controls your environment already requires.
Keep the destination private when needed: use a customer-network worker and outbound connectivity.
Retain evidence: mapping change history, sync health, failed-record context, and reconciliation outcomes.
Need to scope a private CRM mirror?
We can work from your application use case and network diagram to define the smallest safe first mapping.