#Apex58 人正在讨论

Hi @ROHIT PIPPERA

As a fresher, you don't need to be an expert in debugging, but you should know how to identify and troubleshoot common Salesforce errors. 

Focus on these key areas:

1. Debug Logs: Learn how to check logs and identify errors.
2. Flow Debug: Practice debugging Screen Flows and Record-Triggered Flows.
3. Apex Debugging: Understand System.debug(), exceptions, and common DML errors.
4. Permission Issues: Learn how to troubleshoot Profiles, Permission Sets, OWD, and Field-Level Security.
5. Validation Rules: Understand why records fail to save and how to identify the issue.
6. SOQL Errors: Practice identifying query errors and governor limit exceptions.

My suggestion: Create a few errors intentionally in your practice org and try to fix them yourself.

In interviews, don't just explain what Debug Logs are. Be ready to explain how you identified and resolved an issue. 

Practical troubleshooting skills will definitely help you stand out as a fresher. 

All the best!

Hi Ranjith, 

I don't think there's a hidden org-level switch for this. Your setup looks right, so I'd check the request side, since that's what gets rejected before Apex runs: 

1. Make sure client_id is ERP_Agent's consumer key, not Sales_Agent_Broker's. If "Require Secret for Token Exchange Flow" is on, send client_secret too.
2. Confirm Enable Token Exchange Flow is ticked in the OAuth settings and also on the policies side, then save.
3. Call your My Domain URL, never login.salesforce.com. You're already doing that.
4. If you pass token_handler, use the DeveloperName of the OauthTokenExchangeHandler record, not the Apex class name. If you leave it out, check that the handler is the one Salesforce falls back to.
5. Don't read the empty class trace as proof Apex isn't reached. Add a USER_DEBUG trace flag on the apexExecutionUser and the mapped user. You can also throw a custom exception on the first line of validateIncomingToken. If the error text changes, you're hitting Apex.

If all of that checks out and it's still a bare access_denied, open a Support case with the exact timestamp and your My Domain. They can see server-side logs we can't. 

Hope that helps!

Hi @Kushagra Rajput,

Your direction is right. Here is a simple way to build it.

1. Set up AWS SES first

• Verify your sender email or domain in SES.
• If your SES account is in sandbox mode, you can only send to verified emails, so request production access.
• Create an email template in SES. SendBulkEmail needs a template, even for a simple message.

2. Authentication from Salesforce

Use a

3. The API call

Send a POST request to /v2/email/outbound-bulk-emails (SES v2). One call accepts

4. Use Batch Apex

• Implement Database.Batchable<SObject> and Database.AllowsCallouts. Without AllowsCallouts, the callout fails.
• Run it with a scope of 50, so each execute makes one SES call.

apex

public class BulkEmailBatch implements Database.Batchable<SObject>, Database.AllowsCallouts {
    public Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator('SELECT Email FROM Contact WHERE Email != null');
    }
    public void execute(Database.BatchableContext bc, List<Contact> scope) {
        List<Object> entries = new List<Object>();
        for (Contact c : scope) {
            entries.add(new Map<String, Object>{
                'Destination' => new Map<String, Object>{ 'ToAddresses' => new List<String>{ c.Email } }
            });
        }
        Map<String, Object> body = new Map<String, Object>{
            'FromEmailAddress' => 'sender@yourdomain.com',
            'DefaultContent' => new Map<String, Object>{
                'Template' => new Map<String, Object>{ 'TemplateName' => 'YourTemplate', 'TemplateData' => '{}' }
            },
            'BulkEmailEntries' => entries
        };
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:AWS_SES/v2/email/outbound-bulk-emails');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'application/json');
        req.setBody(JSON.serialize(body));
        HttpResponse res = new Http().send(req);
        // check res.getStatusCode() and log failures
    }
    public void finish(Database.BatchableContext bc) {}
}

Run it with Database.executeBatch(new BulkEmailBatch(), 50);

5. Things to remember

• Check the response for each entry (the API returns a status per email), and log failures.
• Respect your SES sending rate limit.
• Handle bounces and unsubscribes (SES configuration sets with SNS can help).

Hope this helps. Share where you get stuck and I can help further.

You’re correct that there isn’t a direct trigger point here. ProcessInstanceWorkitem doesn’t support Apex triggers or record-triggered flows, and reassigning the approval doesn’t update the Case itself. 

If you need to keep the standard Reassign action, I’d handle it with scheduled Apex:

1.  Run a scheduled job every few minutes. 
2.  Query new ProcessInstanceStep records where StepStatus = 'Reassigned'. 
3.  Use ProcessInstance.TargetObjectId to identify the related Case. 
4.  Query the pending ProcessInstanceWorkitem for that process instance to get the newly assigned ActorId. 
5.  Insert a FeedItem with the Case ID as ParentId. 
6.  Store the processed ProcessInstanceStep.Id in a small custom log object with a unique/external-ID field. 
7.  Skip any step already in that log so rerunning the job can’t create duplicate Chatter posts. 

I’d also test it by reassigning the same approval twice and then running the job twice. The expected result should be two Chatter posts total, with no additional posts from the second job run. 

If real-time posting is absolutely required, the other option is to replace the standard Reassign experience with a custom Flow/LWC backed by Apex. That custom action would update ProcessInstanceWorkitem.ActorId and create the Case FeedItem in the same transaction. But the existing standard Reassign action can’t be intercepted directly.

Short answer: you generally cannot (and do not need to) write QuoteAccountId into the standard Quote.AccountId field. On the Quote object, AccountId is a system-derived, read-only reference that Salesforce fills from the related Opportunity's Account. It is not createable/updateable through the UI, Flow, Apex or the API, so an update like AccountId = QuoteAccountId will be rejected or ignored. For quotes created without an Opportunity, QuoteAccountId (label "Account for Quote") is the field Salesforce intends you to use as the account relationship. 

For your future Order process this is already covered: Salesforce's documentation for quotes without opportunities says associating the quote to an account is optional but recommended, because an account is required to convert the quote to an order. When you create an Order from such a quote, the account comes from the quote's account (QuoteAccountId), so you don't need Quote.AccountId populated. 

Practical recommendations: 

1. Make QuoteAccountId required (validation rule, e.g. ISBLANK(OpportunityId) && ISBLANK(QuoteAccountId)) so every quote can be turned into an Order. 

2. After enabling the feature, open Object Manager > Quote > Fields > Account for Quote and grant field-level security to your profiles/permission sets. It is hidden by default, which is why it often looks unavailable in Flow, reports and Apex. 

3. In reports, flows, sharing logic and Apex, use one source of truth, for example a formula field BLANKVALUE(QuoteAccountId, Opportunity.AccountId), so logic works for quotes with and without an Opportunity. 

4. If you create Orders yourself via Flow/Apex (rather than the standard Create Order action), set Order.AccountId = Quote.QuoteAccountId and Order.QuoteId = Quote.Id. 

References: 

Enable Quote Creation Without a Related Opportunity:

Release note, Create Quotes Without a Related Opportunity:

Quote object reference:

Assumption: the statement that Quote.AccountId is read-only is based on the Quote object reference field properties and commonly reported org behaviour; please confirm in a sandbox (e.g. attempt the update in a Flow or Developer Console) before designing around it.