DEV Community: Rohit Maharashi

Salesforce Rules Inference Engine – Version 1 (Field-Optimized Modular Approach)

Rohit Maharashi — Sat, 23 Aug 2025 05:32:27 +0000

This version of the rules engine is designed for clarity, modularity, and maintainability. It evaluates rules against SObject records in a scalable, bulkified manner, with optimizations to limit redundant field access and criteria evaluation.

Process & Architecture
High-Level Flow

Load Rules & Criteria: Retrieve all active rules and their associated criteria for the target object.
Organize by Field: Group criteria by the field they reference, so each field is only accessed once per record.
For Each Record:
- For each relevant field, evaluate all associated criteria.
- Store the result of each criterion (true/false).
- For each rule, substitute the results into the rule’s logical expression (e.g., 1 AND (2 OR 3)).
- If the rule expression evaluates to true, collect the rule as a match for that record.
Return Results: Output a list of matches (record, rule, and optionally actions).

Key Components & Code Snippets

A. RuleEngine (Entry Point)

public class RuleEngine {
    public static List<RuleMatchResult> evaluate(List<SObject> records, String targetObjectApiName) {
        RuleRepository repo = new RuleRepository();
        RuleExecutionContext context = repo.loadContext(targetObjectApiName);
        List<RuleMatchResult> results = new List<RuleMatchResult>();
        for (SObject record : records) {
            Map<Integer, Boolean> criteriaResults = CriteriaEvaluator.evaluate(record, context);
            for (RuleExpression ruleExpr : context.ruleExpressions) {
                Boolean matched = RuleEvaluator.evaluate(ruleExpr, criteriaResults);
                if (matched) {
                    results.add(new RuleMatchResult(record.Id, ruleExpr.ruleId));
                }
            }
        }
        return results;
    }
}

B. RuleRepository (Load & Organize Rules/Criteria)

public class RuleRepository {
    public RuleExecutionContext loadContext(String targetObjectApiName) {
        // Query active rules
        List<Rule__c> rules = [SELECT Id, RecordType.name, Status__c, Rule_End_Date__c, Rule_Expression__c, Rule_Name__c, Rule_Start_Date__c, Where_Clause__c, Fulfillment_Type__c, Rule_Criteria__c, Transaction_Type__c, 
                               Transaction_Subtype__c, Transaction_Status__c FROM Rule__c 
                               WHERE Status__c = 'Active' AND RecordType.name = 'Fulfillment Rules Engine'];
        Set<Id> ruleIds = new Map<Id, Rule__c>(rules).keySet();
        // Query criteria and junctions
        List<Rule_Criteria__c> junctions = [SELECT Id, RecordType.Name, Rule__c, Criteria_Number__c, Condition__r.Field_Name__c, Condition__r.Operation_Type__c, Condition__r.Value__c, Condition__r.Condition_Signature__c, 
                                           Condition__r.Field_Type__c, Condition__r.SObject_Name__c, Negate_Condition__c 
                                           FROM Rule_Criteria__c where Rule__c IN  :ruleIds];
        RuleExecutionContext context = new RuleExecutionContext();
        for (Rule__c rule : rules) {
            context.ruleExpressions.add(new RuleExpression(rule.Id, rule.Rule_Expression__c));
        }
        for (Rule_Criteria__c jc : junctions) {
            if(!context.fieldToCriteria.containsKey(jc.Condition__r.Field_Name__c)) {
                context.fieldToCriteria.put(jc.Condition__r.Field_Name__c, new List<RuleCriteriaWrapper>());
            }
            context.fieldToCriteria.get(jc.Condition__r.Field_Name__c).add(new RuleCriteriaWrapper(jc.Rule__c, Integer.valueOf(jc.Criteria_Number__c), jc.Condition__r.Operation_Type__c, jc.Condition__r.Value__c));
        }
        return context;
    }
}

C. RuleExecutionContext (Runtime Data)

public class RuleExecutionContext {
    public Map<String, List<RuleCriteriaWrapper>> fieldToCriteria = new Map<String, List<RuleCriteriaWrapper>>();
    public List<RuleExpression> ruleExpressions = new List<RuleExpression>();
}

D. CriteriaEvaluator (Evaluate All Criteria for a Record)

