#Data Management108 人がディスカッション中

@Max Jedrzejewski    Are any participants joining as guests or from a meeting room? Salesforce says ECI doesn’t receive their email addresses in those cases and treats the call as external.

Try a call with two employees logged into their company Google accounts. If the emails are still blank, raise an SF Support case with this example to check why they’re not coming through.

 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.