#Salesforce197 personnes en discutent

Hi @ROHIT PIPPERA

As a fresher, you don't need advanced knowledge of Salesforce security, but you should be strong in the basics. 

Focus on these key concepts:

1. OWD: Understand Private, Public Read Only, and Public Read/Write.
2. Role Hierarchy: Know how managers can access their team's records.
3. Sharing Rules: Understand how to provide additional record access.
4. Profiles: Learn about baseline user permissions.
5. Permission Sets: Know how to provide extra permissions without changing profiles.
6. Field-Level Security: Understand how to control field visibility and edit access.

My suggestion:

 Don't just learn definitions. Create a few users in a practice org and test different security scenarios. 

Interviewers may ask why two users with the same profile can see different records or why a user can view a record but cannot edit it.

If you can explain these scenarios confidently, you're well-prepared for fresher-level interviews. 

All the best! 

Thank you, 

Venkat Yadav.

Hi @ROHIT PIPPERA

Screen Flows are widely used in real-time projects to collect user inputs and automate business processes. 

I suggest practicing these scenarios:

1. Case Creation: Collect customer issues and assign cases to support queues.
2. Lead Assignment: Capture lead details and assign leads based on region.
3. Employee Onboarding: Collect employee information using multiple screens.
4. Opportunity Creation: Create opportunities using a guided Screen Flow.
5. Leave Request: Allow employees to submit leave requests.

For Screen Flow Distribution, focus on:

• Adding flows to Lightning Record Pages and App Pages.
• Launching flows using Quick Actions.
• Passing Record IDs using input variables.
• Using flows in Experience Cloud.

My suggestion:

 Start with Case Creation and Lead Assignment. Practice Decision elements, input validation, and fault handling. 

Don't just follow Trailhead steps. Build these scenarios independently in your practice org.

All the best!

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.

 One thing I would add is to treat credential rotation as a dependency-mapping exercise, not just a secret update. If several systems consume the same API credentials, documenting each integration, authentication method, owner, scopes, and last known usage can make future rotations much safer. This is especially important when APIs are being used across multiple workflows. For example, a nonprofit may have a verification service such as the Nonprofit Check Plus API connected to other systems, so keeping track of where credentials are used can prevent an unexpected integration failure after rotation. It’s also worth checking application and middleware logs for recent authentication calls before making the change. That can help identify less obvious consumers that may not be documented in Salesforce or Marketing Cloud. Once the new credentials are deployed, monitoring for authentication failures provides another layer of confirmation that no integration was missed. 

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.

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.