public class CriteriaEvaluator {
    public static Map<Integer, Boolean> evaluate(SObject record, RuleExecutionContext context) {
        Map<Integer, Boolean> result = new Map<Integer, Boolean>();
        for (String field : context.fieldToCriteria.keySet()) {
            Object actual = record.get(field);
            for (RuleCriteriaWrapper rc : context.fieldToCriteria.get(field)) {
                Boolean passed = evaluateCriterion(actual, rc.operator, rc.value);
                result.put(rc.criteriaNumber, passed);
            }
        }
        return result;
    }
    private static Boolean evaluateCriterion(Object actualValue, String operator, String expectedValue) {
        if (actualValue == null) return false;
        String a = String.valueOf(actualValue);
        String b = expectedValue;
        if (operator == 'equal_to') return a == b;
        if (operator == '!=') return a != b;
        if (operator == '>') return Decimal.valueOf(a) > Decimal.valueOf(b);
        if (operator == '<') return Decimal.valueOf(a) < Decimal.valueOf(b);
        // Add more as needed
        return false;
    }
}

E. RuleEvaluator & ExpressionResolver (Logical Expression Evaluation)

public class RuleEvaluator {
    public static Boolean evaluate(RuleExpression expr, Map<Integer, Boolean> criteriaResults) {
        String resolved = ExpressionResolver.substitute(expr.expression, criteriaResults);
        return ExpressionResolver.evalBooleanExpression(resolved);
    }
}
public class ExpressionResolver {
    public static String substitute(String expr, Map<Integer, Boolean> results) {
        for (Integer key : results.keySet()) {
            expr = expr.replaceAll('\\b' + String.valueOf(key) + '\\b', String.valueOf(results.get(key)));
        }
        return expr;
    }
    public static Boolean evalBooleanExpression(String expr) {
        expr = expr.replaceAll('AND', '&&').replaceAll('OR', '||').replaceAll('NOT', '!');
        // Note: For production, use a robust parser here!
        return Boolean.valueOf(evalWithCustomParser(expr));
    }
    private static Boolean evalWithCustomParser(String expr) {
        // Placeholder: implement or use a library for complex logic
        return expr.contains('true') && !expr.contains('false'); // naive
    }
}

F. RuleMatchResult (Result Structure)

public class RuleMatchResult {
    public Id recordId;
    public Id ruleId;
    public RuleMatchResult(Id recordId, Id ruleId) {
        this.recordId = recordId;
        this.ruleId = ruleId;
    }
}

🧮 Time Complexity (Optimized)

Where
N = Number of records to evaluate
R = Number of rules
C = Average number of criteria per rule
F = Number of distinct fields referenced across all rules
K = Average number of criteria per field (i.e., how many criteria reference the same field)

Pros

Modular & Maintainable: Each component is focused and testable.
Bulkified: Supports processing lists of records efficiently.
Field-Level Optimization: Only accesses each relevant field once per record, reducing SOQL and CPU usage.
Extensible: Easy to add new operators, criteria types, or actions.
Declarative Logic: Business logic is data-driven and manageable by admins.

Cons

No Cross-Record Memoization: If many records have the same field value, the same criteria may be evaluated repeatedly (less efficient for large, repetitive data sets).
Expression Evaluation is Basic: Current boolean logic parser is simplistic; complex nested logic requires a more robust solution.
No Early Rule Skipping: All rules are evaluated for all records, even if some could be skipped based on missing fields.
Not RETE-Optimized: Does not share evaluation work across records as in advanced rule engines.

When to Use

Moderate Data Volumes: When the number of records and rules is manageable, and field values are highly variable.
Simplicity & Maintainability: When code clarity and ease of maintenance are more important than maximum performance.
Foundation for Future Optimization: Can be incrementally improved (e.g., add memoization, postfix parsing) as needs grow.

Summary Table

Conclusion
Version 1 of the Salesforce Rules Inference Engine provides a clean, maintainable, and scalable foundation for rules evaluation. It is well-suited for most business scenarios with moderate scale and complexity. For enterprise-scale or highly repetitive data, further optimizations (as in Version 2) may be warranted.

For enhancements, consider adding:

Robust boolean expression parsing (postfix/infix parser)
Cross-record memoization for shared field-value evaluations
Early rule skipping based on required fields

Building a Configurable Rules Engine on Salesforce: A Modern Approach to Business Logic

Rohit Maharashi — Fri, 25 Jul 2025 04:15:16 +0000

Modern business processes demand flexibility, configurability, and reusability in automating decisions, validations, and actions across domains like entitlement assignment, pricing, fulfillment, and compliance. However, traditional hard-coded logic in Salesforce (Apex triggers, workflows, etc.) is often difficult to maintain and adapt as business requirements evolve.

Key Challenges

Lack of Flexibility: Hard-coded rules require code changes for modifications.
Redundancy: Similar logic is duplicated across objects and processes.
Limited Reusability: Conditions and actions aren’t easily shared or reused.
Business User Empowerment: Non-technical users can’t easily manage or update business rules.

Design Approach

To address these challenges, we propose a generic, extensible rules engine built on Salesforce custom objects. This engine enables administrators to define, manage, and execute rules declaratively, supporting a wide range of business scenarios.

