New Logger Plugin Framework + optional Slack plugin

• #165 - In previous versions, if you built your own automations on Log__c and LogEntry__c objects, you could experience inconsistent and unexpected results since there were multiple automations running (the automations included in Logger + your own automations). Now, you can create Apex and Flow "plugins" - the logger system will then automatically run the plugins after each trigger event (BEFORE_INSERT, BEFORE_UPDATE, AFTER_INSERT, AFTER_UPDATE, and so on)

  • Flow plugins: your Flow should be built as auto-launched Flows with these parameters:
    1. Input parameter triggerOperationType - The name of the current trigger operation (such as BEFORE_INSERT, BEFORE_UPDATE, etc.)
    2. Input parameter triggerNew - The list of logger records being processed (Log__c or LogEntry__c records)
    3. Output parameter updatedTriggerNew - If your Flow makes any updates to the collection of records, you should return a record collection containing the updated records
    4. Input parameter triggerOld - The list of logger records as they exist in the datatabase
  • Apex plugins: your Apex class should extend the abstract class LoggerSObjectHandlerPlugin. It includes 1 method signature that you must implement
    • public override void execute(TriggerOperation triggerOperationType, List<SObject> triggerNew, Map<Id, SObject> triggerNewMap, List<SObject> triggerOld, Map<Id, SObject> triggerOldMap) {}

Once you've created your Apex and/or Flow plugins, you can configure them using the new CMDT object LoggerSObjectHandlerConfiguration__mdt. This configuration also provides the ability to enable/disable each of the handler classes (useful for temporarily disabling these classes). See README.md for more details.

Additional Changes

• Bugfix for #155 - logging from Messaging.InboundEmailHandler classes should now work successfully
• Bugfix for #166 - the LogBatchPurger batch class has been optimized by @jamessimone to avoid the error, "Too many DML rows: 10001"