#Data Management107 diskutieren mit

 In my project, I encountered a similar situation where we were unable to promote Data Kits to other Salesforce instances, whether it was a Partial Copy or a Full Copy sandbox. We reached out to Salesforce Support, but they didn’t have a clue. From my perspective, combining Salesforce CLI, VS Code, and AI

is the best approach to successfully deploy Data Kits. 

The Issue

Salesforce generates a single package.xml file for the DevOps Data Kit. While it contains all the items required for deployment, the deployment itself fails due to underlying Salesforce platform limitations and bugs. 

The Resolution

1. Extract the Data Kit package.xml file.
2. Retrieve all metadata from your source organization.
3. Run a validation against the destination organization.
4. Capture all the deployment errors you receive.
5. Feed the package.xml and error screenshots into an AI tool, then ask it to split the main package.xml into smaller, logical parts for deployment. Note: This step involves some trial and error. If you are lucky, you will get it right on the first try; otherwise, it might take 2 to 3 iterations.
6. Deploy the single Data Kit in phases based on the split versions of the package.xml generated by the AI, bypassing the single-file method provided by Salesforce.

Additional Context

When you open a Salesforce Support ticket for assistance, they rarely know how to fix this particular issue. Eventually, they suggested we use Change Sets to promote the changes. However, manually selecting Data Kit dependencies is incredibly tedious—in our case, a single Data Kit had 1,000+ dependencies

. By using AI to break down the massive package into manageable parts, I successfully promoted our changes all the way to Production without any issues. 

Probable Root Cause

Salesforce launched Data Cloud in a rush. I noticed a very similar pattern when they launched Community Cloud back in 2013, where we faced persistent deployment issues for it all the way up until 2020 and the main issue was promoting dependencies in sequence. same we are noticing in data kit deployments. 

Hi @John C ,Hope your issue was resolved! 

I faced a similar issue, as org’s matching criteria allow only one lookup field per Matching Rule. 

So, you cannot include both Account and Contact lookup fields in a single matching rule. 

A possible workaround would be to create two separate Matching Rules for the junction object(which has 2 M-D relationship fields) , one using the Account lookup field and another rule using the Contact lookup field and associate both rules with the same Duplicate Rule

(Click add rule in Duplicate Rule ) configured to block duplicates. 

Ensure that both Matching Rules are activated for the Duplicate Rule.

One important consideration is the business requirement: 

• If the goal is to prevent duplicate Account-Contact combinations, both fields must match the existing record.
• If the goal is to prevent either Account or Contact from appearing more than once, the matching logic would be different.

Note that using two separate Matching Rules may not enforce the first requirement by itself, so test the configuration to ensure it behaves as intended. 

Thanks!!

Hi @Shiv Murti Pal

Although Account–Contact is a Lookup Relationship, Salesforce has a special cascade-delete behavior for standard Account and Contact records.

When an Account is deleted, its related Contacts are also deleted.

This is standard Salesforce behavior and differs from typical lookup relationships on custom objects. 

Hope this helps! 

I’ve often encountered situations when a SQL Server database stops accepting changes due to a full transaction log that results in an error LOG_BACKUP

. Although it may seem at first that the database is corrupt, in most cases, the problem is caused by transaction log backups or related issues preventing SQL Server from reusing space in the log. 

The first thing to do is to check the database recovery model and ensure that transaction log backups are properly maintained. To do that, open the Database Properties window in SSMS, select the Options page, and verify that the database is not in the Simple recovery model. 

If the database is in Full or Bulk-Logged recovery model, ensure that regular transaction log backups are being taken. You can also check the current log space usage with the following command: 

Then, execute the below query to see if your SQL Server instance waits to reuse the log: 

If the

, perform a transaction log backup: 

After that, repeat the previous steps to check the log space and wait descriptions. Do not change the database recovery model to Simple to resolve the issue “transaction log for database is full” unless you want to stop backing up the database. 

In most cases, users try to shrink the .ldf file right away when they see that the transaction log is full. Although it may give a quick fix, this is not an appropriate solution for resolving SQL Server log full errors. Moreover, it is not advisable to attempt to delete the .ldf file or use any other radical measures such as killing all queries or repairing the database with a limited understanding of the risks involved. 

Sometimes, long-running transactions, failed jobs, or replication processes can cause the log to fill up. If none of the suggested steps above works, check whether your database has not been physically corrupted or severely damaged. In such cases, the problem may not be related to the log and may require a different approach to resolve. 

Hi Anish,

That blink is the launcher hitting an error and the console closing before you can read it. On Windows, Data Loader starts from a batch file, so a double-click gives you a window that vanishes the moment Java fails.