Design Principles

Configurability: Business logic is defined via metadata, not code.
Reusability: Conditions (criteria) and actions are normalized and reusable.
Extensibility: The model supports new rule types, criteria, and actions without major redesign.
Maintainability: Centralized rule management reduces duplication and errors.

Data Model & Setup

Custom Objects Overview

Rule: Represents a business rule to be evaluated and executed.

Rule Name: Unique name of the rule.
Record Type: Categorizes rules (e.g., Entitlement, Fulfillment).
Status: Draft, Active, Inactive, etc.
Priority: Evaluation order.
Start/End Date: Optional effective/expiration dates.
Description: Rule description.
Rule Expression: Logical expression (e.g., 1 AND (2 OR 3)).
Where Clause: SOQL-style condition (optional).

Criteria (Condition): Defines an atomic, reusable condition.

Criteria Name: Name of the condition.
Record Type: Categorizes rules.
Description: What this condition checks.
Field Name: Field to evaluate (e.g., Asset.Product__r.Category).
Operator: =, !=, >, <, IN, CONTAINS, IS NULL, etc.
Value: Value to compare against.
External Id: Unique identifier (e.g., FieldName+Operator+Value).

Rule Action: Defines what happens when a rule matches.

Rule (Lookup): Parent rule.
Record Type: Categorizes rules.
Action Type: Create Record, Update Field, Assign Entitlement, etc.
Action Parameter: Parameter for the action (e.g., Fulfill Date).

Rule Criteria (Junction): Links rules to criteria, supporting complex logic and reusability.

Rule (Lookup): The rule this criterion belongs to.
Record Type: Categorizes rules.
Criteria (Lookup): The reusable condition.
Negate Condition: Negate the condition (NOT logic).
Criteria Number: For grouping/ordering in expressions.

Setup & Administration

Rule Management: Business users can create, edit, and activate rules via a custom Lightning App.
Criteria Library: Centralized management of reusable conditions.
Action Catalog: Define and manage available actions (e.g., field updates, record creation).
Validation: Ensure rules have at least one active criterion and action before activation.
Auditing: Enable field history tracking for change management and compliance.

Applications & Use Cases

This rules engine can be applied across multiple business domains, such as:

Entitlement Assignment: Automatically assign entitlements based on asset/product attributes.
Pricing Rules: Apply discounts or surcharges based on customer, product, or order criteria.
Order Validation: Enforce business policies before processing orders.
Fulfillment Routing: Route requests to the correct team or system based on type/status.
Compliance Checks: Ensure transactions meet regulatory or internal standards.

Example Flow

Trigger: An event occurs (e.g., order created).
Rule Evaluation: Active rules for the context are fetched and prioritized.
Criteria Check: Each rule’s criteria are evaluated using the defined logic.
Action Execution: If criteria are met, the corresponding actions are executed.

Extensibility & Future Enhancements

Criteria Grouping: Support for nested/complex logic (e.g., (A AND B) OR (C AND D)).
Action Chaining: Execute multiple actions in sequence.
Rule Sets: Group rules for batch processing or scenario-based evaluation.
Integration: Invoke external services or flows as actions.

Benefits

Agility: Rapidly adapt to changing business needs without code changes.
Consistency: Centralized logic reduces errors and duplication.
Empowerment: Business users can manage rules directly.
Scalability: Supports new rule types and actions as requirements grow.

Conclusion

A configurable rules engine on Salesforce empowers organizations to automate complex business logic with minimal technical overhead, ensuring agility, consistency, and maintainability as business needs evolve.

Have you implemented a rules engine in Salesforce or another platform? Share your experiences and thoughts in the comments!

Salesforce Apex Async Trigger Job Orchestration Framework

Rohit Maharashi — Sat, 12 Jul 2025 09:25:26 +0000

Overview

Salesforce triggers often require post-commit or heavy logic that exceeds synchronous limits. Queueable Apex is the preferred async solution, but Salesforce restricts you to one queueable enqueue per async context. This makes orchestrating complex, multi-step, or nested async logic challenging.

This framework solves those challenges, letting you:

Run multiple jobs in a strict order (even with sub-chains)
Support internal chaining (nested async flows)
Control job execution order and enablement via metadata (CMDT)
Reuse the pattern across any object or trigger
Stay governor-safe and testable

Architecture at a Glance

Trigger
  ↓
Trigger Handler
  ↓
AsyncWorkCollector.add(...)
  ↓
AsyncWorkCollector.flush()
  ↓
AsyncTriggerJobService.chainNextJob (entry point)
  ↓
  [JobA] → [JobB] → [JobC] → [JobC1] → [JobC2] → [JobD] → [JobE]
  (with support for sub-chains, e.g., C1→C2 as an internal chain)

