Troubleshooting practice questions

Which log level should be used when logging sensitive information such as user passwords or personal identification numbers in a production environment?

Trap 1: Trace

Trace logs capture highly granular details often used during local debugging. While this level records much data, it is not an excuse to log sensitive information. Security best practices mandate that passwords and PII must never be stored in plain text within log files regardless of the chosen severity level.

Trap 2: Verbose

Verbose logging provides extensive diagnostic data about variable states and activity flow. While useful for complex troubleshooting, it remains subject to strict security policies. Sensitive data must be excluded from all logs, as verbose logging is frequently forwarded to centralized systems where unauthorized personnel might gain access to logs.

Trap 3: Error

Error logs capture events that prevent the automation from proceeding normally. Even during an error, developers must ensure that data dumped to the log file does not contain plain-text credentials or sensitive user data. Logging sensitive information at an error level is still a critical security vulnerability that requires mitigation.

A
Trace
Why it fails: Trace logs capture highly granular details often used during local debugging. While this level records much data, it is not an excuse to log sensitive information. Security best practices mandate that passwords and PII must never be stored in plain text within log files regardless of the chosen severity level.
B
Verbose
Why it fails: Verbose logging provides extensive diagnostic data about variable states and activity flow. While useful for complex troubleshooting, it remains subject to strict security policies. Sensitive data must be excluded from all logs, as verbose logging is frequently forwarded to centralized systems where unauthorized personnel might gain access to logs.
C
None of the above
No log level is appropriate for logging sensitive information. Security standards explicitly prohibit exposing passwords or PII in logs, as these files are often accessible to support teams and monitoring systems. Developers must implement data masking or use secure credential stores to handle sensitive data without writing it to disk.
D
Error
Why it fails: Error logs capture events that prevent the automation from proceeding normally. Even during an error, developers must ensure that data dumped to the log file does not contain plain-text credentials or sensitive user data. Logging sensitive information at an error level is still a critical security vulnerability that requires mitigation.

Question 2mediummultiple choice

What is the best way to handle logging when working with large datasets in a loop?

Trap 1: Log every single item processed inside the loop

Logging every item in a large loop leads to an explosion of log data, often referred to as log bloat. This can crash log aggregators, consume excessive disk space, and make it impossible for humans to find relevant information, effectively rendering the logs useless for day-to-day monitoring and troubleshooting tasks.

Trap 2: Disable all logs during the execution of the loop

Disabling logs entirely is risky, as it leaves the developer blind if an error occurs mid-loop. It is better to have sparse logs than no logs at all. A balanced approach of conditional or summary logging ensures that both progress tracking and error observability are maintained during high-volume operations.

Trap 3: Always set the log level to 'Trace' during the loop

Trace logging inside a loop is the worst-case scenario for performance. It will generate an enormous amount of data for every single iteration, guaranteed to cause major performance bottlenecks and potential crashes of the logging infrastructure. This level should be avoided entirely for any high-volume, iterative processing tasks.

A
Log every single item processed inside the loop
Why it fails: Logging every item in a large loop leads to an explosion of log data, often referred to as log bloat. This can crash log aggregators, consume excessive disk space, and make it impossible for humans to find relevant information, effectively rendering the logs useless for day-to-day monitoring and troubleshooting tasks.
B
Use the 'Log Message' activity with a condition to log every N items
Conditional logging allows for tracking progress without the performance penalty of logging every single iteration. By logging every N items, the developer gets a heartbeat of the process execution, ensuring visibility into the loop's status while keeping the overall log volume manageable and meaningful for analysis and monitoring purposes.
C
Disable all logs during the execution of the loop
Why it fails: Disabling logs entirely is risky, as it leaves the developer blind if an error occurs mid-loop. It is better to have sparse logs than no logs at all. A balanced approach of conditional or summary logging ensures that both progress tracking and error observability are maintained during high-volume operations.
D
Always set the log level to 'Trace' during the loop
Why it fails: Trace logging inside a loop is the worst-case scenario for performance. It will generate an enormous amount of data for every single iteration, guaranteed to cause major performance bottlenecks and potential crashes of the logging infrastructure. This level should be avoided entirely for any high-volume, iterative processing tasks.

Question 3easymultiple choice

Where can a developer configure the logging level for a specific robot connected to Orchestrator?

Trap 1: In the UiPath.settings file on the Robot machine

