Universal Log — The Next Generation Error Log based on Salesforce Platform Events

Since the beginning of APEX, developers are creating persistent event and error logs in Salesforce. Multiple Salesforce Bloggers explained their version of Error Logging in Salesforce:

All the mechanisms that have been available are using the “try-catch mechanism” and then storing a record in Salesforce. This approach comes with multiple downsides:

  • The error is getting catched and not reported to the next higher instance
  • It is impossible to see from the “Apex Job Log” if batch jobs are successful or not, since all catched exceptions are reported as “success”.
  • An additional DML operation is needed.
  • The Error Log was limited to Salesforce APEX Code

In the past this approch was the only solution to handle exceptions and store them persistent in Salesforce. But with Platform Events a new generation of Error Logging becomes possible.

Universal Log — The Next Generation Error Log

Platform Events and the Salesforce Event Bus allow the implementation of an even more sophisticated solution. I call my solution Universal Log.

My Version of the Log allows not only to store information and exceptions from APEX, the solution supports even configuration like process builder, workflows and external applications.

Architecture of Universal Log

Uniersal Log leverages the out of the box Event Bus in Salesforce. All kinds of services, such as Apex Code, Triggers, Batches, External Applications and others can create Log Events. And send them on the Event Bus. There they can be captured and translated into a persistent log.


Architecture of Universal LogUniversal Log Components

The system is based on 4 major components:

  • The Logger Class that creates based on Exceptions, Flows and other functionality Log Events
  • The Log Event that is used as a transport tool to be catched by
  • The Log Event Trigger that creates based on the event a log record
  • The Log Record That is storing the log information persistently

The Universal Logger Class

The Universal Logger Class can be called during the execution of a class similar to other error logs the error is getting catched and then logged to the log.

But with one difference: The Exception is re-thrown and becomes visible.


This simple code is going to throw an Exception. Now the universal logger sends the exceptions to the event bus and the class re-throw the exception.

    Integer i = 12/0;
catch(Exception e)
    throw e;

The re-thrown exception will be presented to the next higher level. E.g. the developer console


The universal logger take the exception and put the exception on the bus.

global class UniversalLogger
    global static void log(Exception e)
        UniversalLogEvent__e l = new UniversalLogEvent__e();
        l.Stacktrace__c = e.getStackTraceString();
} // Simplified Version

Universal Log Event Trigger

The Universal Event Log Trigger is the last component that then finally converts the Event to a persistent reocrd.

trigger UniversalLogEventTrigger on UniversalLogEvent__e (after insert)
    List<Log__c> logs = new List<Log__c>();
    for(LogEvent__e l : trigger.new)
        logs.add(new Log__c(Stacktrace__c = l.Stacktrace__c, ...));


Salesforce Event Bus as a base for an Error Log is a strong foundation for error logs. All kinds of applications and services can use the error log. The new error log allows to present error messages back to the user, salesforce batch log, while keeping a detailed log in a custom object.

Future Extensions

For a future Version of Universal Log I plan to integrate NewRelic to give even better visibility into the log.

Best Practice: Secure API Keys in Salesforce — Example: Google Firebase

Some time ago Salesforce introduced Named Credentials as a new way to secure secrets in Salesforce. In this post I will explain how to secure API Keys in Salesforce and make callouts to external systems without presenting the secret to developers.


In Winter ’16 Salesforce introduced Named Credentials. Before the common way to store passwords and api keys were “Custom Settings”.

Custom settings had the clear downside that username and password as well as API Keys, Tokens and oAuth Secrets where stored openly and accessible for everyone with access to custom settings.

Named Credentials in comparison do not present passwords and secrets to the user or developer.

How secure are Named Credentials?

Salesforce is recommending to use Named Credentials for all types of callouts.

Named Credentials are a safe and secure way of storing authentication data for external services called from your apex code such as authentication tokens. We do not recommend storing other types of sensitive data in this field (such as credit card information). Be aware that users with customize application permission can view named credentials, so if your security policy requires that the secrets be hidden from subscribers, then please use a protected custom metadata type or protected custom setting. For more information, see named credentials in the online help and training guide.
Source: https://developer.salesforce.com/page/Secure_Coding_Storing_Secrets

As mentioned by Salesforce users with “Customize Application Permissions” can view named credentials. This applies for the named credential itself.
However, when it comes to the passwords stored in named credentials, they are not visible to users or developers:

  • Credential Passwords cannot be made visible in the UI
  • Credential Passwords cannot be accessed through API
  • Credential Passwords cannot be made visible in Debug Logs

Only in the moment the HTTP Request to external systems is executed, Salesforce inserts the password into the request and sends the request to the External Service.

The External Service can then use the password or other credentials to verify the request.

Setup Named Credentials: Example Firebase

Firebase is a service by Google that can be used to send push notifications to users. Salesforce can call firebase and send a push notification to specific users.


Step 1: Setup Named Credentials

To setup the API Key I first had to setup a new server key in firebase.
(Firebase → Project Settings → Message Key)


In Salesforce the Named Credential for Firebase can be created now.
(Setup → Quick Search → Named Credentials)


The following properties have to be entered:
The Endpoint that has to be called is fcm.googleapis.com.
As Identity Type I have chosen Named Principal, since the API key is the same for the whole org.

  • The Authentication Protocol is “Password Authentication”.
  • As Username I entered a dummy value.
  • The password is the API Key.

To use the password in the header of my request, the tick box “Allow Merge Fields in HTTP Body” must be checked.

Step 2: Callout

To be able to call Firebase, I added Firebase to my “Remote Sites” (Setup → Quick Search → Remote Site).
Sending out a request with Named Credentials is using the same functionality as in any other APEX HTTP request:

String message = ‘XYZ’;
// HTTP Request
HttpRequest req = new HttpRequest();
// Callout extended by /fcm/send
// Authentication
req.setHeader(‘Authorization’, ‘key={!$Credential.Password}’);
// send request
Http http = new Http();
HTTPResponse res = http.send(req);

As Endpoint for the HTTPRequest I used callout:Firebase. This indicates to Salesforce that the Named Credential Firebase is used.

During the execution of the HTTP request “callout:Firebase” is getting replace with the URL stored in the Named Credential. The placeholder {!$Credential.Password} is replaced by the password stored in Salesforce.

Step 3: Result

The Debug Log proofs: The request was successfully send to Firebase.



Named Credentials are the secure way to store credentials for callouts in Salesforce.