1. Enum: AsyncTriggerJobType

Defines all possible jobs in your orchestration, including sub-chain jobs.

public enum AsyncTriggerJobType {
    A, B, C, C1, C2, D, E
    // Add more as needed
}

2. Custom Metadata (CMDT) Setup

Create a CMDT named Async_Trigger_Job_Configuration__mdt with fields:

Name: (matches enum value, e.g., C1)
Sequence__c: (integer, controls order)
Is_Enabled__c: (checkbox)
ObjectGroup__c: (e.g., Order)

You need one record per job type. Example:

(Name, Sequence, Is_Enabled, ObjectGroup) -> (A, 1, TRUE, Order)

3. Service: AsyncJobTypeToggleService

Handles enablement and ordering using CMDT.

public class AsyncJobTypeToggleService {
    // Checks if a specific job type is enabled (for a given object group)
    public static Boolean isEnabled(
        AsyncTriggerJobType type,
        Map<String, Async_Trigger_Job_Configuration__mdt> configs,
        String objectGroup
    ) {
        Async_Trigger_Job_Configuration__mdt config = configs.get(type.name());
        return config != null && config.Is_Enabled__c && config.Object_Group__c == objectGroup;
    }
    // Returns a list of enabled job types, filtered by object group and ordered by sequence
    public static List<AsyncTriggerJobType> getOrderedEnabledTypes(
        Map<String, Async_Trigger_Job_Configuration__mdt> configs,
        Set<AsyncTriggerJobType> candidates,
        String objectGroup
    ) {
        List<AsyncTriggerJobType> enabled = new List<AsyncTriggerJobType>();
        for (AsyncTriggerJobType type : candidates) {
            Async_Trigger_Job_Configuration__mdt rec = configs.get(type.name());
            if (rec != null && rec.Is_Enabled__c && rec.Object_Group__c == objectGroup) {
                enabled.add(type);
            }
        }
        enabled.sort(new AsyncJobTypeMetaComparator(configs));
        return enabled;
    }
    // Comparator for sorting by Sequence__c
    public class AsyncJobTypeMetaComparator implements Comparator<AsyncTriggerJobType> {
        private Map<String, Async_Trigger_Job_Configuration__mdt> configurations;
        public AsyncJobTypeMetaComparator(Map<String, Async_Trigger_Job_Configuration__mdt> configurations) {
            this.configurations = configurations;
        }
        public Integer compare(AsyncTriggerJobType typeA, AsyncTriggerJobType typeB) {
            Async_Trigger_Job_Configuration__mdt recA = configurations.get(typeA.name());
            Async_Trigger_Job_Configuration__mdt recB = configurations.get(typeB.name());
            Integer seqA = recA != null ? Integer.valueOf(recA.Sequence__c) : null;
            Integer seqB = recB != null ? Integer.valueOf(recB.Sequence__c) : null;
            // If seqA is null, place it after seqB
            if (seqA == null) {
                return 1;
            }
            // If seqB is null, place seqA before seqB
            if (seqB == null) {
                return -1;
            }
            // Compare sequence values
            if (seqA < seqB) {
                return -1;
            } else if (seqA > seqB) {
                return 1;
            } else {
                return 0;
            }
        }
    }
}

4. Data Container: AsyncTriggerJobBundle

Tracks the jobs, their order, and supports internal chaining.

public with sharing class AsyncTriggerJobBundle {
    private Map<AsyncTriggerJobType, Object> jobMap;
    private List<AsyncTriggerJobType> orderedTypes;
    private Integer currentIndex = 0;
    private AsyncTriggerJobBundle continuationBundle;
    public AsyncTriggerJobBundle(Map<AsyncTriggerJobType, Object> jobMap, String objectGroup) {
        this.jobMap = new Map<AsyncTriggerJobType, Object>(jobMap);
        Map<String, Async_Trigger_Job_Configuration__mdt> configs = Async_Trigger_Job_Configuration__mdt.getAll();
        this.orderedTypes = AsyncJobTypeToggleService.getOrderedEnabledTypes(
            configs,
            new Set<AsyncTriggerJobType>(jobMap.keySet()),
            objectGroup
        );
        this.currentIndex = 0;
    }
    public void setContinuationBundle(AsyncTriggerJobBundle bundle) { this.continuationBundle = bundle; }
    public AsyncTriggerJobBundle getContinuationBundle() { return this.continuationBundle; }
    public Boolean hasMoreJobs() { return jobMap != null && currentIndex < orderedTypes.size(); }
    public AsyncTriggerJobType getNextJobType() { if (!hasMoreJobs()) return null; return orderedTypes[currentIndex++]; }
    public Object getPayloadFor(AsyncTriggerJobType type) { return jobMap.get(type); }
}

