DEV Community

Cover image for Prepare CRM field proposals before trusting an account-specific import
Tim Zinin
Tim Zinin

Posted on

Prepare CRM field proposals before trusting an account-specific import

A field named external_id looks plausible in a mapping document. That does not mean it exists in the customer's CRM, has the expected type, or can be written by the intended integration user. Separate the proposal from the account check. A mapping report can make values, omissions, and conflicts visible before an operator authorizes an import into a real account.

I maintain the us-brand-signal-crm-field-mapper Actor. This walkthrough describes its published build 0.3.1, inspected on 16 October 2026. The example below is synthetic and reviewed against that contract; it was not executed for this article. AI-assisted drafting was followed by a separate factual and editorial review.

The inspected CRM Field Mapper supports versioned target templates, including hubspot_v1_1 and salesforce_v1_1. They describe allowed mapping shapes, not authenticated connections. This example proposes an external identifier from a supplied opaque entity ID. The values object may be empty, but the row's identifier and evidence envelope fields are still required. No customer credentials or destination account are involved.

{
  "schemaVersion": "1.1",
  "target": "hubspot_v1_1",
  "mapping": [
    {
      "sourceField": "entity_id",
      "targetField": "external_id",
      "transform": "as_is"
    }
  ],
  "rows": [
    {
      "signalId": "sig-1",
      "entityId": "entity-1",
      "sourceEvidenceId": "ev-1",
      "sourceUrl": "https://example.com/e1",
      "observedAt": "2026-10-01T08:00:00Z",
      "values": {}
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

The proposal is only meaningful after a CRM owner checks the target schema. In particular, external_id and custom Salesforce-style fields are templates, not verified properties in every account. Current versioned mappings use brand_name to name for HubSpot and to Name for Salesforce. Do not assume older template names imply a working modern account integration.

The Actor allows a closed set of nine source fields, declared source-to-target pairs, and seven transforms. Mapping choices must be unique by source and target. Missing or null values produce omission evidence. When rows for one entity yield different transformed values, the report preserves a conflict rather than choosing whichever row happened to arrive last. The supplied entity ID itself is not resolved or authenticated.

Read entities[].proposals, conflicts, and omissions together. Then inspect unmappedTargetFields and counts. A proposal with an empty omission list is still not a successful CRM write. It only tells you how this bounded mapping processed the supplied packet. For an actual import, account-specific property existence, field types, write permissions, consent, and duplicate policies need their own checks.

The report carries separate input, mapping, entities, counts, and result digests. Archive the selected target template and schema version with them. Mapping order is canonicalized by target field; rows and entities have their own stable ordering. This makes changes inspectable without claiming that a source URL proves the evidence or that an entity identifier corresponds to a verified company.

A practical approval packet contains the mapping report, a small sample of proposed field values, and the target account's verified schema. Ask the CRM owner to resolve conflicts and confirm the exact import fields. Keep their decision outside the generated report. Only then should a separately authorized integration attempt writes and record accepted or rejected records from the CRM itself.

The Actor accepts 1–100 rows and 1–9 mappings within a 96 KiB input cap and 64 KiB report cap. Unique signal and source-evidence IDs protect the submitted packet from ambiguous repeats. No truncation is used to make an oversized proposal appear successful. If an account schema changes later, regenerate and review the mapping against that schema instead of treating a previously delivered proposal as permanent integration acceptance.

On the observed FREE pricing tier, one result-found event costs $0.01 for the complete useful report or plan, rather than each input row. FREE is the tier name, not a promise of free execution. Automatic Actor-start pricing is also present at $0.005 per GB, with a minimum of one event. Check the Actor page and your account tier before running; this is not a fixed total invoice, and a failed or repeated run may still incur applicable charges.

To try this deliberately, open the Actor page, select build 0.3.1, and submit the JSON as input. Set an explicit spending ceiling appropriate to your account; for example, $0.05 is a ceiling, not a quoted run price or a guarantee of a delivered report. Save the returned run ID and verify its immutable build ID. A local timeout does not cancel the remote run: inspect that same run before considering another attempt. Read the completed run's Dataset report and its separate OUTPUT receipt together; structural output is not independent source verification.

Top comments (0)