#AI63 diskutieren mit

Hi @Dan Humphries,

This is not available out of the box. The Salesforce hosted MCP tools work on records (SOQL and sObject reads). Files are stored in ContentVersion, and the actual content sits in the binary field VersionData. Claude can find the file, but it cannot read the text inside a PDF or Word doc.

Practical workaround:

1. Download the file with the REST API (/sobjects/ContentVersion/<id>/VersionData).
2. Extract the text with an external script or service (for example Python).
3. Save the text in a Long Text Area field on the Opportunity, or in a custom object.
4. Claude can then read that field through MCP like any normal field.

You can also build a Flow or Apex action that returns this text, and expose it as an MCP tool.

Official docs:

• Hosted MCP servers overview: https://developer.salesforce.com/docs/platform/hosted-mcp-servers/guide/hosted-mcp-servers-overview.html
• Server reference (list of tools): https://developer.salesforce.com/docs/platform/hosted-mcp-servers/references/reference/servers-reference.html
• sObject server details: https://developer.salesforce.com/docs/platform/hosted-mcp-servers/references/reference/sobject-all.html

Nice find. From what I've seen, you shouldn't assume Agentforce tracks who changed a field between steps. Agents reason over what their actions return and what's in the conversation, so if nothing re-reads the record, the agent's view is whatever it last saw or did. 

Patterns I'd use in Service Cloud: 

1. Re-read before acting. Design actions (Flow or Apex) to query the current record state at the start of each step rather than relying on what the agent did earlier. 

2. Make "who changed it" data. Turn on Field History Tracking for the key fields, and/or return LastModifiedById in your action, so the agent can see that a human edited the field. Then tell it in the instructions to treat a human edit as the source of truth. 

3. Add a verification step. After the agent writes a value, have an action confirm the saved value matches what it intended before it moves on. 

Your ActionTrace idea basically does #2 at the browser level. In the platform, the reliable version is to expose the change history through an action the agent can call.

Hi Chromer, This error usually happens when Salesforce doesn't allow changes to the current agent version. 

Try these steps:

1. Check if the agent is active. Deactivate it before making changes.
2. Refresh Agent Builder and try publishing again.
3. Check if any deployment or publishing process is still running.
4. If possible, try creating the agent again in a fresh Trailhead org.
5. If the issue continues, raise a Trailhead support case with the error and request ID.

It could also be a temporary Salesforce platform issue.

Hope this helps!

Hi @Santhosh Gorantala

This is a common challenge when customer data comes from multiple systems.

I would normally start by checking the match rules and source data quality.

A few things I would suggest:

1. Match Rules: Check whether the rules are too strict. Sometimes small differences in names, emails, or phone numbers prevent matching.
2. Data Quality: Look for missing values, duplicate records, extra spaces, and inconsistent formats.
3. Normalization: Try normalized email and phone matching where applicable.
4. Data Mapping: Make sure Individual, Contact Point Email, and Contact Point Phone are mapped correctly, including their relationships.
5. Ruleset Execution: Check whether the Identity Resolution ruleset completed successfully and review the processing results.
6. Reconciliation Rules: If records are unified but the expected field values aren't showing, check which source is given priority.

Simple Example:

One system has "Santhosh Kumar" and another has "Santosh Kumar". An exact name match may fail, but fuzzy matching could help identify them as the same person. 

My suggestion is to take 2–3 customer records that should match, compare their source values, and test the matching rules step by step. 

One important point: Match rules decide which records get unified, while reconciliation rules decide which field values appear in the unified profile.

Hope this helps! 

Thank you, 

Venkat Yadav.

Hi @Santhosh Gorantala

Good question! I think the main thing is to include only the data that Agentforce actually needs, rather than bringing everything into one Data Graph. 

A few things I would consider:

1. Business Use Case: First, understand what questions the agent needs to answer and what data is required.
2. Relevant Data: Include only necessary objects and fields. Avoid adding unnecessary information.
3. Relationships: Keep relationships simple. Too many related objects can make things complex.
4. Data Volume: Be careful with large datasets and historical records.
5. Performance: Test how quickly Agentforce can retrieve the required information.

For example, if we're building a customer support agent, I would start with Account, Contact, recent Cases, and Orders instead of bringing in the entire customer history.