5. Collector: AsyncWorkCollector

Gathers jobs during the trigger and starts the async chain.

public class AsyncWorkCollector {
    private static Map<AsyncTriggerJobType, Object> jobRegistry = new Map<AsyncTriggerJobType, Object>();
    private static Boolean flushed = false;
    public static void add(AsyncTriggerJobType jobType, Object payload, String objectGroup) {
        // ...enablement check...
        jobRegistry.put(jobType, payload);
    }
    public static void flush(String objectGroup) {
        if (flushed || jobRegistry.isEmpty()) return;
        flushed = true;
        AsyncTriggerJobBundle bundle = new AsyncTriggerJobBundle(jobRegistry, objectGroup);
        AsyncTriggerJobService.chainNextJob(bundle, objectGroup);
    }
    public static void reset() {
        jobRegistry.clear();
        flushed = false;
    }
}

6. Chaining & Orchestration: AsyncTriggerJobService

Encapsulates chaining logic and internal sub-chain orchestration.

public class AsyncTriggerJobService {
    public static void chainNextJob(AsyncTriggerJobBundle bundle, String objectGroup) {
        if (bundle != null && bundle.hasMoreJobs()) {
            AsyncTriggerJobType nextType = bundle.getNextJobType();
            Object nextPayload = bundle.getPayloadFor(nextType);
            Queueable nextJob = AsyncTriggerJobFactory.createJob(nextType, nextPayload, bundle, objectGroup);
            if (nextJob != null) {
                System.enqueueJob(nextJob);
            }
        } else if (bundle != null && bundle.getContinuationBundle() != null) {
            chainNextJob(bundle.getContinuationBundle(), objectGroup);
        }
    }
    public static void startInternalChain(
        Map<AsyncTriggerJobType, Object> subJobs,
        String objectGroup,
        AsyncTriggerJobBundle mainChainBundle
    ) {
        AsyncTriggerJobBundle subBundle = new AsyncTriggerJobBundle(subJobs, objectGroup);
        subBundle.setContinuationBundle(mainChainBundle);
        chainNextJob(subBundle, objectGroup);
    }
}

7. Job Factory

AsyncTriggerJobFactory:

public class AsyncTriggerJobFactory {
    public static Queueable createJob(
        AsyncTriggerJobType type,
        Object payload,
        AsyncTriggerJobBundle bundle,
        String objectGroup
    ) {
        if (objectGroup == 'Order') {
            return OrderAsyncJobFactory.create(type, payload, bundle);
        }
        return null;
    }
}

OrderAsyncJobFactory:

public class OrderAsyncJobFactory {
    public static Queueable create(
        AsyncTriggerJobType type,
        Object payload,
        AsyncTriggerJobBundle bundle
    ) {
        String typeName = type.name();
        if (typeName == 'A') return new JobAQueueable(payload, bundle);
        if (typeName == 'B') return new JobBQueueable(payload, bundle);
        if (typeName == 'C') return new JobCQueueable(payload, bundle);
        if (typeName == 'C1') return new JobC1Queueable(payload, bundle);
        if (typeName == 'C2') return new JobC2Queueable(payload, bundle);
        if (typeName == 'D') return new JobDQueueable(payload, bundle);
        if (typeName == 'E') return new JobEQueueable(payload, bundle);
        return null;
    }
}

8. Example Job Classes

JobCQueueable (starts a sub-chain):

public class JobCQueueable implements Queueable {
    private Object payload;
    private AsyncTriggerJobBundle jobBundle;
    public JobCQueueable(Object payload, AsyncTriggerJobBundle bundle) {
        this.payload = payload;
        this.jobBundle = bundle;
    }
    public void execute(QueueableContext context) {
        Boolean internalChained = false;
        // ... C's work ...
        Map<AsyncTriggerJobType, Object> subJobs = new Map<AsyncTriggerJobType, Object>{
            AsyncTriggerJobType.C1 => null,
            AsyncTriggerJobType.C2 => null
        };
        internalChained = true;
        AsyncTriggerJobService.startInternalChain(
            subJobs,
            'Order',
            this.jobBundle
        );
        // Do NOT call chainNextJob here; sub-chain will resume main chain!
        if(!internalChained) {
            AsyncTriggerJobService.chainNextJob(jobBundle, 'Order');
        }
    }
}

JobC1Queueable and JobC2Queueable:

