Why Coding Isn’t Scary: Simplifying Flows with Apex in Salesforce

For many Salesforce administrators, the idea of writing code might seem intimidating. However, with a little guidance, it can unlock powerful solutions that simplify complex use cases. Today, let’s explore an example challenge in event registration and how combining declarative tools with a bit of Apex code can make life easier.

The Use Case: Event Registration with Speaker Verification

Imagine you’re tasked with building a screen flow for event registration. Your flow needs to check if a user (represented by a Contact) is listed as a speaker for an event. In the client's custom data model, events can have multiple layers of speakers:

1. Speakers directly linked to the event.
2. Moderators assigned to tracks within the event.
3. Speakers assigned to sessions, which may have up to three per session.

You could handle this entirely with declarative tools like loops, decisions, and subflows, but things get messy fast - especially if the requirements expand to include other ticket types like exhibitors or members/non-members.

The Solution: A Flow Action with Apex

Instead of building a sprawling infrastructure of subflows, loops, and decisions, you can write a Flow Action in Apex. This reusable action simplifies your flow while maintaining flexibility for future requirements.

Why Use an Action?

• Efficiency: Replace multiple subflows with a single call to an Apex action.
• Scalability: Add more logic in Apex without modifying the flow structure.
• Reusability: Use the action across multiple flows and processes.

What the Action Does

The custom action checks if a specific Contact is a speaker for an event, whether directly or indirectly through related tracks or sessions. It provides a simple true/false response to the flow, streamlining the logic you need to implement on the screen.

How It Works:

1. The flow passes the Contact ID and Event ID to the action.
2. The Apex code:
   • Checks if the Contact is directly linked as a speaker to the event.
   • Verifies if the Contact is a moderator or speaker in tracks or sessions.
3. The result - whether the Contact is a speaker - is returned to the flow.

public class CheckContactSpeakerInEventAction {

   

    @InvocableMethod(

        label = 'Check Contact Speaker in Event'

        description = 'Determines if the specified Contact is a speaker in the given Event.'

    )

    public static CheckSpeakerResult checkSpeakerForEvent(CheckSpeakerRequest request) {

        Boolean isSpeaker = false;

        List<Speaker__c> speakerRecords = [

            SELECT Id

            FROM Speaker__c

            WHERE Contact__c = :request.contactId

        ];

        if (!speakerRecords.isEmpty()) {

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

            for (Speaker__c es : speakerRecords) {

                speakerIds.add(es.Id);

            }

            List<Event__c> matchingEvents = [

                SELECT Id

                FROM Event__c

                WHERE Id = :request.eventId

                      AND Speaker__c IN :speakerIds

                LIMIT 1

            ];

            if (!matchingEvents.isEmpty()) {

                isSpeaker = true;

            } else {

                List<Event_Track__c> matchingTracks = [

                    SELECT Id

                    FROM Event_Track__c

                    WHERE Event__c = :request.eventId

                          AND Moderator__c IN :speakerIds

                    LIMIT 1

                ];

                if (!matchingTracks.isEmpty()) {

                    isSpeaker = true;

                } else {

                    List<Event_Session__c> matchingSessions1 = [

                        SELECT Id

                        FROM Event_Session__c

                        WHERE Event__c = :request.eventId

                              AND Speaker__c IN :speakerIds

                        LIMIT 1

                    ];

                    List<Event_Session__c> matchingSessions2 = [

                        SELECT Id

                        FROM Event_Session__c

                        WHERE Event__c = :request.eventId

                              AND Speaker2__c IN :speakerIds

                        LIMIT 1

                    ];

                    List<Event_Session__c> matchingSessions3 = [

                        SELECT Id

                        FROM Event_Session__c

                        WHERE Event__c = :request.eventId

                              AND Speaker3__c IN :speakerIds

                        LIMIT 1

                    ];

                    if (!matchingSessions1.isEmpty()

                        || !matchingSessions2.isEmpty()

                        || !matchingSessions3.isEmpty()) {

                        isSpeaker = true;

                    }

                }

            }

        }

        CheckSpeakerResult res = new CheckSpeakerResult();

        res.isSpeaker = isSpeaker;

        return res;

    }

    public class CheckSpeakerRequest {

        @InvocableVariable(

            label = 'Contact Id'

            description = 'ID of the Contact'

            required = true

        )

        public Id contactId;

       

        @InvocableVariable(

            label = 'Event Id'

            description = 'ID of the Event'

            required = true

        )

        public Id eventId;

    }

    public class CheckSpeakerResult {

        @InvocableVariable(

            label = 'Is Speaker'

            description = 'True if Contact is a speaker for the Event (including related track or sessions)'

        )

        public Boolean isSpeaker;

    }

}

Benefits of Combining Declarative and Programmatic Tools

1. Simplified Flow Design: By offloading complex logic to Apex, your flow remains clean and easy to maintain.
2. Improved Performance: Apex handles backend checks more efficiently than flow loops, especially with large datasets.
3. Future-Proofing: As requirements evolve (e.g., adding more ticket types), you can extend the Apex logic without overhauling the flow.

Overcoming the Fear of Code

If you’re new to coding, Flow Actions like this one are a great way to start. They’re modular, focused, and designed to solve specific problems. Here are some tips to get started:

• Understand the Use Case: Break down the problem into steps before diving into code.
• Leverage Salesforce Documentation: Use resources like Trailhead to learn Apex basics.
• Start Small: Write simple actions and gradually add complexity as you grow more comfortable.
• Generative AI: Use the examples that can be built with ChatGPT, Copilot, Gemini, etc.

Key Takeaways

• Coding doesn’t need to be intimidating - it’s a tool to enhance what you’re already doing as a Salesforce admin.
• Combining declarative tools like flows with programmatic solutions creates powerful, maintainable processes.
• A well-designed Flow Action can save time, improve performance, and simplify your org’s architecture.

The next time you build a complex flow, consider how Apex can complement your declarative skills. Start small, experiment, and see how a little coding can go a long way in making your Salesforce solutions smarter and more efficient.

Let me know in the comments - what’s the first Flow Action you’d like to build?