Select Two (Multi-Select) Questions

Studio automatically commits changes to Git every time a file is saved.

Why it fails: Studio does not perform automatic commits. Commits must be initiated manually by the developer through the 'Team' tab or the Git panel. This gives developers the control to group related changes into logical commits, ensuring a clean and meaningful commit history that is easy to audit.

Git is only useful for large projects with more than ten developers.

Why it fails: Git is highly valuable even for single developers or small teams. It provides version history, the ability to revert changes, and a safe way to experiment with new features via branches. It is a best practice for all professional automation development, regardless of the team size or project complexity.

You must use an external Git client because Studio does not support Git.

Why it fails: UiPath Studio has built-in, native Git integration. While external clients can be used if preferred, they are not required. The Studio integration is designed to handle common source control tasks directly within the development environment, streamlining the workflow for developers and reducing the need to context-switch between applications.

The project can be published to Orchestrator even if violations exist.

Why it fails: Enabling the 'Enforce' option explicitly prevents the project from being published if any violations are detected. This is a design-time control mechanism intended to stop non-compliant code from entering the deployment pipeline. Therefore, allowing publication would defeat the primary purpose of the 'Enforce' flag during the build process.

The rule check is performed during runtime execution.

Why it fails: Workflow Analyzer rules are design-time checks performed within Studio, not runtime execution checks. Once a project is published and running on a Robot, these rules have already completed their task. Runtime checks for errors are managed by standard exception handling and logging mechanisms rather than static code analysis tools.

The analyzer will automatically correct the code that triggered the violation.

Why it fails: Workflow Analyzer identifies violations but does not have the capability to auto-correct code. The developer is responsible for manually adjusting the workflow, variable naming, or configuration to align with the active policy. This manual process ensures that the developer understands the changes being made to comply with project standards.

Log Message activity

Why it fails: Log Message is used for logging information but does not verify test outcomes. It cannot cause a test to pass or fail. While logging can be helpful for debugging, it is not essential for verifying the test outcome or enabling data-driven execution. The scenario requires activities that assert results and support multiple data sets, which Log Message does not provide.

Try Catch activity

Why it fails: Try Catch is used for exception handling, not for verifying test outcomes or enabling data-driven execution. While it can be useful in test cases to handle unexpected errors, it is not essential for the fundamental requirements of asserting results and running with multiple data sets. The test case can be properly structured without Try Catch, and it does not contribute to data-driven testing.

Delay activity

Why it fails: The Delay activity pauses the workflow for a specified amount of time. It is not related to verifying test outcomes or data-driven execution. While delays might be used in some tests to wait for elements, they are not essential for the core requirements of assertion and data variation. Including a Delay would not help the test case verify results or run with multiple data sets.

A Do While activity can only be used within a Flowchart, not a Sequence.

Why it fails: Both the While and Do While activities are standard control flow activities that can be used in both Sequences and Flowcharts. They are not restricted to a specific container type. Flowcharts often use Flow Decisions to create similar loops, but the dedicated loop activities are fully compatible with any container that supports activity placement.

A While activity automatically increments an index variable, while Do While does not.

Why it fails: Neither the While nor the Do While activity provides automatic index incrementing. Unlike the For Each activity, which handles the collection pointer for you, these loops require the developer to manually update the variables used in the condition. Failing to update these variables within the Body will result in an infinite loop regardless of which activity is used.

While activities support 'Break' while Do While activities do not support it.

Why it fails: The Break activity is supported in both While and Do While loops. It allows the developer to exit the loop immediately regardless of the condition's current state. This is a common pattern for handling unexpected errors or successful completion of a search within a loop, providing flexible control over the execution flow in both types of activities.

Use the Read Text File activity to load the whole file and then split each line manually in a loop

Why it fails: Read Text File returns a single string, not a DataTable, so the developer would have to parse delimiters, build column names, and construct rows manually. This is exactly the work Read CSV already performs. Choosing this path adds complexity and bug surface without any benefit, and it does not satisfy the requirement of producing a DataTable directly.

