#Salesforce Developer468 utenti parlano di questo argomento

Você pode responder ao Marcos Gomes assim: 

Olá Marcos! Na minha experiência, o Trailhead é uma ótima base, mas eu não recomendaria estudar somente por ele. Além dos módulos relacionados à certificação, vale a pena seguir o Exam Guide oficial, praticar bastante em uma Developer Org/Trailhead Playground e consultar a documentação oficial da Salesforce nos tópicos mais importantes. 

Também acho útil fazer simulados para identificar os pontos fracos e se acostumar com perguntas baseadas em cenários. O mais importante é entender os conceitos e o motivo de cada resposta, em vez de apenas memorizar questões. 

Eu seguiria esta sequência: Exam Guide → Trailhead → Prática → Documentação → Simulados → Revisão. 

Assim, você chega na prova com uma preparação bem mais completa. 

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.

Thanks for testing those, Souvik - since browser, My Domain, and admin are all ruled out, that error is almost certainly coming from one specific org-wide setting: 'Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows' in Setup > OAuth and OpenID Connect Settings. 

Here's the trap: you mentioned enabling PKCE there. When that org-wide toggle is on, the org forces a code_challenge on every supported authorization flow - but the internal namespace-linking flow doesn't send one, so it fails with exactly 'missing required code_challenge'. So that setting being enabled is what's breaking the link, not something you're missing. 

The fix: turn that setting off (Setup > OAuth and OpenID Connect Settings) in the org that owns the namespace - and in the Dev Hub too if it's enabled there - then retry the namespace link. Once it's linked, you can switch it back on if you want PKCE enforced for your own apps. Note this org-wide toggle is separate from the greyed-out PKCE box on the Salesforce-managed connected app you can't edit - this one you do control. 

If it's already off and still fails, then it's on Salesforce's side (the managed linking app), and the right path is a Partner Support case referencing the error - it's a managed flow you can't patch yourself. But I'd bet on the org-wide setting; toggle it off and the link should go through. 

Hope that finally clears it! 

And if this resolves it, please mark it as the Best Answer so it helps the next person who hits this - thanks! 🙂

Trying this in 2026 it is possible to publish DataObjectDataChgEvent events in a test context. 

Test method.

@IsTest
    public static void testEventDataCloud() {
        Test.enableChangeDataCapture();
    	// Insert one or more test records
        DataObjectDataChgEvent de = new DataObjectDataChgEvent();
        de.ActionDeveloperName = 'Foo';
        //Database.SaveResult sr = EventBus.publish(de);
        Database.SaveResult sr = EventBus.publishWithAccessLevel(de, AccessLevel.SYSTEM_MODE);
        System.assert(sr.isSuccess());
    	// Deliver test change events
    	Test.getEventBus().deliver();
        List<Account> accs = [Select Id, Name from Account];
        Assert.areEqual(1, accs.size());
        Assert.areEqual(de.ActionDeveloperName, accs[0].Name);
    }

Trigger

trigger DataObjectDataTrigger on DataObjectDataChgEvent (after insert) {
    System.debug(Trigger.new);
    List<Account> accs = new List<Account>();
    for (DataObjectDataChgEvent event : Trigger.new) {
        // Read properties from the Data Cloud event payload
        String actionName = event.ActionDeveloperName;
        String currentValues = event.PayloadCurrentValue;
        // Fields populated by event publishing
        Assert.isNotNull(event.EventUuid);
        Assert.isNotNull(event.ReplayId);
        Account a = new Account(Name = event.ActionDeveloperName);
        accs.add(a);
    }
    insert accs;
}

I realise this usage to insert an Account based on the ActionDeveloperName is not how this event type would be used at all in reality, but it does show that the trigger is able to be exercised from an Apex test.