#Apex43 personnes en discutent

AI in Salesforce is getting much more practical, especially around Agentforce, support automation, and turning customer conversations into useful data. The key for me is making sure the AI output actually saves the team time rather than creating another layer to review. 

For service teams, call summarization is a good example because it can turn conversations into structured notes and keep Salesforce records updated with less manual work. I found this useful: AI Call Summarization for Salesforce Service Teams

 Hi, I would use normal DML when the operation must be atomic and either all records should succeed or none should. If one record fails, the entire DML operation fails and none of the records are committed.  

I would use Database.insert(records, false) for bulk processing where individual records can fail independently for example, integrations or data imports. It'll help to inspect Database.SaveResult for each record, capture the record's identifier and detailed Database.Error information, log failures persistently, and allow successful records to continue processing.

In this case Salesforce attempts to insert every record independently: 

•  Successful records are committed. 
•  Failed records are not committed. 
•  You get a Database.SaveResult for each input record. 
•  The Apex transaction itself doesn't fail simply because some records failed.

Hi Deepak - for grouping, Map<Key, List<T>> is almost always the right call. List<List<T>> is rarely right for grouping because you lose the key (no O(1) lookup - you would have to scan to find a group). 

When to prefer each: 

- Map<Key, List<T>>: anytime you group BY something, e.g. Map<Id, List<Contact>> keyed by AccountId. O(1) lookup, keys auto-dedup, and it is the bulkification backbone in triggers. 

- List<List<T>>: only when there is no meaningful key and the split is positional - fixed-size chunks for a callout that takes N records per request, or partitioning work across async jobs. You just iterate the sublists, never look up by key. 

Governor / performance: 

- The limit that actually bites is HEAP (6 MB sync / 12 MB async), driven by how many records you hold in memory, not the collection shape. Map's key overhead is negligible. 

- Map's real win is avoiding nested loops: correlating two lists via a Map is O(n); scanning a List<List<>> to find a group re-introduces O(n-squared). That is the real consideration. 

- Neither changes SOQL/DML limits - those depend on bulkifying, which you do either way. 

Pattern I use for grouping SOQL results: 

Map<Id, List<Contact>> byAcct = new Map<Id, List<Contact>>(); 

for (Contact c : [SELECT Id, AccountId FROM Contact]) { 

  if (!byAcct.containsKey(c.AccountId)) byAcct.put(c.AccountId, new List<Contact>()); 

  byAcct.get(c.AccountId).add(c); 

} 

Two more: for a true parent-child group, a subquery like [SELECT Id, (SELECT Id FROM Contacts) FROM Account] groups it at the query level - often cleaner. And for two dimensions, Map<Key1, Map<Key2, List<T>>> stays keyed and O(1). 

Net: default to Map<Key, List<T>> for grouping; reach for List<List<T>> only for keyless chunking. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks :)

Hello @Hitesh Sharma

Lists, Sets, and Maps are fundamental Apex collection types in Salesforce, differing primarily in how they organize, store, and retrieve data. 

1. List (Ordered Shopping List) 

   What it is: A row of items kept in the exact order you put them in. You can have identical items twice. 

   Salesforce Use Case: Holding a batch of records straight out of a database query (like a list of 50 new Contacts) where sequence matters. 

2. Set (Unique ID Bag) 

   What it is: A bag that holds items, but no duplicates are allowed. If you drop the same item in twice, it only stays once. 

   Salesforce Use Case: Collecting unique Account IDs from incoming records so you can search the database safely without running duplicate queries. 

3. Map (Name-to-Phone Number Directory) 

   What it is: A pair system where a unique "Key" points to a specific "Value" (like a person's name linked to their phone number). 

   Salesforce Use Case: Matching a record ID (Key) directly to its parent Account or Contact record (Value) for instant lookup. 

Best Practices 

- No Queries in Loops: Never run database queries inside loops; fetch data into a List or Map first. 

- Use Sets for IDs: Put record IDs into a Set when filtering via WHERE Id IN :mySet to keep code clean and fast. 

- Pick the Right Tool: Use a List for order, a Set for uniqueness, and a Map when you need to find a record instantly by its ID

Hi @Hitesh Sharma 

If you're completely new to Apex, I would recommend learning it step by step rather than trying to learn everything at once.

A good learning path is:

1. Programming fundamentals

• Variables and data types
• If/else and switch
• Loops
• Methods
• Classes and objects
• Collections: List, Set, Map

2. Salesforce fundamentals

• sObjects
• Object relationships
• SOQL
• SOSL
• DML
• Database methods
• Exception handling

Salesforce's Apex Basics & Database module is a good starting point. Apex Basics & Database — Trailhead

For SOQL, this is particularly useful: SOQL Queries in Apex — Trailhead

3. Apex classes

Learn how to build reusable classes and methods. Then understand:

• public, private, protected
• static
• Constructors
• Interfaces
• Inheritance
• Encapsulation

4. Triggers

After you are comfortable with classes, SOQL and DML, learn triggers.

Focus on:

• Trigger context variables
• Before vs after triggers
• Trigger handler pattern
• Bulkification
• Recursion control
• Moving business logic into classes

Salesforce recommends understanding Apex basics, SOQL and database concepts before triggers.

5. Governor Limits & Bulkification — VERY IMPORTANT

This is one of the biggest differences between normal programming and Salesforce development.

Always remember:

❌ Don't put SOQL inside a loop 

❌ Don't put DML inside a loop

Instead:

List<Account> accounts = [
    SELECT Id, Name
    FROM Account
    WHERE Id IN :accountIds
];
update accounts;

Learn to design your code for 1 record and 200 records from the beginning. Salesforce specifically recommends bulk operations to avoid governor-limit problems.

6. Apex Testing

Learn:

• @IsTest
• Test data creation
• Test.startTest()
• Test.stopTest()
• System.assert
• Positive/negative tests
• Bulk tests
• Testing exceptions
• Mock callouts

Don't write tests just to achieve 75% coverage. Test the actual business requirements and edge cases. Salesforce currently requires at least 75% Apex coverage for deployment, with every trigger having coverage.

7. Asynchronous Apex

Then move to:

• Queueable Apex
• Batch Apex
• Scheduled Apex
• Future methods

Understand when and why to use each one rather than just memorizing syntax.

8. Integration

Finally learn:

• HTTP callouts
• REST APIs
• JSON
• Named Credentials
• External Credentials
• Apex REST
• Authentication
• Callout testing with mocks

Recommended order

Programming Basics → Collections → sObjects → SOQL → DML → Classes → Exception Handling → Governor Limits → Bulkification → Triggers → Testing → Queueable → Batch → Scheduled Apex → REST/Callouts → Architecture

I would follow roughly 30% theory + 70% hands-on practice.

For example, don't just read about SOQL. Create Accounts, Contacts and Opportunities and write 20–30 queries yourself.

Official resources

• Apex Developer Guide — Salesforce — comprehensive reference covering Apex fundamentals, testing, governor limits, triggers, asynchronous Apex and more.
• Apex Basics & Database — Trailhead
• Apex Triggers — Trailhead
• Apex Testing — Trailhead
• Asynchronous Apex — Trailhead
• Apex Integration Services — Trailhead

Most importantly, build small projects while learning. For example: build an Opportunity management class → add a trigger → bulkify it → write test classes → add Queueable processing → expose functionality through a REST API.

That will teach you much faster than reading Apex syntax alone.

Hi Hitesh - yes, you can define the list inside the class instead of passing it from anonymous apex. A couple of ways: 

1) A no-argument constructor that builds the list itself: 

public class NewConstEx { 

  public List<String> subjects; 

  public NewConstEx() { 

    subjects = new List<String>{'Apex','LWC','JS','Java'}; 

  } 

} 

// Anonymous: 

NewConstEx n = new NewConstEx(); 

System.debug(n.subjects); 

2) Or initialize the field right at declaration (no constructor needed for that): 

public List<String> subjects = new List<String>{'Apex','LWC','JS','Java'}; 

When to use which: 

- Parameterized constructor (your current version) = the CALLER supplies the data. Best when different callers pass different lists, so it is more reusable. 

- No-arg constructor or field initializer = the CLASS owns the data. Best when the list is fixed/internal. 

And you do not have to choose - Apex supports constructor overloading, so you can keep BOTH a no-arg and a List<String> constructor in the same class and call whichever fits. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks :)

Hi @Hitesh Sharma

, I would suggest starting with Trailhead and then using the Salesforce Developer documentation as the reference. 

Please walktrough the trailhead modules mentioned below one by one, 

1.

2.

Recommended learning order is, 

1.  Basic SELECT / FROM
2. WHERE and operators 
3. ORDER BY / LIMIT
4. AND / OR / IN / LIKE
5.  Date and DateTime queries 
6.  Relationship queries — Parent → Child and Child → Parent 
7.  Aggregate functions — COUNT, SUM, AVG, MIN, MAX
8. GROUP BY
9.  SOQL in Apex + governor limits 
10.  Dynamic SOQL 
11.  SOQL vs SOSL 

you just walkthrough the trailhead and learn the topics one by one with handson excercise. This level of understanding is great to work in SOQL. 

Hope it works.