Logger Settings

Note for Community Users and Logger Settings

Salesforce does not allow custom settings to be directly created for users with a Community User profile. However, when using the Logger Settings tab within the Ops Center, administrators can assign a specific Logger Setting configuration to Community Users. This feature simplifies debugging portal-related issues by isolating log settings to the specific user profile without altering Org-Wide settings.

By targeting individual Community Users, administrators can prevent a surge of unnecessary log events that could otherwise impact overall Org performance and make log management more complex. This approach allows for precise troubleshooting without compromising system stability or increasing log noise across the entire org.

Overview of all available Logger Setting

Setting	What is it for?	Default value	Recommended Sandbox Value	Recommended Production Value	Since Version
Client Log Size	Defines how many messages are cached in the browser. 100 messages are more than sufficient. It could easily be less. Even with larger strings, i.e. full payloads from server requests, I have never found it to impact performance.	100	100	100	1.0
Client Console Log Level	Defines what log statements will be printed to the Browser's developer console. These messages can be seen by any user if they open those tools. This setting is configured for development and testing in Sandboxes, and it is recommended to change the value for Production.	DEBUG	DEBUG	NONE	1.0
Client Server Log Level	Defines what log messages will trigger a server request to send out a Log Event platform event. Please note that this setting ignores the Log Event Reporting Level, which means that even if the client log level is of lower priority, it will still trigger the platform event. Reducing this level in production can sometimes be helpful when diagnosing a specific issue. It is not recommended to set this value below WARN, at least not on a global scope.	WARN	WARN	WARN	1.0
Log Size	Defines how many messages are cached in the browser. 100 messages are more than sufficient. It could easily be less. Even with larger strings, i.e. full payloads from HTTP requests and response, I have \ never found it to impact performance.	100	100	100	1.0
General Log Level	Defines the log level for which log statements are recorded in the cache. Any message below this level will be ignored. Typically, this setting should be set as low as possible, trying to find the balance between valuable content for the majority of the debug sessions, and optionally additional value for specific problems.	INFO	INFO	INFO	1.0
System Debug Log Level	Defines what log statements will be logged to the Salesforce System logs. These messages can be seen by Administrators after enabling a Debug Log in Setup. Debug logs can grow in size significantly and contain a lot of platform information. It is therefore recommended to only use DEBUG in production when debugging specific issues that require that level of detail. Most messages should be written as INFO level, which should be sufficient in most situations.	DEBUG	DEBUG	INFO	1.0
Log Event Reporting Level	Defines what log messages will trigger a Log Event platform event. The Platform Event can be viewed in the Log Monitor Dashboard, where users can also download the log file. Reducing this level in production can sometimes be helpful when diagnosing a specific issue. It is not recommended to set this value below WARN on a global scope. The lowest level this setting can be set to is INFO.	WARN	WARN	WARN	1.0
Flush Log Cache Level	Set the log level for which the log cache should be flushed after a rflib_Log_Event__c Platform Event is published. Any log statement that is published and encompassed by set flush cache level, i.e. flush log cache level of WARN will match for WARN and ERROR messages, will clear the log cache after the platform event is emitted.	NONE	NONE	NONE	2.1
Batched Log Event Reporting Level	Reporting a Log Event platform event will consume an DML request from your governor limits. Furthermore, there are situations where reporting a Log Event itself can cause a runtime exception because DML statements are not allowed. There are two ways to get around this issue. A rflib_DefaultLogger can be configured to batch all logs, and by setting the value of this field. This can also be critical when debugging an issue that may require lowering the log level to a level that may then cause before mentioned exceptions. Please note that whenever log batching is enabled, it is required to call the rflib_Logger.publishBatchedLogEvents() method for the events to actually get dispatched. If this commit is missing, the events will never be emitted.	NONE	NONE	NONE	1.0
Email Log Level	Defines what Log Events should be sent out to the Apex Exception Email list. In most cases, it is desired to review more log messages in the Log Monitor Dashboard, but only to be notified for severe cases. When the log level of the message that triggered the Log Event matches this level, a notification with the details will be sent out. This way, admins do not have to monitor the Dashboard regularly in production.	NONE	Dev Sandboxes: NONE, UAT/Pre-Prod: FATAL	FATAL	1.0
Archive Log Level	Defines what Log Events should be stored in the Log Archive Big Object. These messages are stored until they are manually deleted from the Log Monitor Dashboard. When the log level of the message that triggered the Log Event matches this level, a log record is created in the archive. This way, log messages can be reviewed any time, even after the Log Even platform event was discarded of.	NONE	Dev Sandboxes: NONE, UAT/Pre-Prod: WARN	ERROR	3.0
Org Wide Email Sender Address	Defines the email address to be used to send out the email notifications. The email must be configured and activated in the Organization Wide Email Addresses list.		UAT/Pre-Prod: Set to valid email address	Set to valid email address	1.0
Logger Factory Class	This field identifies the class to be used as a logger factory, which can be dynamically loaded using the rflib_LoggerUtil.getFactory() method. This class will then be instantiated and used to create the logger instance.	rflib_DefaultLoggerFactory	rflib_DefaultLoggerFactory	rflib_DefaultLoggerFactory	1.0
Application Event Logger Class Name	This field identifies the class to be used when creating a Application Event Logger, which can be dynamically loaded and instantiated using the rflib_LoggerUtil.getApplicationEventLogger() method.	rflib_DefaultApplicationEventLogger	rflib_DefaultApplicationEventLogger	rflib_DefaultApplicationEventLogger	5.0
HTTP Callout Log Level	Defines the log level for which a Log Event will be sent to an external HTTP service. An external HTTP service could be an AWS API Gateway that redirects the message to a Lambda function that stores the events in AWS Cloudwatch.	NONE	NONE	WARN - if an external system is available	7.2
Log Aggregation Log Level	Defines the log level at which Application Events will be created. Must be one of: WARN, ERROR, or FATAL.	NONE	Dev Sandboxes: NONE, UAT/Pre-Prod: WARN	WARN	8.0