And yes, adding too many related objects or attributes can increase graph size and potentially impact performance. 

My suggestion would be to start small, test with real-world scenarios, and add more data only when it's actually needed. 

At the end of the day, Agentforce needs the right information at the right time, not every piece of data available. 

Hope this helps! 

Thank you, 

Venkat Yadav.

Hi @Chandra Shekar

Good question! Trailhead is a great place to learn Salesforce, but working on complete projects will help you understand how things work in real companies. 

Here are a few things I would suggest:

1. Build Real-Time Projects: Start with projects like Student Management, Recruitment Management, or Customer Support Management.
2. Understand Requirements: Don't just create objects and fields. Think about the actual business problem you're trying to solve.
3. Practice Admin & Development: Work with security, Flows, validation rules, Apex, SOQL, and LWC based on project requirements.
4. Work on Real Scenarios: Practice bulk data uploads, error handling, record sharing, and approval processes.
5. Use GitHub: Upload your project code, requirements, screenshots, and documentation.
6. Join the Community: Participate in Salesforce community discussions, developer groups, and hackathons.
7. Practice Team Work: Learn how Jira, Agile, Scrum, Git, and deployment processes work.

My suggestion:

 Pick one project and complete it from requirement gathering to development, testing, and deployment. 

For example, build a Recruitment Management application where recruiters can manage candidates, schedule interviews, and track hiring status. 

Most importantly, during interviews, you should be able to explain what you built, why you built it, and how you solved the challenges. 

A complete hands-on project can give you much better practical understanding than completing multiple Trailhead modules alone.

Hope this helps!

Hi @Beth Marshall

, 

Yes, Agentforce can help here as a secondary review layer on top of your existing duplicate management. It shouldn't replace it. 

Matching rules identify potential duplicates, and duplicate rules decide what happens with them. Before adding AI, check whether the missed cases can be fixed with custom matching rules, since each duplicate rule can include up to three matching rules, with up to five active matching rules per object. Also confirm that records created through Data Loader, integrations or the API are covered, because those often bypass duplicate checks.

Community discussions note that simple fuzzy matching rules work for many cases but produce both false positives and false negatives. A duplicate job also runs only for the object defined in the matching rule. That is the gap an AI review layer can help with.

1. Candidate generation. A scheduled Flow or Batch Apex job finds possible matches using looser criteria than your matching rules, such as name variations, phone or email variations, address similarity, and shared parent account or contact details.
2. AI assessment. A Prompt Builder template, called from Flow or Apex, rates each pair as High, Medium or Low likelihood. It also lists matching and conflicting fields and gives a short rationale.
3. Flagging. Likely duplicates are saved to a review object (for example Duplicate_Candidate__c) with Record A, Record B, confidence, rationale and status.
4. User review. Users review the flagged pairs and decide to merge or keep them separate.
5. Optional agent. An Agentforce agent with an action like "Find possible duplicates for this record" can run the check on demand from the record page.

The overall flow is: Matching/Duplicate Rules → candidate check → AI scoring → user review → merge or keep. 

The AI should flag and explain, but never auto-merge. Merges are hard to undo, and AI rationale can be wrong. 

• Cost: Agentforce and prompt usage is metered, so limit how many pairs go to the AI.
• Data privacy: Review Einstein Trust Layer and data masking, because record data is sent to the LLM.
• Security: Sharing rules and field-level security must apply to reviewers.
• Native feature: I haven't found Salesforce documentation of a built-in Agentforce duplicate-detection feature, so this would be a custom build or an AppExchange product.
• Scoping: Which object (Account, Contact or Lead), roughly how many records, and is Agentforce with Prompt Builder licensed?

References

• Trailhead: Resolve and Prevent Duplicate Data in Salesforce: https://trailhead.salesforce.com/content/learn/modules/sales_admin_duplicate_management/sales_admin_duplicate_management_unit_2
• Salesforce Help: Matching Methods Used in Matching Rules: https://help.salesforce.com/s/articleView?id=sf.matching_rules_matching_methods.htm&type=5
• Trailblazer Community: Salesforce Duplicate Management group: https://trailhead.salesforce.com/trailblazer-community/groups/0F9300000001tavCAA
• Original question: https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000jAUao0AG

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.