#Data Management88 personnes en discutent

Migrating your help desk to Service Cloud — whether from Zendesk, Freshdesk, Jira Service Management, or another platform — means bringing years of ticket history into an environment where Agentforce is either already running or about to be enabled.

Most admins treat that as a data transfer problem. Get the tickets across, map the fields, validate the counts, go live. Agentforce gets enabled after cutover and learns from historical data over time.

That expectation is the problem.

Agentforce trains on specific signals — and if those signals arrive in the wrong order, the accuracy baseline you establish on day one is the one you're remediating for weeks. The platform you're migrating from doesn't matter. The order and quality of what you bring across does.

Do you need an AI-ready migration or a Full Migration?

Go AI-ready first if:

• Agentforce is being enabled at or shortly after go-live
• You're migrating years of unresolved, mixed-quality, or inconsistently tagged ticket history
• Your KB articles reference outdated product or pricing information

Migrate everything at once if:

• Agentforce isn't being activated until months post-migration
• Your historical data is clean, consistently tagged, and recent
• You're under 10k records with solid CSAT coverage

If you're in the first group, a bulk migration before AI setup is the fastest way to establish a low-accuracy baseline that's hard to recover from. The AI trains on what arrives first — unresolved tickets, legacy pricing references, and low-rated interactions — and confidently learns the wrong patterns.

The sequencing that works:

KB articles first. Agentforce reads your Knowledge Base before it reads your tickets. KB content determines what the AI actually says in response — ticket history informs intent detection, but the KB drives response quality. Migrate every article, every language version, before a single ticket moves.

Before importing anything, disable all automations, triggers, outbound notifications, and surveys on the target org. Vendors claim this happens automatically during import. Verify it yourself.

Filtered tickets second. Not all tickets are equal training data. Three filters matter:

• Status: Resolved and Closed only. Open tickets have no confirmed resolution outcome — they add noise, not signal.
• Date range: Last 12–18 months. Older tickets reference product states and policies that no longer exist. Tighten to 6–9 months if you had a major product change recently.
• CSAT: 4 stars and above. High-rated interactions represent your team's best resolutions. Skip this filter if your CSAT data is sparse — a solid resolved-ticket dataset beats a thin filtered one.

Validate before cutover. Run a 50-ticket spot check on tickets you excluded from the filtered migration. You're checking two things: intent detection accuracy at ≥ 85% and zero KB hallucinations. If Agentforce references content that doesn't exist in your articles, your KB is incomplete or hasn't finished indexing. Don't cut over until you hit both thresholds.

After Agentforce is stable:

Run the full historical migration — remaining tickets, contacts, companies, and attachments. This isn't AI training data. It's agent context for when a customer references a conversation from two years ago, compliance records if GDPR or HIPAA apply to your org, and reporting completeness so your analytics aren't built on a partial dataset.

Watch your accuracy baseline as historical chunks come in. If it drops more than 5 percentage points from your validated benchmark after any batch, pause and audit that chunk before continuing. Old or low-quality tickets are usually the cause.

If you've hit Agentforce accuracy issues post-cutover, curious what you found during your root cause audit.

#Data Management

Have you ever had to reconstruct a Salesforce Setup Data Export after it was already downloaded?

I’m looking at a very specific post-export problem:

You already have the Salesforce Data Export ZIPs on disk — sometimes dozens of them — with Attachments / Documents / ContentVersion files named by IDs and split across multiple folders.

At that point, have you ever had to manually:

merge or search through multiple ZIPs,

rename ID-based files,

match them back to CSV rows,

deal with duplicate filenames,

identify missing/orphaned files,

or reconstruct a usable archive for a migration or handoff?

If yes, I’d love to know:

1. What did you actually do to solve it?

2. Roughly how long did it take?

3. Would you pay around US$69 once for a local tool that accepts the untouched export ZIPs, processes them together, reconstructs what can be safely reconstructed, and gives you readable files plus an audit report — without Salesforce login or API access?

I’m specifically interested in people who have already dealt with this problem, not general opinions about the idea.

We are currently building notification framework to monitor Data Stream errors in Slack.  

On the DataStream object we can identify records with the ImportRunStatus field having a value of FAILURE. However, we cannot find where the error message content is stored (likely a related object looking up to this DataStream)   

When failures occur, the error message is visible to be previewed while on the Refresh History tab as shown in screenshot. This is the text content we are trying to find within SF schema.  

According to this link: a DLO exists for Problem Records, but in Query Editor or Data Explorer cannot find nor query this DLO, for example PR_DLO_<DataStreamName> - in Query Editor we receive an Insufficient Access error. In data explorer that DLO is not able to be seen in the lookup.  

Has anyone else managed to find where this error message is stored?  

Thanks in advance!