While the UiPath.settings file contains local configuration parameters, logging levels for robots managed by Orchestrator are typically overridden or centrally managed by the Orchestrator server. Changing local files might be temporary, as Orchestrator settings often push down configurations that overwrite local changes, making Orchestrator the standard place for management.

Trap 2: Inside the UiPath Studio Project settings

Studio settings define the development environment configurations, such as default naming conventions or library dependencies. They do not dictate the runtime logging level of an unattended robot executing in a production environment. Logging levels must be managed at the execution tier to ensure appropriate visibility during runtime operations.

Trap 3: In the Windows Event Viewer

Windows Event Viewer displays system and application-level logs but does not control the UiPath robot log generation level. Configuring logging levels requires interaction with the UiPath management interface, as the robot is an application running on Windows, not a service whose internal log verbosity is managed by the OS.

A
In the UiPath.settings file on the Robot machine
Why it fails: While the UiPath.settings file contains local configuration parameters, logging levels for robots managed by Orchestrator are typically overridden or centrally managed by the Orchestrator server. Changing local files might be temporary, as Orchestrator settings often push down configurations that overwrite local changes, making Orchestrator the standard place for management.
B
In the Orchestrator Robot or Machine settings
The Orchestrator provides a centralized interface to manage robot configurations, including the log level. This allows administrators to change the logging verbosity for specific machines or robot environments without requiring direct access to the remote machine, ensuring consistency and ease of maintenance across large-scale enterprise automation deployments.
C
Inside the UiPath Studio Project settings
Why it fails: Studio settings define the development environment configurations, such as default naming conventions or library dependencies. They do not dictate the runtime logging level of an unattended robot executing in a production environment. Logging levels must be managed at the execution tier to ensure appropriate visibility during runtime operations.
D
In the Windows Event Viewer
Why it fails: Windows Event Viewer displays system and application-level logs but does not control the UiPath robot log generation level. Configuring logging levels requires interaction with the UiPath management interface, as the robot is an application running on Windows, not a service whose internal log verbosity is managed by the OS.

Question 4hardmultiple choice

When a job is triggered but stays in 'Pending' status indefinitely, what is the most likely reason?

Trap 1: The Orchestrator database is corrupted.

Database corruption would manifest as broad system failures, service errors, or 500 status codes across the entire platform, not just a single job sitting in 'Pending' status. Pending jobs are a standard operational state and almost always trace back to robot connectivity or configuration issues rather than backend database errors.

Trap 2: The process package has been deleted from the project folder.

If a process package were missing, the Orchestrator would fail to start the job, likely resulting in an error state rather than a 'Pending' status. 'Pending' specifically implies that the system is actively looking for a robot but hasn't found one that meets all the necessary execution criteria yet.

Trap 3: The machine key is expired.

Machine keys do not have an expiration date in the traditional sense; they are either valid or revoked. If a key was invalid or revoked, the robot would show as 'Disconnected'. A 'Pending' status indicates that the Orchestrator is operational, but the resource assignment logic is unable to find a suitable robot match.

A
The Orchestrator database is corrupted.
Why it fails: Database corruption would manifest as broad system failures, service errors, or 500 status codes across the entire platform, not just a single job sitting in 'Pending' status. Pending jobs are a standard operational state and almost always trace back to robot connectivity or configuration issues rather than backend database errors.
B
The robot is not associated with the folder or lacks the required process/license.
A job remains 'Pending' when no robot is available to execute it. This happens if no robots are connected, the connected robots are not part of the folder where the process exists, or the robot is missing the specific license or process version required to execute the assigned task.
C
The process package has been deleted from the project folder.
Why it fails: If a process package were missing, the Orchestrator would fail to start the job, likely resulting in an error state rather than a 'Pending' status. 'Pending' specifically implies that the system is actively looking for a robot but hasn't found one that meets all the necessary execution criteria yet.
D
The machine key is expired.
Why it fails: Machine keys do not have an expiration date in the traditional sense; they are either valid or revoked. If a key was invalid or revoked, the robot would show as 'Disconnected'. A 'Pending' status indicates that the Orchestrator is operational, but the resource assignment logic is unable to find a suitable robot match.

Question 5hardmulti select

Which THREE practices are recommended when troubleshooting failed UI interactions involving the Object Repository?

Trap 1: Reset the computer to clear temporary UI cache files.