Set the Read CSV activity's Encoding property to a specific code page to change the delimiter interpretation

Why it fails: The Encoding property controls how bytes are decoded into characters, which matters for accented or non-Latin text, but it has no effect on which character separates fields. Delimiter selection is governed solely by the Delimiter property. Setting an encoding to fix a delimiter problem misdiagnoses the issue and leaves the parsed DataTable malformed.

Use the Excel Read Range activity inside Excel Application Scope, pointing at invoices.csv

Why it fails: Excel Application Scope and Read Range operate on Excel workbooks such as .xlsx files, not on plain delimited text files. Pointing them at a .csv typically fails or yields unexpected results because the file lacks the workbook structure the activity expects. The correct tool for a semicolon-delimited text file is the Read CSV activity.

Reduced disk space usage on the local robot machine

Why it fails: Structured logging does not inherently reduce the size of log files on the local machine. Disk space management is typically controlled by log rotation policies and retention settings in Orchestrator. Structured formats often add metadata overhead, which might slightly increase the size of the generated log files rather than decrease them.

Automatic encryption of all log entries before storage

Why it fails: Structured logging formats define the schema and organization of the log data but do not provide encryption by default. Encryption at rest is a configuration setting managed at the Orchestrator or database level. Developers must ensure that sensitive fields are masked before they are structured and sent to storage.

Elimination of the need for log levels

Why it fails: Log levels remain a fundamental component of the UiPath logging architecture regardless of the structure used. They determine the urgency and detail level of the message. Structured logging complements log levels by adding context, but it does not replace the requirement to classify messages based on their severity or importance.

The Object Repository is mandatory for all projects created in the Modern Experience.

Why it fails: While the Object Repository is a best practice and highly integrated with the Modern Experience, it is not strictly mandatory for every project. Developers can still use traditional selector techniques if needed, though using the Object Repository is strongly recommended for improved maintainability and project standardization.

The Object Repository only supports web-based applications.

Why it fails: The Object Repository is platform-agnostic and supports various UI technologies, including desktop applications, web browsers, and Java-based interfaces. Its flexibility allows it to serve as a unified management layer for diverse application environments, ensuring that developers can maintain a consistent workflow regardless of the underlying technology stack of the target.

Each UI element can only be associated with one specific Screen.

Why it fails: UI elements can be reorganized or moved across different screens within the repository structure. While elements are logically associated with screens, the repository allows for flexible management of these relationships to accommodate complex UI structures where the same element might potentially appear in different application contexts.

Catch the general 'System.Exception' type in all blocks to ensure no errors are missed.

Why it fails: Catching 'System.Exception' is too broad and can hide underlying issues that require specific handling. It makes debugging more difficult because it masks the precise cause of the failure, preventing the application of granular recovery logic tailored to different types of technical errors.

Always re-throw the original exception at the end of every 'Catch' block.

Why it fails: Re-throwing should only be done if the local handler cannot resolve the issue. Blindly re-throwing every exception defeats the purpose of the Try-Catch block, which is to handle errors locally whenever possible to allow the process to continue or fail gracefully without termination.

Place the entire workflow inside one massive Try-Catch block.

Why it fails: Wrapping everything in one block makes it impossible to implement specific recovery logic for different activities. If one part of the workflow fails, the entire process must terminate, reducing the robustness of the solution and making it harder to handle localized failures efficiently.

Checking if the workflow follows camelCase naming conventions.

Why it fails: CamelCase naming is a matter of code style and maintainability, not security. While it is an important rule to enforce for project consistency, it belongs under 'Naming Convention' rules, not 'Security' rules. Security rules specifically target threats to data and system integrity rather than stylistic aspects of the code base.

Validating the version number of the UiPath.System.Activities package.