public class JobC1Queueable implements Queuable{
    private Object payload;
    private AsyncTriggerJobBundle jobBundle;
    public JobC1Queueable(Object payload, AsyncTriggerJobBundle bundle) {
        this.payload = payload;
        this.jobBundle = bundle;
    }
    public void execute(QueueableContext context) {
        // ... C1's work ...
        AsyncTriggerJobService.chainNextJob(jobBundle, 'Order');
    }
}

(Same pattern for JobC2Queueable.)

9. How Internal Chaining Works

JobCQueueable creates a sub-bundle for C1 and C2, sets its continuation to the main bundle, and enqueues the dispatcher for the sub-bundle.

The dispatcher runs C1, then C2.

After C2, the dispatcher sees the sub-bundle is done, checks for a continuation bundle, and resumes the main chain (D, E, etc).

10. Trigger Handler Example

public class OrderTriggerHandler {
    public static void afterInsert(List<Order> orders) {
        AsyncWorkCollector.add(AsyncTriggerJobType.A, orders);
        AsyncWorkCollector.add(AsyncTriggerJobType.B, orders);
        AsyncWorkCollector.add(AsyncTriggerJobType.C, orders);
        // ... add more as needed
        AsyncWorkCollector.flush('Order');
    }
}

Summary

Declarative: Admins can enable/disable jobs and set order in metadata.
Governor-safe: Only one queueable enqueued per async context.
Supports internal chaining: Sub-chains can run before resuming the main chain.
Reusable: Works for any object or trigger.
Testable: Each job is isolated and easy to test.

⚙️ Scalable and Ordered Queueable Execution from Triggers in Salesforce

Rohit Maharashi — Fri, 27 Jun 2025 03:04:59 +0000

🚀 Problem Statement

In Salesforce, Apex triggers often need to perform post-commit processing or heavy logic that exceeds synchronous limits. Queueable Apex jobs are the go-to solution for such asynchronous processing. However, there’s a critical platform limitation:

When a transaction is already running asynchronously (e.g., from another Queueable/Future/Batch), only one System.enqueueJob() call is allowed.

This makes it difficult to:
• Enqueue multiple jobs from a trigger
• Maintain ordered execution of those jobs
• Support nested internal chaining (e.g., Job C triggers C1 and C2)
• Handle complex input data, possibly from the trigger state
• Build a framework that works for any object

⸻

🛠️ Design Intent

We aim to build a generic, scalable, and governor-safe Apex framework to:
• Enqueue multiple Queueable jobs in order
• Allow jobs to chain additional sub-jobs internally
• Support input injection from a State object
• Work in both synchronous and asynchronous contexts
• Be reusable across object trigger handlers

The final flow will look like this:

Trigger.afterInsert() ➔ A ➔ B ➔ C ➔ C1 ➔ C2 ➔ D ➔ E

⸻

🔧 Core Components

BaseChainedQueueable

An abstract base class to support chaining jobs one after another.

public abstract class BaseChainedQueueable implements Queueable {
    protected BaseChainedQueueable nextJob;

    public void setNext(BaseChainedQueueable nextJob) {
        this.nextJob = nextJob;
    }

    public void execute(QueueableContext context) {
        run();
        if (nextJob != null) {
            System.enqueueJob(nextJob);
        }
    }

    public abstract void run();
}

⸻

Sample Job Classes

public class JobA extends BaseChainedQueueable {
    private List<Account> accounts;

    public JobA(List<Account> accounts) {
        this.accounts = accounts;
    }

    public override void run() {
        System.debug('Running A');
    }
}

public class JobC extends BaseChainedQueueable {
    private List<Contact> contacts;

    public JobC(List<Contact> contacts) {
        this.contacts = contacts;
    }

    public override void run() {
        System.debug('Running C');
        JobC1 c1 = new JobC1();
        JobC2 c2 = new JobC2();
        c1.setNext(c2);

        if (nextJob != null) {
            c2.setNext(nextJob);
        }

        System.enqueueJob(c1);
    }
}

public class JobC1 extends BaseChainedQueueable {
    public override void run() {
        System.debug('Running C1');
    }
}

public class JobC2 extends BaseChainedQueueable {
    public override void run() {
        System.debug('Running C2');
    }
}

Repeat similarly for JobB, JobD, and JobE.

⸻

State Class

A generic key-value store to pass contextual data between jobs:

public class State {
    private Map<String, Object> data = new Map<String, Object>();

    public void put(String key, Object value) {
        data.put(key, value);
    }

    public Object get(String key) {
        return data.get(key);
    }
}

⸻

QueueableOrchestrator

Handles safe job submission based on execution context:

public class QueueableOrchestrator {
    public static void run(BaseChainedQueueable firstJob) {
        if (AsyncUtils.isAsync()) {
            System.enqueueJob(new ChainedStarter(firstJob));
        } else {
            System.enqueueJob(firstJob);
        }
    }