Resetting the computer is unnecessary and does not resolve issues with UI selectors or repository configurations. UI interactions are governed by the browser's DOM or the application's native structure, not by OS-level cache files. This is a non-technical suggestion that wastes time and fails to address the root cause of selector failures.

Trap 2: Reinstall the UiPath Studio extension for the browser.

Reinstalling the extension is a extreme measure only used if the extension is completely broken or unresponsive. Most UI interaction issues are related to selector definitions or application states, not the extension itself. Blindly reinstalling tools is a poor debugging practice that ignores the diagnostic process required for finding the real error.

A
Use the 'Validate' function in the Object Repository to check the selector.
The 'Validate' function is the first step in confirming whether the current descriptor matches the application. If it fails, the developer knows immediately that the selector is out of sync with the application structure. This saves time by narrowing down the issue to the descriptor definition itself rather than the workflow logic.
B
Reset the computer to clear temporary UI cache files.
Why it fails: Resetting the computer is unnecessary and does not resolve issues with UI selectors or repository configurations. UI interactions are governed by the browser's DOM or the application's native structure, not by OS-level cache files. This is a non-technical suggestion that wastes time and fails to address the root cause of selector failures.
C
Verify that all variables used in the selector have valid values at runtime.
If a selector is parameterized, it will fail if the variables are null or contain incorrect data. Checking these values at runtime ensures that the final selector string being sent to the application is valid. This is a common point of failure in dynamic automation scenarios and must be verified during troubleshooting.
D
Inspect the application for overlapping elements or visibility issues.
Even with a valid selector, an element might be covered by another UI component or hidden behind a modal. Checking the Z-index or visibility in the browser's developer tools helps confirm if the element is actually interactable. This is critical for diagnosing 'Element not clickable' errors, which often occur despite having a correct selector.
E
Reinstall the UiPath Studio extension for the browser.
Why it fails: Reinstalling the extension is a extreme measure only used if the extension is completely broken or unresponsive. Most UI interaction issues are related to selector definitions or application states, not the extension itself. Blindly reinstalling tools is a poor debugging practice that ignores the diagnostic process required for finding the real error.

Question 6hardmultiple choice

When designing a custom logging framework, which approach is most effective for ensuring consistent log correlation across multiple workflows?

Trap 1: Log the timestamp of every activity execution

Timestamps are useful but insufficient for correlation, as multiple process instances may run simultaneously. Relying on time-based filtering in high-concurrency environments leads to noise and incorrect associations. Correlation IDs are explicitly designed to link related log entries regardless of when they occur, providing a much more accurate tracing mechanism.

Trap 2: Use the Robot ID to group all logs together

Robot IDs identify the machine executing the task, not the business process instance. If one robot runs multiple tasks in parallel or sequence, the logs will intermingle, making it impossible to separate data related to a single business process. Robot IDs lack the granularity required for effective cross-workflow transaction tracing.

Trap 3: Write logs to a local text file and sort by file size

Sorting logs by file size is a storage management practice and has no relevance to the logic of log correlation. It does not help in identifying which log entries belong to the same business process. Effective correlation must be based on metadata identifiers present within the log content itself.

A
Log the timestamp of every activity execution
Why it fails: Timestamps are useful but insufficient for correlation, as multiple process instances may run simultaneously. Relying on time-based filtering in high-concurrency environments leads to noise and incorrect associations. Correlation IDs are explicitly designed to link related log entries regardless of when they occur, providing a much more accurate tracing mechanism.
B
Use the Robot ID to group all logs together
Why it fails: Robot IDs identify the machine executing the task, not the business process instance. If one robot runs multiple tasks in parallel or sequence, the logs will intermingle, making it impossible to separate data related to a single business process. Robot IDs lack the granularity required for effective cross-workflow transaction tracing.
C
Pass a unique Correlation ID through arguments across workflows
Passing a unique identifier through arguments allows developers to attach a common tag to every log entry across different workflow files. This ensures that when querying a log aggregator, one can search for a single ID and retrieve the entire chronological execution path of that specific business transaction.
D
Write logs to a local text file and sort by file size
Why it fails: Sorting logs by file size is a storage management practice and has no relevance to the logic of log correlation. It does not help in identifying which log entries belong to the same business process. Effective correlation must be based on metadata identifiers present within the log content itself.

Question 7hardmultiple choice

