When to Use Apex and Flows of Action in Apex

Ever felt limited by Salesforce’s point-and-click features? Then dive into the world of Apex!

This powerful programming language empowers Salesforce administrators and developers to automate complex workflows, build custom applications, and extend Salesforce functionalities far beyond its out-of-the-box capabilities.

Whether you’re a seasoned pro or just starting your Salesforce journey, this blog will guide you through the use of Apex in Salesforce and when it becomes the ultimate tool to supercharge your Salesforce experience.

When to use Apex?

Salesforce lets you modify pre-made apps to suit your business. Apex in Salesforce and Lightning Components are two examples of technologies you can use to develop unique functionality and user interfaces for complex business processes.

Let’s look at when you should use Apex:

1. To create web services and email services.
2. To perform complex validations on multiple objects.
3. To perform complex business processes that Flow Builder doesn’t support.
4. To create custom transactional logic (logic that occurs over the entire transaction, not just with a single record or object).
5. Attach custom logic to another operation, such as saving a record, so that it occurs whenever the operation is executed, regardless of whether it originates in the user interface, a Visualforce page, or from SOAP API.

Apex Action in Flow

Apex is Salesforce’s proprietary programming language, which is used to create custom business logic in Salesforce. Below are the general apex actions in flow:

1. Trigger Execution

These are executed before and after any record is saved to the database. They are typically used to validate or modify record values before saving and log changes or update related records after saving.

2. Database Operations

Data Manipulation Language (DML) operations such as insert, update, delete, and upsert are executed to interact with the Salesforce database. Meanwhile, SOQL and SOSL Queries are used to retrieve data from the Salesforce database.

3. Execution Context

In a Visualforce page, Apex controllers handle user interactions and page logic using controller methods. The following actions are also included in the execution:

• Batch Apex: Handles large volumes of records asynchronously.
• Scheduled Apex: Allows you to run Apex classes at specific times.
• Queueable Apex: Allows job chaining and provides more complex job processing than future methods.

4. Business Logic Execution

Custom Methods are defined in Apex classes to encapsulate business logic. Validation Rules are custom logic to enforce data integrity, and Workflow Rules automate standard internal procedures to save time.

5. Exception Handling

Try-catch blocks are used to handle exceptions and errors in code execution gracefully.

6. Developer Action

When the developer writes and saves the code to the Apex platform, the platform application server compiles the code into a set of instructions that can be understood by the Apex runtime, interprets those instructions, and then saves them as compiled Apex.

7. End-User Action

When the end-user performs some action that involves the apex code or when the end-user triggers the execution of the Apex by clicking a button accessing a VF page or interacting with the lightning component, the platform application server retrieves the compiled instructions from the meta-data.

It sends it through apex runtime, which interprets it before returning the result. The end-user observes no differences in the execution time as compared to the standard application platform request.

Action Flow in Client-Server Interaction

1. Request: The client (user interface) sends a request to the Salesforce server. This could be a data query, a form submission, or any user action.
2. Processing: The application server processes the request. This may involve executing Apex code, querying the database using SOQL, or performing business logic.
3. Response: The server sends a response back to the client. This could include data to display in the user interface, confirmation of an action, or an error message.
4. Rendering: The client receives the response and renders it to the user. This might involve updating the user interface with new data, showing a confirmation message, or displaying error information.