Why it fails: Validating package versions is a function of package management and dependency rules, not security rules. While using outdated packages can pose security risks, the rule category specifically for this is 'Package Management'. Security rules are focused on the logic and data handling within the workflow files themselves.

Ensuring that the project icon is updated for the process.

Why it fails: Updating a project icon is purely aesthetic and has no relevance to the security or functional integrity of an automation project. It is not managed by the Workflow Analyzer's security rule set, as it does not address any threat models or potential vulnerabilities within the automation process or its data.

Logs are stored in the local Windows Event Viewer by default

Why it fails: UiPath logs are primarily sent to Orchestrator or a local log file, not to the Windows Event Viewer. While some system-level events might appear in the event logs, the application-level logs for workflow activity are handled by the UiPath logging infrastructure, which is separate from standard Windows system event logging.

Log messages from 'Write Line' are always sent to Orchestrator

Why it fails: The 'Write Line' activity is specifically limited to the Studio Output panel. It is designed for temporary local debugging and is intentionally excluded from the enterprise-level logging pipeline to prevent cluttering production logs and Orchestrator databases with transient, non-critical diagnostic information that should not exist in production code.

Hard-code folder paths within the library activities for consistency.

Why it fails: Hard-coding paths restricts reusability and causes failures in different environments where file structures differ. Libraries should instead use arguments to receive dynamic paths, ensuring the code remains flexible and functional regardless of the specific machine or directory structure where the automation process is ultimately executed.

Include the main process logic inside the library project.

Why it fails: Including main process logic in a library violates the separation of concerns. Libraries should house shared, reusable components, while the process project handles the orchestration of these components. Mixing them makes the library bloated, harder to maintain, and complicates versioning for the distinct automation logic.

It provides a built-in GUI designer for creating custom web forms.

Why it fails: The REFramework is a logic template based on a state machine, not a visual form designer. While it supports integration with Action Center or forms, it does not include a native GUI designer for creating custom web-based user interfaces.

It automatically eliminates the need for any manual testing.

Why it fails: While the REFramework is robust, it does not replace the requirement for thorough testing. Developers must still validate workflows against edge cases and business scenarios. Testing ensures that logic handles specific application behaviors correctly, which a template cannot predict or verify on its own.

It converts all Orchestrator assets into local hard-coded variables.

Why it fails: Hard-coding variables is a poor practice that violates the principles of maintainability and security. The REFramework encourages using Orchestrator assets to keep configurations external to the code, allowing environment-specific adjustments without needing to recompile or modify the underlying automation project files.

Switch

Why it fails: The Switch activity is a general-purpose control flow activity available in both Sequences and Flowcharts. In a Sequence, it appears as a container with different sections for each case. In a Flowchart, it is also available, although developers often prefer the Flow Switch for its visual representation of multiple outgoing connection points from a single node.

Pick

Why it fails: The Pick activity is a container activity that can be used in both Sequences and Flowcharts. It functions by containing PickBranch activities. While it manages branches, it does not rely on the Flowchart's connection lines to define those branches; instead, they are contained within the Pick activity itself, making it compatible with the linear structure of a Sequence.

Assign

Why it fails: Assign is one of the most fundamental activities in UiPath and is used to set the value of a variable. It is available in every container type, including Sequences, Flowcharts, and State Machines. It does not have any specialized Flowchart-only version, as variable assignment is a universal requirement across all types of workflow designs and control flow structures.

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.

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.

Email body content

Why it fails: Filtering by email body content is not natively supported in the basic 'Get Outlook Mail Messages' filter property. Trying to implement this would require retrieving all messages and using an 'If' condition post-retrieval, which is inefficient and significantly increases execution time for large mailboxes.

Attachment presence

Why it fails: While critical for logic, the native filter string of the activity does not support a direct 'hasAttachment' flag. Filtering for attachments must be handled within the loop after retrieval, making it an ineffective criterion for the initial server-side retrieval filter, though it remains a vital validation step.

Concatenating strings using the '+' operator.

