CleanMerge Shared Data

Shared Data — CleanMerge

Reference content for the "Shared Data" section of the HubSpot Marketplace listing — describes exactly how CleanMerge's requested OAuth scopes are currently used. This is written to be accurate as of today's build, not aspirational.

Write scopes are back, and still not installer-facing. CleanMerge now requests write access to Companies and Contacts again to support two capabilities: the merge executor (finds and merges duplicate records) and a new warehouse-ingest pipeline (creates/updates records from a customer-configured data-lake query). Both remain reachable only via internal admin endpoints, configured per customer by CleanMerge's operator — not self-serve for installers. The scopes are requested because these capabilities are real, deployed, and actively used (just not yet installer-triggered), not held speculatively.

Contacts

Scope requested	`crm.objects.contacts.read`, `crm.objects.contacts.write`
Direction	Bidirectional
Fields	`firstname`, `lastname`, `email`, `phone`, plus any existing custom properties mapped during Warehouse Sync setup
How it's actually used	The CleanMerge: Normalize CRM Data workflow action does not call HubSpot's CRM API at all — HubSpot's own workflow engine passes the selected property's value into the action and writes the returned value back to whichever property the workflow is configured to update. CleanMerge never reads or writes a Contact record directly for this feature. The read/write scopes support two internal-admin capabilities: the duplicate-detection and merge engine (reads Contacts to find likely duplicates; on a human-approved or high-confidence match, normalizes and merges via HubSpot's Merge API), and the warehouse-ingest pipeline (reads Contacts to match incoming warehouse rows against existing records; creates a new Contact or updates a matched one; mapped properties must already exist in the customer's HubSpot, since CleanMerge does not create properties).

Scope requested

crm.objects.contacts.read, crm.objects.contacts.write

Direction

Bidirectional

Fields

firstname, lastname, email, phone, plus any existing custom properties mapped during Warehouse Sync setup

How it's actually used

The CleanMerge: Normalize CRM Data workflow action does not call HubSpot's CRM API at all — HubSpot's own workflow engine passes the selected property's value into the action and writes the returned value back to whichever property the workflow is configured to update. CleanMerge never reads or writes a Contact record directly for this feature.

The read/write scopes support two internal-admin capabilities: the duplicate-detection and merge engine (reads Contacts to find likely duplicates; on a human-approved or high-confidence match, normalizes and merges via HubSpot's Merge API), and the warehouse-ingest pipeline (reads Contacts to match incoming warehouse rows against existing records; creates a new Contact or updates a matched one; mapped properties must already exist in the customer's HubSpot, since CleanMerge does not create properties).

Companies

Scope requested	`crm.objects.companies.read`, `crm.objects.companies.write`
Direction	Bidirectional
Fields	`name`, `domain`, `phone`, plus any existing custom properties mapped during Warehouse Sync setup
How it's actually used	Same as Contacts above — the workflow action doesn't touch Company records directly; read/write is used by the merge engine and the warehouse-ingest pipeline.

Scope requested

crm.objects.companies.read, crm.objects.companies.write

Direction

Bidirectional

Fields

name, domain, phone, plus any existing custom properties mapped during Warehouse Sync setup

How it's actually used

Same as Contacts above — the workflow action doesn't touch Company records directly; read/write is used by the merge engine and the warehouse-ingest pipeline.

If/when this becomes installer-facing

The review queue, merge executor, and warehouse-ingest configuration are all real and deployed, but reachable only by CleanMerge's operator via internal admin endpoints today — not by installers. If/when any of these become self-serve, this page should be updated to reflect installers configuring and triggering them directly, rather than requesting it on their behalf.