Class Name: SObjectTriggerHandler¶

Last Updated: 2025-10-22 Source Code: SObjectTriggerHandler.cls

API Name: SObjectTriggerHandler Type: Utility Test Coverage: Not specified

Business Purpose¶

This utility class provides reusable methods for identifying records with complete address information and detecting address field changes in trigger contexts. It supports AANP's geocoding and address processing workflows by filtering records that have sufficient address data for external API processing.

Class Overview¶

Sharing Model: with sharing
Access Modifier: public
Interfaces Implemented: None

Key Responsibilities¶

Filter records that have complete address information (street, city, country required)
Detect address field changes between old and new record versions in trigger contexts
Support generic SObject processing for reusability across different objects
Provide null-safe operations with proper defensive coding

Public Methods¶

getObjectsWithAddresses¶

public static List<sObject> getObjectsWithAddresses(
    final List<sObject> records,
    Schema.SObjectField street,
    Schema.SObjectField city,
    Schema.SObjectField state,
    Schema.SObjectField country
)

Purpose: Filters a list of SObject records to return only those with complete address information (street, city, and country are not blank).

Parameters: - records (List): List of records to filter - street (Schema.SObjectField): Field reference for street address - city (Schema.SObjectField): Field reference for city - state (Schema.SObjectField): Field reference for state (validated but not required) - country (Schema.SObjectField): Field reference for country

Returns: - List<sObject>: List of records with complete address information; returns empty list if input is null/empty

Usage Example:

List<Order> ordersWithAddresses = (List<Order>) SObjectTriggerHandler.getObjectsWithAddresses(
    Trigger.new,
    Order.ShippingStreet,
    Order.ShippingCity,
    Order.ShippingState,
    Order.ShippingCountry
);

Business Logic: - Requires street, city, and country to be non-blank - State field is optional (included in parameters but not validated) - Uses String.isBlank() for robust string validation - Returns empty list for null or empty input

getObjectsWithUpdatedAddresses¶

public static List<sObject> getObjectsWithUpdatedAddresses(
    final Map<Id,sObject> oldRecords,
    final Map<Id,sObject> newRecords,
    final Schema.SObjectField street,
    final Schema.SObjectField city,
    final Schema.SObjectField state,
    final Schema.SObjectField country
)

Purpose: Identifies records where any of the four address fields have changed between old and new versions, typically used in trigger update contexts.

Parameters: - oldRecords (Map): Map of old record versions (Trigger.oldMap) - newRecords (Map): Map of new record versions (Trigger.newMap) - street (Schema.SObjectField): Field reference for street address - city (Schema.SObjectField): Field reference for city - state (Schema.SObjectField): Field reference for state - country (Schema.SObjectField): Field reference for country

Returns: - List<sObject>: List of records where at least one address field has changed; returns empty list if input is null/empty

Usage Example:

List<Order> ordersWithUpdatedAddresses = (List<Order>) SObjectTriggerHandler.getObjectsWithUpdatedAddresses(
    Trigger.oldMap,
    Trigger.newMap,
    Order.ShippingStreet,
    Order.ShippingCity,
    Order.ShippingState,
    Order.ShippingCountry
);

Business Logic: - Compares all four address fields (street, city, state, country) between old and new versions - Returns record if ANY address field has changed - Uses direct field comparison (handles null values through Salesforce's equality operator) - Returns empty list for null or empty input maps

Private/Helper Methods¶

This class contains no private methods.

Dependencies¶

Apex Classes¶

No direct Apex class dependencies

Salesforce Objects¶

Generic SObject support - can be used with any object containing address fields
Common usage: Order, Account, ContactPointAddress, PracticeSite__c

Custom Settings/Metadata¶

None

External Services¶

None directly (indirectly supports geocoding services through calling classes)

Design Patterns¶

Utility Pattern: Static methods for reusable address validation logic
Generic Programming: Uses SObject type and Schema.SObjectField for type-safe field references across multiple objects

Governor Limits Considerations¶

SOQL Queries: None DML Operations: None CPU Time: Minimal - simple field comparisons and string validation Heap Size: Low - processes lists in memory without aggregation

Bulkification: Yes - processes lists of records efficiently Async Processing: None - designed for synchronous trigger execution

Error Handling¶

Strategy: Defensive programming with null checks on input parameters Logging: No explicit logging (returns empty lists on invalid input) User Notifications: None

Security Considerations¶

Sharing Rules: Enforces sharing (with sharing) - respects record access Field-Level Security: Does not enforce FLS - assumes caller has validated field access CRUD Permissions: No DML operations Input Validation: Validates null/empty inputs but not field-level permissions

Test Class¶

Test Class: SObjectTriggerHandlerTest.cls Coverage: Not specified Test Scenarios Covered: - Records with complete address information - Records with incomplete addresses - Address field change detection - Null and empty input handling - Multiple record processing

Changes & History¶

No documented change history available

Pre-Go-Live Concerns¶

CRITICAL - Fix Before Go-Live¶

MISSING FLS CHECKS: No field-level security validation for address field access
NULL POINTER RISK: No explicit null checks for individual field values during comparison (relies on Salesforce's null handling)

HIGH - Address Soon After Go-Live¶

Add comprehensive error handling with try-catch for field access operations
Implement validation for SObjectField parameters (ensure they belong to the passed SObject type)
Add logging for address validation failures to aid troubleshooting
Consider adding performance monitoring for large record processing

MEDIUM - Future Enhancement¶

Add support for postal code validation in complete address check
Implement configurable address validation rules (Custom Metadata)
Add support for partial address matching scenarios
Consider adding address standardization capabilities
Add method overloads for common SObject types to improve usability

LOW - Monitor¶

Monitor performance with large record volumes (10,000+ records)
Track address validation success rates in production
Review field usage patterns for optimization opportunities

Maintenance Notes¶

Complexity: Low Recommended Review Schedule: Annually Key Maintainer Notes: - This utility class is fundamental to address processing workflows and is used across multiple trigger contexts - The generic design allows reusability but requires careful testing with different SObject types - No SOQL/DML operations make this class very safe to use in bulk contexts - When adding new address fields, ensure backward compatibility with existing callers - Any modifications should be thoroughly tested across all dependent trigger handlers (OrderTrigger, AccountTrigger, etc.) - Consider that field comparison logic relies on Salesforce's built-in null handling - changing this could affect trigger behavior