A developer is troubleshooting a production automation that intermittently fails to process certain PDFs. They need to capture detailed diagnostic information, including variable values and execution flow, but only when the failure occurs. They want to minimize log volume and avoid exposing sensitive data. Which approach should they take?

Trap 1: Use the 'Add Log Fields' activity to add relevant variable values…

Add Log Fields attaches custom fields to all subsequent log messages, which can be useful for correlation. However, it does not control when logs are generated; it only enriches existing logs. It would not capture detailed diagnostic information only on failure, and it might expose sensitive data if the fields contain such information. It does not address the need for conditional, detailed logging.

Trap 2: Configure the robot's log level to 'Verbose' and rely on the…

Setting the robot's log level to Verbose increases the verbosity of system-generated logs, but it does not automatically log custom variable values. Default execution logs include activity names and timestamps but not arbitrary variable contents. This approach would increase log volume without providing the specific diagnostic details needed, and it does not limit logging to failure scenarios.

Trap 3: Set the global log level to 'Trace' and add Log Message activities…

Setting the global log level to Trace captures all messages, including Trace-level logs, which can generate a massive volume of data. This approach does not limit logging to failure scenarios and may inadvertently capture sensitive information if variable values are logged. It is inefficient for production and does not meet the requirement to minimize log volume or selectively capture data only on failure.

A
Use the 'Add Log Fields' activity to add relevant variable values to the log context at the start of the process.
Why it fails: Add Log Fields attaches custom fields to all subsequent log messages, which can be useful for correlation. However, it does not control when logs are generated; it only enriches existing logs. It would not capture detailed diagnostic information only on failure, and it might expose sensitive data if the fields contain such information. It does not address the need for conditional, detailed logging.
B
Configure the robot's log level to 'Verbose' and rely on the default execution logs to capture variable values.
Why it fails: Setting the robot's log level to Verbose increases the verbosity of system-generated logs, but it does not automatically log custom variable values. Default execution logs include activity names and timestamps but not arbitrary variable contents. This approach would increase log volume without providing the specific diagnostic details needed, and it does not limit logging to failure scenarios.
C
Set the global log level to 'Trace' and add Log Message activities with Trace level throughout the workflow.
Why it fails: Setting the global log level to Trace captures all messages, including Trace-level logs, which can generate a massive volume of data. This approach does not limit logging to failure scenarios and may inadvertently capture sensitive information if variable values are logged. It is inefficient for production and does not meet the requirement to minimize log volume or selectively capture data only on failure.
D
Implement a Try Catch block around the PDF processing, and in the Catch block, use Log Message activities with 'Error' level to log variable values and then rethrow the exception.
This approach captures detailed diagnostic information only when an exception occurs. By placing Log Message activities in the Catch block, the developer can log specific variable values and context at the moment of failure. Using the Error level ensures these logs are captured even if the global log level is set higher. It minimizes log volume during normal operation and allows selective data capture, avoiding exposure of sensitive data except on failure.

Question 8mediummultiple choice

A developer notices that a UiPath automation is producing an excessive number of log entries in Orchestrator, making it difficult to identify errors. The developer wants to reduce the volume of logs without losing important error information. Which action should the developer take?

Trap 1: Remove all Log Message activities from the workflows and rely…

Removing Log Message activities eliminates custom diagnostic entries but does not control the volume of automatic logs, which can still be verbose. It also removes valuable context that could help troubleshoot issues. The better approach is to adjust the logging level, which filters both custom and automatic entries uniformly.

Trap 2: Disable logging entirely for the robot by setting the logging level…

Disabling logging entirely prevents any log entries, including errors, from being recorded. This would eliminate the ability to diagnose failures and is not a viable option for production monitoring. The developer needs to reduce volume while retaining error information, so a level like Warning is appropriate.

Trap 3: Set the logging level to Verbose to capture all details, then use…

Setting the level to Verbose increases log volume dramatically, as it captures the most detailed entries. While Orchestrator can filter, the sheer volume can impact performance and storage. This is the opposite of reducing log volume and would make it harder to identify errors among the noise.