    private class ChainedStarter implements Queueable {
        private BaseChainedQueueable job;

        public ChainedStarter(BaseChainedQueueable job) {
            this.job = job;
        }

        public void execute(QueueableContext context) {
            System.enqueueJob(job);
        }
    }
}

⸻

JobQueueManager

Central place to build and connect the job chain:

public class JobQueueManager {
    public static void runChainedJobsFromState(State state) {
        List<Account> accounts = (List<Account>) state.get('accounts');
        List<Contact> contacts = (List<Contact>) state.get('contacts');
        List<Opportunity> opps = (List<Opportunity>) state.get('opps');

        JobA a = new JobA(accounts);
        JobB b = new JobB(opps);
        JobC c = new JobC(contacts);
        JobD d = new JobD();
        JobE e = new JobE();

        a.setNext(b);
        b.setNext(c);
        c.setNext(d);
        d.setNext(e);

        QueueableOrchestrator.run(a);
    }
}

⸻

Trigger Handler Integration

public class AccountTriggerHandler extends TriggerHandler {
    public override void afterInsert() {
        State state = new State();
        state.put('accounts', (List<Account>) Trigger.new);

        List<Id> accIds = new Map<Id, Account>(Trigger.new).keySet();
        state.put('contacts', ContactSelector.getByAccountIds(accIds));
        state.put('opps', OpportunitySelector.getByAccountIds(accIds));

        JobQueueManager.runChainedJobsFromState(state);
    }
}

⸻

✅ Benefits Recap

•🔁 Fully Ordered Execution — Jobs execute in defined sequence, even with sub-jobs.
•🧱 Governor Safe — One enqueueJob() per async context.
•🧪 Modular and Testable — Each job is self-contained and reusable.
•🔄 Reusable Architecture — Extendable to any object’s trigger.
•🧠 Input-Aware — Jobs receive input from a shared State.

⸻

📚 Closing the Loop

This pattern abstracts away common Salesforce platform limitations, providing a clean, object-oriented framework for managing chained asynchronous logic from Apex triggers.

Whether you’re scaling post-processing across multiple SObjects or introducing conditional sub-flows, this solution lets you build predictably, safely, and cleanly.

Enterprise-Grade Apex Trigger Architecture for Scalable Salesforce Orgs

Rohit Maharashi — Thu, 26 Jun 2025 07:33:55 +0000

As Salesforce orgs evolve into mission-critical platforms, Apex trigger management often turns into a nightmare. Even with popular frameworks, teams eventually hit bottlenecks and complexity spirals out of control.

In this article, I’ll walk you through a modular, maintainable, and enterprise-grade Apex trigger architecture — built to scale gracefully and keep your sanity intact.

💥 Common Problems in Real-World Apex Trigger Implementations

Despite best intentions, real-world triggers tend to suffer from:

🔁 Multiple unnecessary iterations over Trigger.new
🧱 Overloaded trigger handlers that try to do too much
🧵 Poor state sharing between services and layers
❌ Redundant and unoptimized SOQL queries
🧯 No strategy for partial failures or error aggregation
🔄 Scattered DMLs that violate governor limits
🔍 Difficult-to-test and debug logic

We need to go beyond the usual handler frameworks and adopt responsibility-driven modular design.

🎯 Design Goals and Principles

An ideal Apex trigger architecture must be:

✅ Single Responsibility at every layer
✅ Bulk-safe across all operations
✅ No redundant loops on Trigger.new
✅ Centralized DML and error control
✅ Modular, reusable, and testable
✅ Extensible for future business logic

🧩 Proposed Architecture Overview

Here’s the layered flow:

Trigger → Handler → Services → Selectors → UnitOfWork → ContextManager

Layer	Responsibility
Trigger	Lightweight. Only calls the handler.
Handler	Detects context (`beforeInsert`, etc.) and delegates work
Services	Business logic split into Simple (per-record) & Bulk (multi-record)
Selectors	Encapsulate and reuse SOQL queries
UnitOfWork	Batched DML operations and error-safe commits
ContextManager	Shared state and error collection

🧪 Example: Account Trigger Flow

🔹 1. Minimal Trigger

trigger AccountTrigger on Account (
    before insert, after insert,
    before update, after update
) {
    new AccountTriggerHandler().run();
}

🔹 2. Generic Trigger Handler

