Debug Logs and Trace Flags
5 minutes
5 Questions
Debug Logs and Trace Flags are essential auditing and monitoring tools in Salesforce that help administrators troubleshoot automation, code, and user activity. A debug log records database operations, system processes, and errors that occur when a user executes a transaction or when a unit test runs. It captures details such as Apex execution, workflow rules, validation rules, Process Builder and Flow actions, callouts, and SOQL/SOSL queries, along with timing information and governor limit consumption. To generate debug logs, an administrator must create a Trace Flag. A trace flag specifies who or what is being monitored (a specific user, an Apex class, an Apex trigger, or an Automated Process entity), the time window during which logging is active (start and expiration dates), and the Debug Level to apply. Trace flags for users expire after a maximum of 24 hours, which prevents unnecessary log accumulation and protects storage limits. Debug Levels define the granularity of information captured for each log category, such as Apex Code, Database, Workflow, Validation, Callouts, System, and Visualforce. Each category can be set to levels like NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, or FINEST. Higher levels produce more detail but larger logs. Each debug log is limited to 20 MB, and an organization can retain up to 1,000 MB of logs; older logs are deleted when the limit is reached. Administrators access these tools through Setup under Environments > Logs > Debug Logs, or via the Developer Console, which offers log filtering and inspection. Logs are retained for 24 hours in Setup and 7 days in the Developer Console. For the Platform Administrator II exam, remember that debug logs are not a substitute for Setup Audit Trail, Field History Tracking, or Event Monitoring; rather, they are a diagnostic tool for understanding why automation behaves unexpectedly, identifying performance bottlenecks, and verifying that processes execute in the intended order.
Debug Logs and Trace Flags: A Complete Guide for the Salesforce Advanced Administrator Exam
Why Debug Logs and Trace Flags Matter
As an Advanced Administrator you are expected to diagnose problems that go beyond a simple configuration error. A user reports that a record will not save, a Flow produces the wrong value, a workflow email never arrives, or an integration user hits a governor limit. Field history, Setup Audit Trail and login history tell you what changed or who logged in, but they do not tell you what Salesforce executed during a transaction. Debug logs do exactly that. The Auditing and Monitoring section of the exam tests whether you know which tool to reach for, how to configure it correctly, what its limits are, and how to read what it produces. Debug logs and trace flags are a favourite topic because they combine configuration knowledge (where to set them up), conceptual knowledge (what a debug level is) and scenario judgement (when a debug log is the right answer versus another monitoring tool).
What a Debug Log Is
A debug log is a record of the database operations, system processes and errors that occur when a user executes a transaction or when unit tests run. A single transaction, for example saving an Account, can trigger validation rules, workflow rules, Process Builder processes, record-triggered Flows, Apex triggers, assignment rules and more. The debug log captures all of these in the order they fired, along with timing information, resource consumption against governor limits, exceptions, and any System.debug statements that developers added to Apex code.
Each log contains:
• A header listing the API version and the log categories with their levels.
• Execution units, one per transaction, bounded by EXECUTION_STARTED and EXECUTION_FINISHED.
• Code units within each execution unit, such as a trigger, a Flow interview, a workflow rule evaluation or a Visualforce controller method, bounded by CODE_UNIT_STARTED and CODE_UNIT_FINISHED.
• Log lines consisting of a timestamp, an event identifier (for example VALIDATION_RULE, WF_RULE_EVAL_BEGIN, FLOW_START_INTERVIEW, SOQL_EXECUTE_BEGIN, EXCEPTION_THROWN, LIMIT_USAGE_FOR_NS) and additional detail.
What a Trace Flag Is
Debug logging is not permanently on for everyone; that would be far too expensive. A trace flag is the instruction that tells Salesforce to start generating logs. A trace flag has four parts:
1. Traced Entity Type – who or what to log. Options are a specific User, an Apex Class, an Apex Trigger, the Automated Process user and the Platform Integration user. Logging a user captures everything that user does. Logging the Automated Process user is essential when troubleshooting Flows, processes or scheduled actions that run in system context rather than as a named user.
2. Start Date and Expiration Date – the window during which logging is active. A single trace flag can be active for a maximum of 24 hours. If you need longer, you create a new trace flag.
3. Debug Level – a reusable, named record that specifies how much detail to capture for each log category.
An important nuance: trace flags on Apex classes and triggers do not generate logs on their own. They override the logging levels for that class or trigger only when a user-level (or Automated Process) trace flag is already generating a log. Use them to turn up detail for one piece of code while keeping the rest of the log quiet.
Debug Levels, Categories and Levels
A debug level is a named set of category-level pairs. The categories are:
• Database – SOQL, SOSL and DML statements.
• Workflow – workflow rules, Process Builder, Flows, assignment rules, approval processes and time-based actions. Flow events appear under this category.
• Validation – validation rule evaluation and results.
• Callouts – outbound HTTP and web service requests and responses.
• Apex Code – Apex execution, including System.debug output and exceptions.
• Apex Profiling – cumulative profiling and governor limit usage information.
• Visualforce – Visualforce page events, view state and formula evaluation.
• System – internal system method calls.
• NBA (Next Best Action) and Wave (CRM Analytics) for those specific features.
The levels, from least to most verbose, are: NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST. Each level includes everything from the levels below it. FINEST produces enormous logs and should be used sparingly on only the categories you need. Salesforce ships a default debug level named SFDC_DevConsole, and you can create your own and reuse them across many trace flags.
How It Works: Setting Up and Reading Logs
Step 1 – Create the trace flag. Navigate to Setup, search for Debug Logs (under Environments > Logs), click New under User Trace Flags, choose the traced entity type and entity, set start and expiration times, and pick or create a debug level. Alternatively, in the Developer Console use Debug > Change Log Levels to add trace flags, or use the Developer Console's Logs tab, which automatically creates a trace flag for the current user.
Step 2 – Reproduce the issue. Have the user (or the automated process) perform the action again while the trace flag is active. Nothing is logged retroactively; a log is only created for transactions that occur inside the trace flag window.
Step 3 – Retrieve the log. Return to Setup > Debug Logs where logs appear in the list with the user, request type, application, status, size and time. Click View to read it in the browser or Download to save a .log text file. In the Developer Console, double-click a log to open the Log Inspector, which offers the Execution Overview, Stack Tree, Execution Log and the Debug Only filter to show just System.debug output.
Step 4 – Interpret the log. Follow the sequence of code units to see the order of operations. Look for VALIDATION_FAIL, FLOW_ELEMENT_ERROR, EXCEPTION_THROWN or FATAL_ERROR lines to find the failure point. Review the LIMIT_USAGE_FOR_NS section to see how close the transaction came to governor limits such as SOQL queries (100 synchronous), DML statements (150), CPU time (10,000 ms) and heap size.
Step 5 – Clean up. Delete or let trace flags expire. Logs and trace flags consume storage, and large volumes can shut logging off for the whole org.
Key Limits You Must Memorise
• Each debug log must be 20 MB or smaller. Logs larger than 20 MB are reduced by removing log lines, which can come from anywhere in the log, not just the beginning.
• System debug logs are retained for 24 hours; monitoring debug logs (those created through Setup trace flags) are retained for 7 days.
• If your org generates more than 1,000 MB of debug logs in a 15-minute window, Salesforce disables your trace flags and sends an email to the users who last modified them. Logging resumes after 15 minutes when you re-enable the trace flags.
• A trace flag's duration cannot exceed 24 hours.
• Debug logs cannot be enabled for an inactive user, and you cannot log for a user in another org.
Required Permissions
To view, retain and delete debug logs a user needs the View All Data permission. Using the Developer Console also requires View All Data, and executing anonymous Apex requires Author Apex. Because View All Data is a powerful permission, exam scenarios often test whether you recognise that a standard user cannot simply view their own debug logs.
Debug Logs Versus Other Monitoring Tools
The exam loves to make you choose the right tool. Keep these distinctions clear:
• Debug Logs – what executed during a transaction (automation order, errors, limits). Short retention, reactive.
• Setup Audit Trail – who changed configuration, retained 180 days, downloadable as CSV.
• Field History Tracking – changes to record field values over time.
• Login History – who logged in, when, from where, success or failure.
• Event Monitoring (Event Log Files) – org-wide API, report export, login, Lightning usage and performance data for analytics; a paid add-on in most editions.
• Apex Jobs / Scheduled Jobs / Bulk Data Load Jobs – status of asynchronous processing.
• Flow error emails and Apex exception emails – proactive notification when automation fails.
• Time-Based Workflow queue – pending time-dependent actions.
• Email Log Files – delivery information for emails sent from Salesforce in the past 30 days.
If the question asks you to identify why a save failed or which automation fired, the answer is a debug log. If it asks who changed a setting or what a field value used to be, it is not.
Common Troubleshooting Scenarios
Scenario 1 – A user gets an error on save that is not a validation rule message. Set a user trace flag on that user with Apex Code at DEBUG or FINE and Workflow at INFO, have them reproduce the error, then look for EXCEPTION_THROWN or FATAL_ERROR lines to identify the trigger or Flow responsible.
Scenario 2 – A record-triggered Flow is not updating a field. The Flow may run as the Automated Process user in some contexts, so if the user trace flag shows nothing, add a trace flag on the Automated Process entity. Set the Workflow category to FINER to see FLOW_ELEMENT_BEGIN, FLOW_ASSIGNMENT_DETAIL and FLOW_VALUE_ASSIGNMENT events.
Scenario 3 – A trace flag exists but no logs appear. Check that the expiration time has not passed, that the start time is not in the future, that the correct user is being traced, that the traced user is active, and that org-wide logging was not disabled by exceeding the 1,000 MB threshold.
Scenario 4 – Logs are truncated and missing the important part. Lower the levels for categories you do not need (for example System and Database to NONE or ERROR) and raise only the relevant category, or add a class or trigger trace flag to focus detail on one code unit.
Scenario 5 – An integration is hitting limits. Trace the integration user with Apex Profiling at FINEST and Database at INFO to see SOQL counts and cumulative limit usage.
Exam Tips: Answering Questions on Debug Logs and Trace Flags
1. Read for the verb. If the question says investigate, troubleshoot, determine why, identify the order of execution, or see which automation fired, think debug logs. If it says audit, track changes, or report on who did what, think Setup Audit Trail or Field History.
2. Know the five traced entity types. User, Apex Class, Apex Trigger, Automated Process and Platform Integration. Questions about Flows or processes that seem invisible in a user's log usually point to the Automated Process user.
3. Memorise the numbers. 20 MB per log, 24-hour maximum trace flag duration, 24-hour retention for system logs, 7-day retention for monitoring logs, 1,000 MB in 15 minutes disables trace flags, and 180 days for Setup Audit Trail (a common distractor).
4. Order the levels correctly. NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST. If a question asks for the most detail, the answer is FINEST; if it asks how to reduce log size, the answer involves lowering levels on unneeded categories.
5. Remember that logging is prospective, not retrospective. A trace flag must be active before the transaction occurs. Any answer that implies you can enable logging and then view an error that happened yesterday is wrong.
6. Class and trigger trace flags refine; they do not initiate. If an option suggests setting a trace flag only on an Apex class to capture a user's error without any user trace flag, be suspicious.
7. Watch for permission traps. Viewing debug logs requires View All Data. A scenario where a sales user wants to see their own log is solved by the administrator, not by granting the user a profile change, unless the question explicitly asks for the permission.
8. Eliminate development-only answers. Checkpoints, Apex Replay Debugger and Execute Anonymous are developer features. In an administrator exam the expected answer is usually to set a trace flag in Setup and review the log, or to use the Developer Console's Log Inspector.
9. Do not confuse debug logs with Event Monitoring. Event Monitoring is for org-wide trend analysis and security monitoring via event log files and often requires an additional licence. Debug logs are for transaction-level troubleshooting of specific users or code.
10. When two answers both seem plausible, choose the least disruptive one. Salesforce exam answers favour setting a targeted, time-bound trace flag with an appropriate debug level over turning everything to FINEST or enabling logging for every user.
Quick Review Checklist
• Debug log = what happened during a transaction.
• Trace flag = who/what, when, and at what detail to log.
• Debug level = reusable set of category and level pairs.
• Setup path = Setup > Environments > Logs > Debug Logs; also Developer Console.
• Max log size 20 MB; trace flag max 24 hours; 1,000 MB per 15 minutes shuts logging off.
• Retention 24 hours (system) or 7 days (monitoring).
• View All Data needed to view logs.
• Automated Process user for Flows and processes running in system context.
• Class/trigger trace flags override levels but need an active user trace flag.
Master these points and you will be able to handle any debug log or trace flag question on the Advanced Administrator exam with confidence, and more importantly, troubleshoot real production issues quickly and safely.
As an Advanced Administrator you are expected to diagnose problems that go beyond a simple configuration error. A user reports that a record will not save, a Flow produces the wrong value, a workflow email never arrives, or an integration user hits a governor limit. Field history, Setup Audit Trail and login history tell you what changed or who logged in, but they do not tell you what Salesforce executed during a transaction. Debug logs do exactly that. The Auditing and Monitoring section of the exam tests whether you know which tool to reach for, how to configure it correctly, what its limits are, and how to read what it produces. Debug logs and trace flags are a favourite topic because they combine configuration knowledge (where to set them up), conceptual knowledge (what a debug level is) and scenario judgement (when a debug log is the right answer versus another monitoring tool).
What a Debug Log Is
A debug log is a record of the database operations, system processes and errors that occur when a user executes a transaction or when unit tests run. A single transaction, for example saving an Account, can trigger validation rules, workflow rules, Process Builder processes, record-triggered Flows, Apex triggers, assignment rules and more. The debug log captures all of these in the order they fired, along with timing information, resource consumption against governor limits, exceptions, and any System.debug statements that developers added to Apex code.
Each log contains:
• A header listing the API version and the log categories with their levels.
• Execution units, one per transaction, bounded by EXECUTION_STARTED and EXECUTION_FINISHED.
• Code units within each execution unit, such as a trigger, a Flow interview, a workflow rule evaluation or a Visualforce controller method, bounded by CODE_UNIT_STARTED and CODE_UNIT_FINISHED.
• Log lines consisting of a timestamp, an event identifier (for example VALIDATION_RULE, WF_RULE_EVAL_BEGIN, FLOW_START_INTERVIEW, SOQL_EXECUTE_BEGIN, EXCEPTION_THROWN, LIMIT_USAGE_FOR_NS) and additional detail.
What a Trace Flag Is
Debug logging is not permanently on for everyone; that would be far too expensive. A trace flag is the instruction that tells Salesforce to start generating logs. A trace flag has four parts:
1. Traced Entity Type – who or what to log. Options are a specific User, an Apex Class, an Apex Trigger, the Automated Process user and the Platform Integration user. Logging a user captures everything that user does. Logging the Automated Process user is essential when troubleshooting Flows, processes or scheduled actions that run in system context rather than as a named user.
2. Start Date and Expiration Date – the window during which logging is active. A single trace flag can be active for a maximum of 24 hours. If you need longer, you create a new trace flag.
3. Debug Level – a reusable, named record that specifies how much detail to capture for each log category.
An important nuance: trace flags on Apex classes and triggers do not generate logs on their own. They override the logging levels for that class or trigger only when a user-level (or Automated Process) trace flag is already generating a log. Use them to turn up detail for one piece of code while keeping the rest of the log quiet.
Debug Levels, Categories and Levels
A debug level is a named set of category-level pairs. The categories are:
• Database – SOQL, SOSL and DML statements.
• Workflow – workflow rules, Process Builder, Flows, assignment rules, approval processes and time-based actions. Flow events appear under this category.
• Validation – validation rule evaluation and results.
• Callouts – outbound HTTP and web service requests and responses.
• Apex Code – Apex execution, including System.debug output and exceptions.
• Apex Profiling – cumulative profiling and governor limit usage information.
• Visualforce – Visualforce page events, view state and formula evaluation.
• System – internal system method calls.
• NBA (Next Best Action) and Wave (CRM Analytics) for those specific features.
The levels, from least to most verbose, are: NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST. Each level includes everything from the levels below it. FINEST produces enormous logs and should be used sparingly on only the categories you need. Salesforce ships a default debug level named SFDC_DevConsole, and you can create your own and reuse them across many trace flags.
How It Works: Setting Up and Reading Logs
Step 1 – Create the trace flag. Navigate to Setup, search for Debug Logs (under Environments > Logs), click New under User Trace Flags, choose the traced entity type and entity, set start and expiration times, and pick or create a debug level. Alternatively, in the Developer Console use Debug > Change Log Levels to add trace flags, or use the Developer Console's Logs tab, which automatically creates a trace flag for the current user.
Step 2 – Reproduce the issue. Have the user (or the automated process) perform the action again while the trace flag is active. Nothing is logged retroactively; a log is only created for transactions that occur inside the trace flag window.
Step 3 – Retrieve the log. Return to Setup > Debug Logs where logs appear in the list with the user, request type, application, status, size and time. Click View to read it in the browser or Download to save a .log text file. In the Developer Console, double-click a log to open the Log Inspector, which offers the Execution Overview, Stack Tree, Execution Log and the Debug Only filter to show just System.debug output.
Step 4 – Interpret the log. Follow the sequence of code units to see the order of operations. Look for VALIDATION_FAIL, FLOW_ELEMENT_ERROR, EXCEPTION_THROWN or FATAL_ERROR lines to find the failure point. Review the LIMIT_USAGE_FOR_NS section to see how close the transaction came to governor limits such as SOQL queries (100 synchronous), DML statements (150), CPU time (10,000 ms) and heap size.
Step 5 – Clean up. Delete or let trace flags expire. Logs and trace flags consume storage, and large volumes can shut logging off for the whole org.
Key Limits You Must Memorise
• Each debug log must be 20 MB or smaller. Logs larger than 20 MB are reduced by removing log lines, which can come from anywhere in the log, not just the beginning.
• System debug logs are retained for 24 hours; monitoring debug logs (those created through Setup trace flags) are retained for 7 days.
• If your org generates more than 1,000 MB of debug logs in a 15-minute window, Salesforce disables your trace flags and sends an email to the users who last modified them. Logging resumes after 15 minutes when you re-enable the trace flags.
• A trace flag's duration cannot exceed 24 hours.
• Debug logs cannot be enabled for an inactive user, and you cannot log for a user in another org.
Required Permissions
To view, retain and delete debug logs a user needs the View All Data permission. Using the Developer Console also requires View All Data, and executing anonymous Apex requires Author Apex. Because View All Data is a powerful permission, exam scenarios often test whether you recognise that a standard user cannot simply view their own debug logs.
Debug Logs Versus Other Monitoring Tools
The exam loves to make you choose the right tool. Keep these distinctions clear:
• Debug Logs – what executed during a transaction (automation order, errors, limits). Short retention, reactive.
• Setup Audit Trail – who changed configuration, retained 180 days, downloadable as CSV.
• Field History Tracking – changes to record field values over time.
• Login History – who logged in, when, from where, success or failure.
• Event Monitoring (Event Log Files) – org-wide API, report export, login, Lightning usage and performance data for analytics; a paid add-on in most editions.
• Apex Jobs / Scheduled Jobs / Bulk Data Load Jobs – status of asynchronous processing.
• Flow error emails and Apex exception emails – proactive notification when automation fails.
• Time-Based Workflow queue – pending time-dependent actions.
• Email Log Files – delivery information for emails sent from Salesforce in the past 30 days.
If the question asks you to identify why a save failed or which automation fired, the answer is a debug log. If it asks who changed a setting or what a field value used to be, it is not.
Common Troubleshooting Scenarios
Scenario 1 – A user gets an error on save that is not a validation rule message. Set a user trace flag on that user with Apex Code at DEBUG or FINE and Workflow at INFO, have them reproduce the error, then look for EXCEPTION_THROWN or FATAL_ERROR lines to identify the trigger or Flow responsible.
Scenario 2 – A record-triggered Flow is not updating a field. The Flow may run as the Automated Process user in some contexts, so if the user trace flag shows nothing, add a trace flag on the Automated Process entity. Set the Workflow category to FINER to see FLOW_ELEMENT_BEGIN, FLOW_ASSIGNMENT_DETAIL and FLOW_VALUE_ASSIGNMENT events.
Scenario 3 – A trace flag exists but no logs appear. Check that the expiration time has not passed, that the start time is not in the future, that the correct user is being traced, that the traced user is active, and that org-wide logging was not disabled by exceeding the 1,000 MB threshold.
Scenario 4 – Logs are truncated and missing the important part. Lower the levels for categories you do not need (for example System and Database to NONE or ERROR) and raise only the relevant category, or add a class or trigger trace flag to focus detail on one code unit.
Scenario 5 – An integration is hitting limits. Trace the integration user with Apex Profiling at FINEST and Database at INFO to see SOQL counts and cumulative limit usage.
Exam Tips: Answering Questions on Debug Logs and Trace Flags
1. Read for the verb. If the question says investigate, troubleshoot, determine why, identify the order of execution, or see which automation fired, think debug logs. If it says audit, track changes, or report on who did what, think Setup Audit Trail or Field History.
2. Know the five traced entity types. User, Apex Class, Apex Trigger, Automated Process and Platform Integration. Questions about Flows or processes that seem invisible in a user's log usually point to the Automated Process user.
3. Memorise the numbers. 20 MB per log, 24-hour maximum trace flag duration, 24-hour retention for system logs, 7-day retention for monitoring logs, 1,000 MB in 15 minutes disables trace flags, and 180 days for Setup Audit Trail (a common distractor).
4. Order the levels correctly. NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST. If a question asks for the most detail, the answer is FINEST; if it asks how to reduce log size, the answer involves lowering levels on unneeded categories.
5. Remember that logging is prospective, not retrospective. A trace flag must be active before the transaction occurs. Any answer that implies you can enable logging and then view an error that happened yesterday is wrong.
6. Class and trigger trace flags refine; they do not initiate. If an option suggests setting a trace flag only on an Apex class to capture a user's error without any user trace flag, be suspicious.
7. Watch for permission traps. Viewing debug logs requires View All Data. A scenario where a sales user wants to see their own log is solved by the administrator, not by granting the user a profile change, unless the question explicitly asks for the permission.
8. Eliminate development-only answers. Checkpoints, Apex Replay Debugger and Execute Anonymous are developer features. In an administrator exam the expected answer is usually to set a trace flag in Setup and review the log, or to use the Developer Console's Log Inspector.
9. Do not confuse debug logs with Event Monitoring. Event Monitoring is for org-wide trend analysis and security monitoring via event log files and often requires an additional licence. Debug logs are for transaction-level troubleshooting of specific users or code.
10. When two answers both seem plausible, choose the least disruptive one. Salesforce exam answers favour setting a targeted, time-bound trace flag with an appropriate debug level over turning everything to FINEST or enabling logging for every user.
Quick Review Checklist
• Debug log = what happened during a transaction.
• Trace flag = who/what, when, and at what detail to log.
• Debug level = reusable set of category and level pairs.
• Setup path = Setup > Environments > Logs > Debug Logs; also Developer Console.
• Max log size 20 MB; trace flag max 24 hours; 1,000 MB per 15 minutes shuts logging off.
• Retention 24 hours (system) or 7 days (monitoring).
• View All Data needed to view logs.
• Automated Process user for Flows and processes running in system context.
• Class/trigger trace flags override levels but need an active user trace flag.
Master these points and you will be able to handle any debug log or trace flag question on the Advanced Administrator exam with confidence, and more importantly, troubleshoot real production issues quickly and safely.
Test mode:
Admin II - Debug Logs and Trace Flags Example Questions
Test your knowledge of Debug Logs and Trace Flags
Question 1
At Ursa Major Solar, a record-triggered flow on Opportunity fails intermittently for one sales user. The administrator sets a user trace flag on that user with a debug level that logs every category at a high verbosity. The resulting logs fill with Apex, database, and system entries from other automation on the object and are cut off before the flow's element details appear. Which recommendation best gives the administrator usable flow troubleshooting data?
Question 2
At Universal Containers, saving a quote runs a record-triggered flow that calls a custom invocable Apex class. A sales rep reports wrong discount values. The administrator captured a log for the rep with detailed levels across every category. The log was truncated before the class output appeared. The administrator needs fine-grained detail from that one class for this rep, with the rest of the transaction logged lightly. Which logging design meets this need?
Question 3
At Cloud Kicks, a sales rep runs a screen flow that calls a custom invocable Apex action. The action sometimes returns the wrong discount. The administrator's earlier debug logs for the rep were truncated because several other custom classes in the same transaction wrote verbose Apex entries. The administrator needs detailed entries for the invocable class while keeping Apex output from the other classes minimal. Which logging setup meets this requirement?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Debug Logs and Trace Flags questions
29 questions (total)
Other Auditing and Monitoring concepts
Data Classification Settings for Sensitive FieldsEncryption of Sensitive Data at RestEvent MonitoringField History Tracking and Field Audit TrailLogin History and Identity Verification HistoryMasking Sensitive Data in SandboxesRelease Updates That Change System AccessSecurity Health CheckSetup Audit Trail