Apex Trigger Scaffolder — Best-Practice Boilerplate
Skip to main content
Dev Toolkitby salesforceapp.tech

App

🕐History⚙️Settings1d

Apex Trigger Scaffolder

Generate a one-trigger-per-object Apex bundle: trigger, handler, helper, test, and meta XML.

Trigger: AccountTriggerHandler: AccountTriggerHandlerHelper: AccountTriggerHelper
/**
 * AccountTrigger
 * One-trigger-per-object pattern. All logic lives in AccountTriggerHandler.
 */
trigger AccountTrigger on Account (before insert, after insert, before update, after update) {
    AccountTriggerHandler.run();
}
AccountTrigger.trigger-meta.xml
<?xml version="1.0" encoding="UTF-8"?>
<ApexTrigger xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>60.0</apiVersion>
    <status>Active</status>
</ApexTrigger>

About the Apex Trigger Builder

Writing a well-structured Apex trigger from scratch requires knowing the right patterns — single trigger per object, handler class separation, bulkification, and proper test coverage. This builder generates a complete trigger bundle: the trigger file, a handler class with event-specific methods, and a test class skeleton — all following Salesforce best practices.

What this tool generates

Trigger File

A thin trigger that delegates to a handler class. Includes only the selected trigger events (before insert, after update, etc.).

Handler Class

A handler class with separate methods for each trigger event. Bulkified by default — all methods accept List<SObject> parameters.

Test Class

An @isTest class with test methods for each trigger event, using Test.startTest() / Test.stopTest() and bulk data setup.

API Version

Select the Salesforce API version for the generated metadata. Defaults to the latest available version.

Trigger best practices

  • One trigger per object — use a handler class to manage execution order
  • Never query or DML inside a loop — collect IDs first, then bulk query/DML outside
  • Use Trigger.newMap and Trigger.oldMap for efficient record lookup
  • Always write tests that insert 200 records to verify bulkification

Pipeline

Frequently asked

Is my trigger code sent to a server?
No. All code generation runs 100% in your browser. Your object names, field names, and trigger logic never leave your device.
What is the Trigger Handler pattern?
The Trigger Handler pattern separates trigger logic from the trigger file itself. The trigger file is kept thin — it just calls a handler class. The handler class contains the actual business logic in methods like beforeInsert(), afterUpdate(), etc. This makes the code testable, maintainable, and avoids the "one trigger per object" anti-pattern.
Why should I only have one trigger per object?
Multiple triggers on the same object execute in an undefined order. If two triggers both modify the same field, the result is unpredictable. The single-trigger pattern with a handler class gives you full control over execution order within a single entry point.
What trigger events should I use?
Use before insert/update for validation and field defaulting (before the record is saved). Use after insert/update for creating related records or calling external systems (after the record has an Id). Use before delete for validation. Use after delete/undelete for cleanup and cascade operations.
What is bulkification and why does it matter?
Bulkification means writing trigger logic that handles a list of records (Trigger.new) rather than a single record. Salesforce processes up to 200 records per trigger invocation. Non-bulkified code that queries or DMLs inside a loop will hit governor limits immediately when processing more than a handful of records.