public virtual class TriggerHandler {
    public void run() {
        if (Trigger.isBefore) {
            if (Trigger.isInsert) beforeInsert();
            if (Trigger.isUpdate) beforeUpdate();
            if (Trigger.isDelete) beforeDelete();
        }
        if (Trigger.isAfter) {
            if (Trigger.isInsert) afterInsert();
            if (Trigger.isUpdate) afterUpdate();
            if (Trigger.isDelete) afterDelete();
        }
    }

    protected virtual void beforeInsert() {}
    protected virtual void beforeUpdate() {}
    protected virtual void beforeDelete() {}
    protected virtual void afterInsert() {}
    protected virtual void afterUpdate() {}
    protected virtual void afterDelete() {}
}

🔹 3. Account-Specific Handler

public with sharing class AccountTriggerHandler extends TriggerHandler {
    private final AdvancedUnitOfWork uow = new AdvancedUnitOfWork();

    protected override void beforeInsert() {
        AccountTriggerContext ctx = new AccountTriggerContext((List<Account>) Trigger.new, (Map<Id, Account>) Trigger.oldMap);
        for (Account acct : ctx.newRecords) {
            new AccountValidationService().validate(acct);
        }
    }

    protected override void afterInsert() {
        AccountTriggerContext ctx = new AccountTriggerContext((List<Account>) Trigger.new, (Map<Id, Account>) Trigger.oldMap);
        new AccountPostInsertService().handleAfterInsert(ctx.newRecords, uow);
        uow.commit();
        ctx.clear();
    }
}

🔹 4. 🧠 Domain Services

✅ Validation Service

public with sharing class AccountValidationService {
    public void validate(Account acct) {
        if (String.isBlank(acct.Name)) {
            acct.addError('Account name is mandatory.');
        }
    }
}

✅ Post-Insert Service

public with sharing class AccountPostInsertService {
    public void handleAfterInsert(List<Account> accounts, AdvancedUnitOfWork uow) {
        if (accounts.isEmpty()) return;

        List<Contact> relatedContacts = ContactSelector.selectByAccountIds(accounts);
        for (Contact con : relatedContacts) {
            con.Description = 'Updated after insert';
            uow.registerUpdate(con);
        }
    }
}

🔹 5. 🔍 Selector Layer (SOQL Isolation)

public with sharing class ContactSelector {
    public static List<Contact> selectByAccountIds(List<Account> accounts) {
        Set<Id> accountIds = new Set<Id>();
        for (Account acc : accounts) {
            if (acc.Id != null) accountIds.add(acc.Id);
        }

        return accountIds.isEmpty() ? new List<Contact>() :
            [SELECT Id, FirstName, LastName, AccountId FROM Contact WHERE AccountId IN :accountIds];
    }
}

🔹 6. 🧱 Advanced Unit of Work

Handles all DMLs centrally. Avoids mixed DML and supports partial error capture.

public with sharing class AdvancedUnitOfWork {
    private List<SObject> inserts = new List<SObject>();
    private List<SObject> updates = new List<SObject>();

    public void registerInsert(SObject record) {
        if (record != null) inserts.add(record);
    }

    public void registerUpdate(SObject record) {
        if (record != null) updates.add(record);
    }

    public void commit() {
        if (!inserts.isEmpty()) handleDml('insert', inserts);
        if (!updates.isEmpty()) handleDml('update', updates);
    }

    private void handleDml(String operation, List<SObject> records) {
        try {
            Database.SaveResult[] results;

            if (operation == 'insert') results = Database.insert(records, false);
            else results = Database.update(records, false);

            for (Database.SaveResult res : results) {
                if (!res.isSuccess()) {
                    TriggerContextManager.addError(res.getErrors()[0].getMessage());
                }
            }
        } catch (Exception e) {
            TriggerContextManager.addError(e.getMessage());
        }
    }
}

🔹 7. 📦 Trigger Context Manager

Shared memory and error collector across services.

public class TriggerContextManager {
    public static Map<String, Object> sharedData = new Map<String, Object>();
    public static List<String> errors = new List<String>();

    public static void clear() {
        sharedData.clear();
        errors.clear();
    }

    public static void addError(String msg) {
        errors.add(msg);
    }

    public static Boolean hasErrors() {
        return !errors.isEmpty();
    }
}

🧠 Why This Architecture Works

💡 One job per class = better readability and unit testing
💡 Selectors prevent query duplication
💡 Services remain simple and scalable
💡 UnitOfWork avoids mixed DML chaos
💡 ContextManager gives shared state and captures errors
💡 Extremely testable: services and selectors are easy to mock/test

✅ Final Thoughts

With this approach, your Salesforce trigger logic becomes:

🚀 Robust for enterprise-scale applications
🔍 Clear and maintainable
🧪 Testable by default
🔄 Flexible for future changes
⚙️ Aligned with governor limits and best practices

Let your triggers do less. Let your architecture do the heavy lifting.

🙌 Thanks for reading!
If this helped you, consider sharing it with your team, leaving a ❤️, or dropping a comment!