-
-
Notifications
You must be signed in to change notification settings - Fork 180
Plugin Framework
If you want to add your own automation to the included custom objects, you can leverage Apex or Flow to define "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). Currently, these objects are supported:
-
LogEntryEvent__e
platform event -
Log__c
custom object -
LogEntry__c
custom object -
LogEntryTag__c
custom object -
LoggerTag__c
custom object -
LoggerScenario__c
custom object
This framework (currently in beta) makes it easy to build your own plugins, or deploy/install others' prebuilt packages, without having to modify the logging system directly.
Your Flow should be built as auto-launched Flows with these parameters:
-
Input
parametertriggerOperationType
- The name of the current trigger operation (such as BEFORE_INSERT, BEFORE_UPDATE, etc.) -
Input
parametertriggerNew
- The list of logger records being processed (Log__c
orLogEntry__c
records) -
Output
parameterupdatedTriggerNew
- If your Flow makes any updates to the collection of records, you should return a record collection containing the updated records -
Input
parametertriggerOld
- The list of logger records as they exist in the datatabase
-
Apex plugins: your Apex class should implements
LoggerPlugin.Triggerable
. For example:public class ExampleTriggerablePlugin implements LoggerPlugin.Triggerable { public void execute(LoggerPlugin__mdt configuration, LoggerTriggerableContext input) { // Example: only run the plugin for Log__c records if (context.sobjectType != Schema.Log__c.SObjectType) { return; } List<Log__c> logs = (List<Log__c>) input.triggerNew; switch on input.triggerOperationType { when BEFORE_INSERT { for (Log__c log : logs) { log.Status__c = 'On Hold'; } } when BEFORE_UPDATE { // TODO add before-update logic } } } }
Once you've created your Apex or Flow plugin(s), you will also need to configure the plugin:
- 'Logger Plugin' - use the custom metadata type
LoggerSObjectHandlerPlugin__mdt
to define your plugin, including the plugin type (Apex or Flow) and the API name of your plugin's Apex class or Flow - 'Logger Plugin Parameter' - use the custom metadata type
LoggerSObjectHandlerPluginParameter__mdt
to define any configurable parameters needed for your plugin, such as environment-specific URLs and other similar configurations
Note: the logger plugin framework is not available in the managed package due to some platform limitations & considerations with some of the underlying code. The unlocked package is recommended (instead of the managed package) when possible, including if you want to be able to leverage the plugin framework in your org.
- Assigning Permission Sets to Users
- Configuring Global Feature Flags
- Configuring Profile & User-Specific Settings
- Configuring Data Mask Rules
Manual Instrumentation
- Logging in Apex
- Logging in Flow & Process Builder
- Logging in Lightning Web Components & Aura Components
- Logging in OmniStudio
- Logging in OpenTelemetry (OTEL) REST API
ISVs & Package Dependencies
- Overview
- Optionally Use Nebula Logger (When Available) with
Callable
Interface - Require Nebula Logger with Strongly-Coupled Package Dependency
Troubleshooting
Pub/Sub with Platform Events
Persisted Data with Custom Objects
- Logger Console app
- Assigning & Managing Logs
- Using 'View Related Log Entries' Component on Record Pages
- Deleting Old Logs
Official Plugins