Salesforce Data Cloud: Programmatic Implementation with Claude

Programmatic Salesforce Data Cloud implementation with Claude Code and MCP

Here is a run at configuring Salesforce Data Cloud identity resolution pipelines programmatically, with Claude Code and the Metadata Configuration Platform (MCP) rather than the UI. The goal was a complete pipeline built from scratch against a realistic dataset and an authoritative design document.

Setting up the development environment

The environment came first, and it was more approachable than expected for someone who is not a full-time developer:

• Install Claude Code through the standard CLI path.
• Clone the Data 360 MCP server and install its dependencies with Maven.
• Set up credentials: a Salesforce Connected App, a private key for JWT authentication, and a configuration file that points Claude Code at the MCP server.
• Run a simple metadata query to confirm Claude can see the org's Data 360 configuration.

That took under 30 minutes, including backtracking over a couple of forgotten steps. The MCP abstraction layer is what makes it painless. No REST endpoints, headers or API version strings to keep straight, just a conversation with Data 360.

The experiment: programmatic pipeline design and configuration

Step 1: data understanding and profiling insights

Nothing gets configured until the existing data is understood. Using earlier profiling results, stored in pnova__Profiling_Value_Results__c managed package objects and ingested into Data 360, Claude was asked to apply identity resolution best practices through a two-gate evaluation framework:

• A semantic gate, asking whether a field genuinely represents an individual rather than a role, a relationship or an organization.
• A quantitative gate, asking whether the data in that field is fit for matching, and flagging outliers that would produce false positives.

A custom Claude skill carrying Salesforce best practices and the author's own articles, such as "contact point mapping best practices", drove the analysis. What came back was a systematic, field-by-field evaluation across every identity resolution candidate on the Contact object.

Step 2: documenting key design decisions

On a serious implementation you have to be able to explain a decision six months later, so Claude was asked to document the outcomes of the field analysis: which fields go into identity resolution match rules and the rationale for each one, and whether source data could map straight to the target Data Model Objects (DMOs) or needed an interim transformation layer.

The reasoning held up on review. Three of the four target DMOs needed an interim transformation layer. The Contact object's email and phone fields in particular could not map directly to ContactPoint DMOs, for two reasons. One Contact record holds several email and phone fields while the canonical model expects one row per contact point, so those have to be normalized into multiple rows. And placeholder email addresses had to be filtered out before matching, or they would generate false positive matches.

This is better documentation than the UI usually leaves behind, because the rationale stays attached to the evidence.

Step 3: creating interim data structures (DLOs)

With the design settled, Claude used the Data 360 MCP to create three interim Data Lake Objects (DLOs), for email contact points, phone contact points and address contact points. Each mirrors the schema of the DMO it feeds, so the mapping after transformation is a straight line.

All three were created through the API and went ACTIVE quickly. This part of the process is reliable.

Step 4: designing transformation logic

Populating those interim DLOs was the hard part. Three things had to happen:

• Fan-out. Generate several output rows from one Contact row, one per email or phone type, each with a unique composite primary key.
• Filtering. Drop records with placeholder email values before they reach the identity resolution layer.
• Normalization. Standardize email casing, strip whitespace, and map country name variations onto canonical values.

Claude designed all of it: the fan-out patterns, the filter conditions, the normalization expressions and the composite key construction, each tied back to a specific field-level profiling finding. Then the request to create those transforms through the Data 360 MCP fell over.

The challenge: batch data transform API failures

The Batch Data Transform API returned errors on every payload variation tried, despite systematic and documented parameter combinations. Eight distinct attempts, using valid type identifiers (Stl, DcSql) taken from the API's own error messages, all failed, some as HTTP 400s with structured messages and some as HTTP 500s with opaque server exceptions.

The telling detail was a contradiction inside the API itself. Its validation layer accepted the precise type identifiers as valid, and its JSON deserializer then failed to resolve them. That is a platform-level inconsistency. No amount of fixing your payload gets past it.

The failure sat in one API endpoint. The design work, the field analysis, the transformation logic design and the interim DLO creation all succeeded, which is the part that says the methodology holds up. The DLOs were sitting there ready to receive data as soon as the transform layer started working.

Bug reporting and next steps

Rather than abandon the process, Claude was used to turn the whole thing into a structured API usability bug report:

• Full environment context.
• All eight payload attempts, with exact request structures and error responses.
• A comparison of expected versus actual behavior.
• A root cause hypothesis from the observed error patterns, specifically the mismatch between the validation and deserializer type registries.
• The business impact of the blocker.
• Notes for the engineering team, including the consistent internal error codes.

That report went to the product owner, who could diagnose it quickly and file an internal bug with the engineering team. A precise, reproducible description of the inconsistency is what moved it along. This is the underrated part of agentic work: the feedback it produces is specific enough to act on.