A
Change the robot's logging level from Information to Warning in Orchestrator.
Raising the minimum log level to Warning filters out Information, Verbose, and Trace entries, significantly reducing log volume while still capturing Warning, Error, and Critical messages. This preserves important error information and is a standard configuration change in Orchestrator for production robots to keep logs manageable.
B
Remove all Log Message activities from the workflows and rely solely on automatic logging.
Why it fails: Removing Log Message activities eliminates custom diagnostic entries but does not control the volume of automatic logs, which can still be verbose. It also removes valuable context that could help troubleshoot issues. The better approach is to adjust the logging level, which filters both custom and automatic entries uniformly.
C
Disable logging entirely for the robot by setting the logging level to None.
Why it fails: Disabling logging entirely prevents any log entries, including errors, from being recorded. This would eliminate the ability to diagnose failures and is not a viable option for production monitoring. The developer needs to reduce volume while retaining error information, so a level like Warning is appropriate.
D
Set the logging level to Verbose to capture all details, then use Orchestrator's filtering to find errors.
Why it fails: Setting the level to Verbose increases log volume dramatically, as it captures the most detailed entries. While Orchestrator can filter, the sheer volume can impact performance and storage. This is the opposite of reducing log volume and would make it harder to identify errors among the noise.

Question 9hardmulti select

A developer is designing a UiPath automation that processes sensitive customer data. The developer needs to ensure that log entries do not contain personally identifiable information (PII) while still allowing effective troubleshooting. Which two actions should the developer take? (Choose two.)

Trap 1: Use the Add Log Fields activity to add a custom field containing…

Adding PII such as a full name as a custom log field directly violates the requirement to avoid logging sensitive data. Custom fields are included in every subsequent log entry and are visible in Orchestrator, so this would expose PII. Instead, non-sensitive identifiers like a hashed customer ID should be used.

Trap 2: Set the robot's logging level to Verbose to capture all details,…

Setting the level to Verbose increases the risk of logging sensitive data because more detailed messages are captured. Manual redaction is error-prone and does not prevent PII from being stored in Orchestrator. The goal is to avoid logging PII in the first place, not to redact after the fact.

Trap 3: Use the Log Message activity with Level set to Error to log the…

Logging the full customer record, even at Error level, still writes PII to the logs. Error-level entries are not automatically encrypted or restricted, and they persist in Orchestrator. This action would violate the requirement to avoid logging sensitive data, regardless of the severity level used.

A
Use the Add Log Fields activity to add a custom field containing the customer's full name for easy identification in logs.
Why it fails: Adding PII such as a full name as a custom log field directly violates the requirement to avoid logging sensitive data. Custom fields are included in every subsequent log entry and are visible in Orchestrator, so this would expose PII. Instead, non-sensitive identifiers like a hashed customer ID should be used.
B
Set the robot's logging level to Verbose to capture all details, then manually redact sensitive information from the logs before sharing them.
Why it fails: Setting the level to Verbose increases the risk of logging sensitive data because more detailed messages are captured. Manual redaction is error-prone and does not prevent PII from being stored in Orchestrator. The goal is to avoid logging PII in the first place, not to redact after the fact.
C
Replace direct logging of sensitive values with references to non-sensitive identifiers, such as a hashed customer ID or a queue item reference.
Using non-sensitive identifiers allows the developer to correlate log entries with specific customers or transactions without exposing PII. A hashed ID or queue reference provides traceability for troubleshooting while ensuring that the actual sensitive data is never written to logs, satisfying both security and diagnostic needs.
D
Configure the automation to log only non-sensitive metadata, such as timestamps, status codes, and transaction outcomes, for each processing step.
Logging only non-sensitive metadata provides a record of the automation's execution without exposing PII. Timestamps, status codes, and outcomes are sufficient for troubleshooting and auditing while ensuring compliance with data protection policies. This approach minimizes the risk of accidental PII exposure in logs.
E
Use the Log Message activity with Level set to Error to log the full customer record when an exception occurs, ensuring that support can see the data.
Why it fails: Logging the full customer record, even at Error level, still writes PII to the logs. Error-level entries are not automatically encrypted or restricted, and they persist in Orchestrator. This action would violate the requirement to avoid logging sensitive data, regardless of the severity level used.

Question 10hardmultiple choice

A developer is troubleshooting a workflow that intermittently fails to click a 'Confirm' button on a checkout page. The button is stored in the Object Repository with a strict selector and an anchor set to the nearby 'Order Total' label. The failure occurs only when a promotional banner appears above the button. Which explanation best accounts for the intermittent failure?

Trap 1: The anchor's fuzzy matching threshold is too high, so it rejects…