Why it fails: Manual string concatenation with the '+' operator is error-prone and ignores OS-specific path separators. It often leads to double slashes or missing separators, causing File IO exceptions. Best practice dictates using built-in Path library methods to handle these nuances, ensuring that the automation remains stable across various deployment environments without manual path adjustment.

Hardcoding full paths using double backslashes in all variables.

Why it fails: Hardcoding paths creates fragile automations that fail when deployed to different machines or environments. It violates the core principle of environment-agnostic development. Automation developers should use configuration files or dynamic path resolution methods instead, allowing the bot to adapt to local file structures without requiring manual updates to the project code base.

Always using forward slashes for all file operations.

Why it fails: While some libraries support forward slashes, assuming universal compatibility is risky in complex enterprise environments. Relying on hardcoded characters rather than built-in path methods leads to inconsistent behavior across different .NET frameworks and OS versions. Always utilize the native Path class methods to ensure that delimiters are always appropriate for the runtime environment.

Hardcode test data directly into the workflow activities.

Why it fails: Hardcoding test data makes tests rigid and difficult to update. Best practice is to use external data sources or test data queues. This separation of data from logic allows for testing multiple scenarios with the same workflow, increasing test coverage and reducing the need to modify the workflow for new data.

Include complex UI interactions in every single unit test.

Why it fails: Including complex UI interactions in unit tests makes them slow and brittle. Unit tests should focus on business logic. UI interactions belong in end-to-end tests. Overloading unit tests with UI logic defeats the purpose of fast feedback loops, as environmental changes often cause tests to fail even if the logic is correct.

Use a While loop with a counter to manually retry the entire workflow on any exception.

Why it fails: A While loop with a counter can implement retries, but it does not inherently differentiate between system and business exceptions. Retrying the entire workflow on any exception would also retry business exceptions, which is not desired. This approach is less efficient and more error-prone than using built-in retry mechanisms.

Set the 'ContinueOnError' property to True for all activities that interact with applications.

Why it fails: Setting 'ContinueOnError' to True suppresses exceptions and allows the workflow to continue, but it does not provide retry logic or differentiate between exception types. It also may hide errors that should be handled, leading to incorrect processing. This is not a suitable solution for the requirement.

Configure the Global Exception Handler to retry all exceptions a fixed number of times.

Why it fails: The Global Exception Handler is used for unhandled exceptions and does not provide per-exception-type retry logic. Retrying all exceptions, including business exceptions, is incorrect because business exceptions should not be retried. This approach does not meet the requirement to differentiate between exception types.

Enable logging for the variable to track its value in Orchestrator.

Why it fails: The Variables panel does not include a logging option. Logging is handled through activities such as Log Message or Write Line, or via Orchestrator settings. There is no per-variable logging toggle in the Variables panel. This option describes a feature that does not exist.

Convert the variable into an argument automatically.

Why it fails: Variables and arguments are distinct concepts. Arguments are used to pass data between workflows and are defined in the Arguments panel. The Variables panel does not have a feature to convert a variable into an argument. You must manually create an argument and adjust the workflow.

Reorder the variable's position in the panel to change its scope.

Why it fails: The order of variables in the Variables panel does not affect their scope. Scope is determined by the container in which the variable is declared and can be changed via the Scope drop-down. Reordering is not a supported action and would not alter variable behavior.

Always increase the 'TimeoutMS' property to a very high value like 300,000.

Why it fails: Setting extremely high timeouts can lead to slow execution and poor performance without solving the root cause of selector instability. Proper timeouts should be based on expected application load times rather than arbitrarily large numbers which hide underlying performance issues in the target application.

Avoid using 'UiExplorer' as it generates overly complex selectors.

Why it fails: UiExplorer is the recommended tool for identifying stable selectors and testing them. It provides full control over selector attributes and is essential for finding the most robust combination of tags, which is necessary for avoiding SelectorNotFoundExceptions during the execution of complex UI-based automation processes.