#Salesforce199 debatiendo

Hi @Santhosh Gorantala Good question!  

Testing Agentforce before moving to production is very important because, unlike traditional automation, the same question can be asked in different ways, and the agent may select different subagents or actions. 

I would recommend the following approach:

1. Testing Center: Use Agentforce Testing Center to test multiple user questions and validate whether the correct subagent and actions are selected.
2. Positive Scenarios: Test normal business scenarios with valid inputs and expected results.
3. Negative Scenarios: Test invalid inputs, missing records, incomplete information, and questions outside the agent's scope.
4. Permission Testing: Test with different user profiles and permission sets. Make sure the agent respects Salesforce security and doesn't expose restricted data.
5. Action Failure Testing: Check how the agent responds when Apex, Flow, or external API actions fail, time out, or return empty results.
6. Conversation Testing: Test follow-up questions, context switching, ambiguous requests, and multiple questions in the same conversation.
7. Session Tracing: Review session traces to identify incorrect subagent selection, action execution issues, and response-generation problems.
8. Regression Testing: Maintain a reusable set of test cases and run them whenever you modify agent instructions, subagents, actions, or grounding configurations.

When is an agent ready for production?

I would consider it ready when critical business scenarios pass consistently, security tests are successful, actions work reliably, and there are no unresolved high-severity issues. 

I also recommend starting with a limited group of users in production and monitoring the agent's responses before rolling it out to everyone. 

My suggestion: Don't test only whether the agent gives the correct answer. Also verify whether it selected the correct subagent, executed the right action, respected user permissions, and handled failures properly.

Hope this helps! 

Thank you, 

Venkat Yadav.

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 @Collin Thao

, 

1. Redesign roles around data visibility, not reporting lines.

Roles should be few and stable (e.g. by region, segment, or function), not one per manager or team. When a rep changes managers but stays in the same segment, nothing in Salesforce changes. A role hierarchy that mirrors the org chart is the usual cause of constant rework.  

2. Handle the "manager sees non-direct-report opps" exceptions outside the hierarchy.

This is the part that makes copying from AD unworkable, and it's best handled with sharing, not roles: 

• Owner-based sharing rules + public groups: "Opportunities owned by members of Group A are shared with Group B (Read Only)". Exceptions become group membership edits (about 30 seconds each).
• Opportunity Teams or manual sharing for one-off, deal-level cases.
• Optionally, delegate public group management to an ops lead through Delegated Administration, so it's not all on you.

3. Make the reorg itself a spreadsheet job, not a click-through.

Keep a template CSV (UserId, RoleId, ManagerId, public group membership). Export the current state, edit, and upsert with Data Loader (or Data Import Wizard for groups). Hours become minutes. A bulk reorg also triggers sharing recalculation, so use

(Setup) while you make the changes, then recalculate once at the end. 

Moving accounts between territories is rule-driven rather than person-by-person. It's a bigger project, so only worth it if that's what's actually changing. 

User.ManagerId drives approvals and similar features. Role drives record visibility and forecast rollups. Update them independently so you're not forced to restructure roles for a manager change. 

Trade-offs to know about 

• Sharing rules can't grant more access than the OWD allows to begin with. They only open it up, so this works if Opportunity OWD is Private or Public Read Only.
• Forecast rollups follow the role hierarchy. If non-direct-report managers need those rollups too, sharing alone won't give you that. You'd need a Forecast hierarchy or role adjustment.
• Changing the role structure itself is a visibility change org-wide, so test in a sandbox first and get sign-off before touching production.

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

Hi @Manohar Goud

This is a common issue when we work with multiple subagents and actions in Agentforce.

Here are a few things I would suggest: 

1. Clear Responsibilities: Give each subagent a specific job. Try to avoid overlapping responsibilities.
2. Proper Instructions: Clearly explain when to use a subagent, when not to use it, and what it should do.
3. Meaningful Names: Use clear names and descriptions for subagents and actions so Agentforce can understand their purpose.
4. Avoid Similar Actions: If two actions perform almost the same task, try to combine them or clearly separate their use cases.
5. Use Agent Script: For complex or critical scenarios, use conditions and explicit routing instead of depending completely on AI decisions.
6. Availability Conditions: Use available when conditions wherever applicable to control which subagents or actions can be selected.
7. Handle Unclear Requests: If the user request is confusing, let the agent ask a follow-up question instead of choosing the wrong action.
8. Test Multiple Scenarios: Test different ways users might ask the same question, including negative and overlapping scenarios.
9. Monitor Agent Behavior: Review session traces regularly to understand why a particular subagent or action was selected.

For example:

If we have three subagents for Order Inquiry, Order Cancellation, and Order Modification, each should have clear instructions about which requests it handles.

In my view, the best approach is to start with fewer subagents and actions, test them properly, and then gradually add more. 

One important point: Don't depend only on AI instructions for critical business processes. Use proper conditions, permissions, and validations to control execution.

Hope this helps! 

Thank you, 

Venkat Yadav.

@Guilherme Sequine Saquei! 

O evento chegar no flow e no Data Cloud confirma que o carrinho abandonado está entrando. A vitrine é outro passo: ela só repete os produtos quando o Repeater tem uma fonte, e cada campo de dentro (imagem, nome, preço e link) é merge field dessa mesma fonte. Com o layout estático, o teste envia o e-mail e a vitrine vem vazia ou fixa. 

O data graph só alimenta a vitrine quando ela está em Data Graph Attribute. Nesse caso ele precisa incluir o DMO dos itens do carrinho, no caminho Unified Individual → Unified Link Individual → Individual → itens, com nome, preço, imagem e URL marcados. O e-mail usa o graph padrão do Setup (Customer Engagement), salvo se tiverem colocado outro na própria mensagem. Esse graph atualiza na agenda, então o carrinho pode já estar no Data Cloud e ainda não estar disponível para a vitrine. Um graph só de perfil envia o e-mail e não tem linha de produto para repetir. 

Para esse teste, liguem a vitrine no evento, que é o payload que vocês já validaram. No e-mail, aba Data Sources, adicionem o evento de carrinho abandonado (o mesmo do flow). No Repeater, definam o Repeater Source nesse evento, nos itens do carrinho. Dentro da vitrine, a imagem entra como Merge field, e nome, preço e URL do botão também, todos dessa mesma fonte. Salvam e fazem o preview com a pessoa que gerou o evento. Se nome e preço aparecerem e a imagem continuar em branco, incluam o domínio da imagem em Setup → Trusted URLs.

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.

Hi @Scott Holmes

I would treat “task completed” and “desired outcome achieved” as two separate things. 

If the user made the call but reached voicemail, mark that task as Completed and capture the result in a field such as Call Outcome = Voicemail / No Answer / Connected. Then create a new follow-up task with the next expected contact date. 

When the actual conversation happens in September, log it as a new completed activity on that date. This keeps the activity history accurate and prevents users from accumulating overdue tasks for work they already performed. 

You can also enable Sort past activities by completed date under Activity Settings if you want completed activities in the timeline to reflect when they were actually completed rather than only relying on the original due date. 

So, for example:

March → Call completed → Outcome: Voicemail → Create follow-up task 

September → Conversation completed → Log new call/activity with September date 

This gives you a much cleaner activity history and reporting model.