The scenario states the anchor is the 'Order Total' label, which remains on the page when the banner appears. A high fuzzy threshold would cause anchor rejection, but the label itself is unaffected by the banner, so this does not explain the intermittent behaviour tied to the banner. The failure is in resolving the target, not the anchor.

Trap 2: The 'Confirm' button's selector uses the 'Order Total' label as its…

An anchor is a separate element used for context; it is not merged into the target's attribute set. The button's selector does not derive its matching attributes from the anchor label. Even if the label text changed, that would affect the anchor, not the button's strict selector, so this does not explain the banner-related failure.

Trap 3: The Object Repository cannot store anchors and strict selectors…

The Object Repository does support storing both a target selector and one or more anchors for an element. They are evaluated together at runtime, with the anchor constraining the search region. Claiming the anchor is silently ignored is factually incorrect and does not match the observed behaviour, which depends on the banner's presence.

A
The anchor's fuzzy matching threshold is too high, so it rejects the 'Order Total' label whenever the banner is visible.
Why it fails: The scenario states the anchor is the 'Order Total' label, which remains on the page when the banner appears. A high fuzzy threshold would cause anchor rejection, but the label itself is unaffected by the banner, so this does not explain the intermittent behaviour tied to the banner. The failure is in resolving the target, not the anchor.
B
The 'Confirm' button's selector uses the 'Order Total' label as its own attribute, so the banner changes that label's text and breaks the match.
Why it fails: An anchor is a separate element used for context; it is not merged into the target's attribute set. The button's selector does not derive its matching attributes from the anchor label. Even if the label text changed, that would affect the anchor, not the button's strict selector, so this does not explain the banner-related failure.
C
The anchor element still matches, but the strict selector for the button now resolves to a different element because the banner shifts the DOM, so the target is found incorrectly or not at all.
Anchors help locate a target but do not override an incorrect strict selector match. If the banner changes the DOM such that the strict selector's attributes now match another element or none, the click fails or hits the wrong control even though the anchor is present. The anchor narrows the region; it does not guarantee the target selector is correct.
D
The Object Repository cannot store anchors and strict selectors together, so the anchor is silently ignored at runtime.
Why it fails: The Object Repository does support storing both a target selector and one or more anchors for an element. They are evaluated together at runtime, with the anchor constraining the search region. Claiming the anchor is silently ignored is factually incorrect and does not match the observed behaviour, which depends on the banner's presence.

Question 11easymultiple choice

A developer is troubleshooting a UiPath automation and wants to see the values of variables at various points during execution. Which activity should the developer use to write a custom diagnostic message to the UiPath logs with a specified severity level?

Trap 1: Write Line

Write Line outputs text to the console or output pane and does not create a structured log entry with a severity level. It is not captured by Orchestrator's logging system, so it cannot be used to record diagnostic messages that appear in robot logs or support troubleshooting through centralized logs.

Trap 2: Add Log Fields

Add Log Fields attaches custom metadata to subsequent log entries but does not itself create a log message. Without a Log Message activity, no entry is written. It is used to enrich logs with context such as transaction IDs, not to output diagnostic variable values at a chosen severity.

Trap 3: Message Box

Message Box displays a modal dialog to the user and is intended for interactive notifications, not logging. It does not write to the UiPath logs, has no severity level, and would block unattended execution, making it unsuitable for diagnostic logging during troubleshooting.

A
Write Line
Why it fails: Write Line outputs text to the console or output pane and does not create a structured log entry with a severity level. It is not captured by Orchestrator's logging system, so it cannot be used to record diagnostic messages that appear in robot logs or support troubleshooting through centralized logs.
B
Log Message
The Log Message activity writes a custom message to the UiPath logs and allows the developer to select a severity level such as Info, Warn, Error, or Verbose. It is the standard activity for adding diagnostic entries that appear in Orchestrator logs and local robot logs, making it ideal for troubleshooting variable values.
C
Add Log Fields
Why it fails: Add Log Fields attaches custom metadata to subsequent log entries but does not itself create a log message. Without a Log Message activity, no entry is written. It is used to enrich logs with context such as transaction IDs, not to output diagnostic variable values at a chosen severity.
D
Message Box
Why it fails: Message Box displays a modal dialog to the user and is intended for interactive notifications, not logging. It does not write to the UiPath logs, has no severity level, and would block unattended execution, making it unsuitable for diagnostic logging during troubleshooting.