Steps Best Practices

To maintain clean, scalable, and maintainable Apex code when implementing custom Steps in the Breezz Framework, follow these core development guidelines.

Single Responsibility Principle (SRP)

Each Step should do one thing only. Avoid creating monolithic “God Steps” that handle multiple unrelated operations. Small, focused steps are significantly easier to unit test, maintain, and compose into flexible Step Groups.

DO: Create separate, highly cohesive classes as:

• ValidateAccountBillingAddressStep
• SyncAccountToExternalSystemStep

AVOID: Packing multiple responsibilities into a single class as for example validating addresses, updating prices, and sending emails all inside one Step as:

• FullAccountServiceStep

Never Issue Direct DML

Never use direct DML statements (insert, update, delete) inside a Step. Always leverage the Modification Context. The framework automatically aggregates, bulkifies, and executes modifications at the end of the transaction scope.

DO:

for (Account acc : accountList) {
    getContext().addModificationToUpdate(acc.Id, Account.Status__c, 'Active');
}

AVOID:

update accountList; // Risk of hitting DML limits or skipping framework controls

Ensure Strict Bulkification

Assume your Step will always receive bulk data, even if it runs on a single record during standard UI testing.

DO:

• Build logic using sets and maps to process collections efficiently.
• Always register context modifications within record-level loops rather than holding state in global static variables.
• Use getStore() for loading data asynchronously and getContext() for staging updates.

AVOID:

• Avoid running SOQL/SOSL queries or DML operations inside loops.

Leverage Standard Exceptions

Let the Breezz framework handle top-level error logging. If an unrecoverable business condition fails:

DO:

• Throw standard framework exceptions or custom application exceptions.

AVOID:

• Do not swallow exceptions with empty try-catch blocks, as this prevents the error logging engine from capturing the failure state.

Keep Steps Completely Stateless

Steps should not rely on persistent static state across multiple executions. Treat input data passed into the Step methods as the single source of truth for that execution context. This ensures that Steps can safely run in parallel, inside Queueables, or within Batch Apex scopes without race conditions.

Robust Testing

Always initialize test contexts using forvendi.BreezzApi.TESTS.init(...) and always call forvendi.BreezzAPI.TESTS.assertErrorLogs(); in your unit tests to ensure no internal framework exceptions were suppressed during execution.

Summary Checklist

Before pushing a custom Step to production, verify:

• Logic is confined to a single business goal.
• No direct DML operations exist in the class.
• No SOQL/SOSL queries exist inside loops.
• Field updates use addModificationToUpdate to prevent field overwrites.
• Unit tests cover both single-record and bulk processing scenarios via forvendi.BreezzApi.TESTS.

💡 To know more best practices check Getting Started - good practices