Open Command Prompt, cd into the folder you extracted, and run dataloader.bat from there. If you installed with install.bat, run that the same way so the text stays on screen. Whatever line it stops on is the real failure. Wiping the old config won't show you that line.

Current Data Loader does not bundle Java. Salesforce's install notes say to install a Java 17 runtime first, 64-bit. Azul Zulu 17 is the one those notes point people at. Set JAVA_HOME to that JDK folder, put its bin directory first on PATH, then open a new Command Prompt. Run java -version in that window. If it isn't the Zulu 17 you just installed, the bat file is still seeing a different Java, or none.

The other thing that causes the same blink is the folder. Extract to a short path such as C:\DataLoader. Skip Program Files, OneDrive, and any path with spaces or non-English characters. If Windows blocked the zip, unblock it and extract again.

Config for a given version lives under your user folder in dataloader, then the version, then configs. Clearing that is fine, and it still won't open the GUI if JAVA_HOME is wrong. The write-up is Install Data Loader and Considerations for Installing Data Loader.

Hi Venkata, 

Best answer to your core ask: use Data Cloud's native Writeback feature (a Batch Transform/Data Transform with a Salesforce Object as the target), not a scheduled Flow. This directly solves your problem — it reads the entire DMO (all existing + new records) on a schedule, writes to CRM via Upsert matched on your key field (account_id), and isn't triggered by create/update events at all, so backfill and ongoing sync use the exact same mechanism. 

How to set it up: 

1. Data Cloud → Data Transforms → create a Batch Transform (or use an existing one) sourced from your DMO 

2. In the Writeback/target configuration: Target Type = Salesforce Object, select your account_data custom object 

3. Action Type = Upsert, map account_id as the matching key, map your other fields (e.g., model) 

4. Schedule the transform to run as often as needed (this is a genuine scheduled batch job on Data Cloud's side, not something bound by Flow governor limits) 

This directly answers your numbered questions: 

1. Recommended way: Writeback via Data Transform (above), not a flow-based approach, for anything beyond small volumes. 

2. Copy Field enrichment: works, but it's designed for real-time, per-record enrichment onto existing CRM records as they're viewed/queried — not a backfill mechanism for records that already exist and won't re-trigger. Not the right tool for "sync everything now." 

3. Scheduled Flow reading DMO at scale: it'll work for low volume, but Flow's Get Records/Update Records has standard governor limits (SOQL rows, DML rows per transaction) — it's not built for bulk DMO-to-CRM sync the way a Data Transform writeback is. Expect it to struggle or need batching logic once you're past a few thousand records. 

4. Correct — Copy Field enrichment is standard-objects-only. But Writeback via Data Transform is not restricted that way: Salesforce Object as Target Object explicitly supports custom objects, which is exactly your account_data case. 

For the one-time backfill specifically: you don't need Data Loader as a separate step — just run the Writeback transform once manually (on demand) for the backfill, then put it on a schedule for ongoing sync. Same mechanism handles both. 

Reference:

Hey Misty, 

Your read is accurate: per Salesforce's own docs, Related Record Matching is an org-wide, all-or-nothing setting, when it's on, ECI runs its own algorithm (participant email/domain matching against Contact, Lead, Account) and populates the Related Record field automatically. If you want to run your own Flow-based matching logic instead (your name-against-Contact/Lead + subject line idea), you have to turn Related Record Matching OFF entirely, then a Flow becomes the only thing setting that field. You can't layer a supplemental Flow on top of the native matching to "catch the extra 10-20%", it's one or the other, not additive. 

Given that, your options really are: 

1. Turn off native matching, build your own Flow to replicate ECI's built-in logic PLUS your extra fallback rules (name-against-Contact/Lead, subject line parsing). This means you inherit responsibility for the baseline matching ECI already does well, not just the edge cases, that's a bigger lift than it initially sounds. 

2. Keep native matching on, and instead build a separate Flow/batch job that runs afterward on unmatched records only, checking if Related Record is null, then applying your own supplemental logic to update it. This avoids fighting the native system since you're only touching records ECI already gave up on, not replacing its matching entirely. 

3. Turn on Einstein Activity Capture integration alongside ECI, per Salesforce's own guidance, this specifically enhances guest participant matching quality, which sounds directly relevant to your "joining from a car/conference room" problem, worth testing before building custom logic at all. 

On

or similar tools: since ECI's matching is a Salesforce-side process, not tied to which video/transcription vendor recorded the call, a third-party transcription add-on wouldn't conflict with ECI's matching logic, but it also wouldn't replace or feed into it automatically. It solves a different problem (better transcript quality) than record-matching itself. 

Given the scale you're describing, option 2 (supplement only nulls, don't disable native matching) is usually the least disruptive path, worth prototyping that before considering a full matching rebuild. 

Reference: