#Apex49 人正在讨论

Hi @Hitesh Sharma

 You can handle this using an after-update Opportunity trigger + Queueable Apex. First, collect the unique Account IDs where the Opportunity changes to Closed Won, then pass those IDs to a single Queueable job. 

In the Queueable, query the related Accounts and Opportunities, determine the latest Closed Won Opportunity for each Account, and update the Account Description in one bulk DML operation. 

This approach avoids SOQL/DML inside loops and handles bulk updates safely. Salesforce recommends bulkifying both SOQL and DML operations. 

Also, use a Set<Id> for Account IDs to ensure the same Account is processed only once.  

Code: 

trigger OpportunityTrigger on Opportunity (after update) { 

    Set<Id> accountIds = new Set<Id>(); 

    for (Opportunity opp : Trigger.new) { 

        Opportunity oldOpp = Trigger.oldMap.get(

opp.Id

); 

        if (opp.StageName == 'Closed Won' && 

            oldOpp.StageName != 'Closed Won' && 

            opp.AccountId != null) { 

            accountIds.add(opp.AccountId); 

        } 

    } 

    if (!accountIds.isEmpty()) { 

        System.enqueueJob(new UpdateAccountDescriptionQueueable(accountIds)); 

    } 

} 

Then the Queueable can query the latest Closed Won Opportunity per Account and perform one bulk update on the Accounts. 

One important consideration: because the requirement is “latest Opportunity Name”, don't simply use the Opportunity from Trigger.new; if multiple Opportunities for the same Account are updated in the same transaction or an older Closed Won Opportunity already exists, the Queueable should determine the latest record from the database. 

This follows Salesforce's bulk-processing guidance and keeps the trigger lightweight.  

Hope This Helps!!

Hi Aakash, 

For an AI-based ticketing system in Salesforce, I would start with Service Cloud and Case Management, then learn AI Summary and Prompt Builder to understand how Salesforce can automatically summarize support tickets and generate useful insights. After that, focus on Knowledge, Similar Cases, and Case Retriever so the system can identify repeated or related issues from historical tickets and use previous solutions as context. Next, learn Service Assistant and Agentforce for Service to understand how AI can analyze cases, recommend resolutions, retrieve relevant Knowledge articles, and assist support agents. Finally, learn how to connect these capabilities with Flow and Apex so the entire ticket analysis and resolution process can be automated. For your use case, the most important areas to focus on are Prompt Builder, Similar Cases/Case Retriever, Service Assistant, Knowledge, and Agentforce, as these will help you build an end-to-end AI-powered ticketing solution.

Hi @Pranjal Budhlakoti, 

When one sObject variable is assigned to another, both variables refer to the 

same sObject instance

 in memory. 

For example:

Account acc1 = new Account(Name = 'Original');Account acc2 = acc1;acc2.Name = 'Updated';System.debug(acc1.Name); // Updated

Here, changing acc2.Name also changes acc1.Name because both variables reference the same Account object.

So, assigning an sObject variable does not create a new copy

 of the record; it creates another reference to the same object.  

Hope This Helps!!

Hi @Hitesh Sharma 

Yes, a trigger can perform DML on the same object, but it depends on the trigger context.

For example, in an after update Account trigger:

trigger AccountTrigger on Account (after update) {    for (Account acc : Trigger.new) {        acc.Description = 'Updated';    }    update Trigger.new;}

This update causes the Account trigger to fire again, which can lead to recursive execution and eventually a Maximum trigger depth exceeded error.

Also, in a before trigger, we normally modify Trigger.new directly without performing DML, because Salesforce automatically saves those changes as part of the original transaction.

So the best practice is: avoid unnecessary DML on the same records and use appropriate recursion-control logic when same-object updates are required.  

Hope This Helps!!.

Hi @Pranjal Budhlakoti, 

The first update acc; will execute successfully.

acc and accounts[0] reference the same Account record. The loop changes the Name to 'Final Account', so the first update saves 'Final Account'

. 

The second update accounts; will also execute successfully because it is a separate DML statement containing only one record. The Duplicate id in list error occurs when the same record ID appears multiple times in the same list being updated, not simply because the record is updated twice in separate DML statements.

So, the final Account Name will be 'Final Account'.

For Reference: Salesforce Apex DML documentation.  

Hope This Helps!!.

@Deepak Sharma 

Best practice is a Trigger Handler pattern with controlled recursion, rather than relying only on a static Boolean. 

•  Keep triggers thin and move logic into handler/service classes. 
•  Use a static Set<Id> to track records already processed in the current transaction. 
•  Keep all logic bulkified—use collections and avoid SOQL/DML inside loops. 
•  Add clear entry conditions so updates only happen when relevant fields actually change. 

A static Boolean can work for simple cases, but a

is more scalable for complex automation. 

@deeFor real projects, Database.insert(records, false) is useful when you want partial success—one failed record should not prevent valid records from being inserted.

Database.SaveResult[] results = Database.insert(records, false);
for (Integer i = 0; i < results.size(); i++) {
    if (!results[i].isSuccess()) {
        for (Database.Error err : results[i].getErrors()) {
            System.debug(
                'Failed Record: ' + records[i].Id +
                ' | Error: ' + err.getMessage()
            );
        }
    }
}

Use normal insert when the entire operation should succeed or fail together.

Use Database.insert(records, false) for integrations, data loads, or batch processing where you want successful records saved while capturing failures for logging/reprocessing.

Best practice: always process SaveResult[] and log the record ID, status code, and error message for failed records. 

Hi @Rohit ., 

acc.Contacts is available because the query uses a Parent-to-Child Relationship Query:

SELECT Id, Name,       (SELECT Id, Name, Department FROM Contacts)FROM Account

The child Contacts are retrieved as part of the same SOQL query and stored in the acc.Contacts relationship collection. Therefore, no separate SOQL query is required inside the loop. 

Regarding a large number of Contacts, the nested loop is valid, but retrieving every Contact just to count IT Contacts may be inefficient. If we only need the count, an Aggregate SOQL query

 with COUNT() and GROUP BY AccountId would be more efficient because the database performs the counting instead of Apex. 

So, use the relationship query when you need to process Contact records; use Aggregate SOQL when you only need counts/statistics

.  

Hope this help !!.