Tagging System Overhaul

Added new tagging objects & more robust tagging functionality

• 2 "tagging modes" are now built into Nebula Logger
  1. Using Salesforce Topics: this old functionality is still available in the unlocked package (but still not available in the managed package. However, as of release v4.6.0, it will no longer be the default. After upgrading to v4.6.0, you can revert to using Topics by updating the custom metadata record "LogEntryEventHandler - Use Topics for Tags" within the CMDT object LoggerSObjectHandlerParameter__mdt - simply change the Value__c field from false to true and save.
  2. Using Logger's Custom Tagging objects: available in both the unlocked package and managed package, this mode will be the default as of release v4.6.0. This mode uses 2 additional custom objects, LoggerTag__c and LogEntryTag__c in place of Topic and TopicAssignment (respectively)
• Tags can be added in 3 different ways
  1. In Apex: developers can use 2 new methods in LogEntryBuilder to add tags

     // Use addTag(String tagName) for adding 1 tag at a time
     Logger.debug('my log message').addTag('some tag').addTag('another tag');
     
     // Use addTags(List<String> tagNames) for adding a list of tags in 1 method call
     List<String> myTags = new List<String>{'some tag', 'another tag'};
     Logger.debug('my log message').addTags(myTags);

  2. In Flow: flow builders can set the property List<String> tags within the Flow classes FlowLogEntry, FlowRecordLogEntry and FlowCollectionLogEntry
  3. Using the custom metadata type object LogEntryTagRule__mdt: admins can configure tagging rules to append additional tags. These tags are added on top of any tags added via Apex and/or Flow. Rules can be set up by configuring a rule with these fields set:
     1. Logger SObject: currently, only the "Log Entry" object (LogEntry__c) is supported.
     2. Field: the SObject's field that should be evaluated - for example, LogEntry__c.Message__c. Only 1 field can be selected per rule, but multiple rules can use the same field.
     3. Comparison Type: the type of operation you want to use to compare the field's value. Currently supported options are: CONTAINS, EQUALS, MATCHES_REGEX, and STARTS_WITH
     4. Comparison Value: the comparison value that should be used for the selected field operation
     5. Tags: a list of tag names that should be dynamically applied to any matching LogEntry__c records. When specifying multiple tags, put each tag on a separate line within the Tags field
     6. Is Enabled: only enabled rules are used by Logger - this is a handy way to easily enable/disable a particular rule without having to entirely delete it

Plugin Framework Enhancements

Added plugin support for LogEntryEvent__e

Plugins can now be built for the platform event object LogEntryEvent__e, using the TriggerOperation enums BEFORE_INSERT and AFTER_INSERT.

• Note: for the BEFORE_INSERT trigger operation on LogEntryEvent__e, any configured plugins are executed synchronously. Plugins designed to run in this scenario should try to minimize CPU time to avoid introducing any performance issues.

New CMDT object LoggerSObjectHandlerParameter__mdt

This custom metdata type (CMDT) object is used by the SObject handler classes for feature-flagging & customizations, allowing certain functionality within the handler classes to be changed via configuration

• LogHandler now uses parameters to store lists of preview & non-preview instance names, instead of hardcoding values within code
• LogEntryEventHandler now uses a parameter as a feature flag to enable/disable callouts made to Salesforce status API (api.status.salesforce.com). This was previously managed via the org-level defaults in LoggerSettings__c, but the parameter CMDT object is a better fit for this particular feature

New Apex class LoggerParameter

This class is used by the SObject handler classes and plugins to easily retrieve (and mock) records for the CMDT objects

• Logger.Parameter.Handler - this returns an instance of LoggerParameter that loads SObject Handler parameters from the object LoggerSObjectHandlerParameter__mdt
  • Tests can mock these CMDT records using LoggerParameter.Handler.setMockParameter(LoggerSObjectHandlerParameter__mdt parameter)
• Logger.Parameter.Plugin - this returns an instance of LoggerParameter that loads SObject Handler Plugin parameters from the object LoggerSObjectHandlerPluginParameter__mdt
  • Tests can mock these CMDT records using LoggerParameter.Plugin.setMockParameter(LoggerSObjectHandlerPluginParameter__mdt parameter)

Slack Plugin

Updated Slack plugin to leverage the new LoggerParameter class

Added logging for Flow record collections

Added a new class, FlowCollectionLogEntry, to handle logging a record collection (i.e., an instance of List<SObject>), which stores the JSON of the record collection on the LogEntry__c record. This class is very similar to FlowLogEntry and FlowRecordLogEntry, with the only difference being that it logs an instance of List<SObject>.

This release also includes a new public class, FlowLogger, that's used for sharing some code for all 3 Flow entry classes. FlowLogEntry and FlowRecordLogEntry have been refactored to leverage FlowLogger.

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"

Added new save method SYNCHRONOUS_DML

• #163 - Added new enum value Logger.SaveMethod.SYNCHRONOUS_DML. Using this save method skips publishing platform events and instead immediately creates Log__c and LogEntry__c records. Please note that this save method should be used cautiously! When using this save method, any exceptions thrown in the same transaction will prevent your log entries from saving! This is due to Salesforce rolling back any DML when exceptions occur.

LogBatchPurger Bugfixes

• Fixes #146 (again) - chunking errors previously could occur due to trying to use 1 consolidated List<SObject> for deletions - updated the code to use 2 lists instead (logs & entries)
• Query limit error caused by logs with 200+ log entries - switched to instead querying log entries directly to avoid this issue

Inaccurate Timestamp Bugfix

• Fixes issue #132 (PR #153). Timestamps previously could have been inaccurate if the current user and automated process user had different time zones - internally converting a String version of System.now().getTime() back to Datetime solves the issue (instead of just using a String version of System.now())

Experience Site Guest Users Bugfix

• #152 Fixed logging failing for Experience Site guest users (reported in #145)

Unlocked Package

• Production installation URL: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027FI1QAM
• Sandbox installation URL: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027FI1QAM

Topics overloads cleanup

This release only impacts the unlocked package

• Removed all public overloads in Logger that used List<String> topics as a parameter - these methods are not currently available in the managed package. Topics functionality will be revisited in #90.
• Updated Logger.md docs - all references to the Topics overloads have been removed, and some inaccurate ApexDocs details have been corrected

Unlocked Package

• Production installation URL: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027FGUQA2
• Sandbox installation URL: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027FGUQA2

Unlocked Package Release

A new unlocked package of Logger has been added - you can now choose 3 ways to install Logger in your org

1. Install the new unlocked package (recommended) - this new package does not use a namespace. This package provides the advantages of the unpackaged metadata, with the added convenience of being able to easily install, update and uninstall using a 2nd gen package
2. Install the managed package - due to Salesforce limitations with namespaced code, the managed package has some limitations (see README.md for details)
3. Deploy the unpackaged metadata directly from Github - this provides more or less the same experience as the unlocked package, but requires you to deploy using the metadata API & remove using destructiveChanges.xml

All metadata in this version is the same metadata in the managed package's release v4.4.0

Unlocked Package

• Production installation URL: https://login.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027FGFQA2
• Sandbox installation URL: https://test.salesforce.com/packaging/installPackage.apexp?p0=04t5Y0000027FGFQA2