Naming conventions and strategies

Using clear names for everything in UiPath – workflows, variables, and more – makes your projects easier to understand now and in the future. We’ll show you how in the next sections.


Consistent naming conventions are crucial for improving the readability, maintainability, and overall quality of your UiPath projects in both Studio and Orchestrator. Here’s a breakdown of key points to consider for variables:

Variables - Best pratices Uipath
Variables – Best pratices Uipath

UiPath Variable Naming Best Practices: A Professional Guide

Aspect Description Recommendation Benefits Example
Case Sensitivity While only arguments are case-sensitive, consistency is recommended. PascalCase (Upper Camel Case): Each word starts with a capital letter, no separators. Improved code readability and maintainability across the project. FirstName, OrderTotal, isProcessed
Naming Convention Select a clear and unambiguous convention. PascalCase is widely used and promotes clarity. Ensures everyone understands variable purpose at a glance. customerName, extractedDataDt
Single Purpose Each variable should have a well-defined, unique role. Minimize global variables. Prioritize local scoping for clarity. Enhances code organization and reduces potential errors. customerAddress (specific) vs. data (generic)
Scope Awareness Declare variables within the most relevant scope. Avoid cluttering the Variables panel. Ensure autocomplete suggests relevant names. Improves code locality and reduces potential naming conflicts. Use variables within the activity they’re used for.
Proximity Group statements working with the same variable(s). Improves code flow and maintainability. Makes code easier to understand and follow. Keep statements using customerName together.
Clarity Use descriptive and meaningful names that reflect the variable’s content. Clearly convey the variable’s purpose. Enhances code self-documentation and reduces the need for comments. extractedCustomerData instead of data.
Length Aim for a balance between readability and conciseness (6-20 characters). Consider abbreviations for longer words, but prioritize clarity. Optimizes screen space and ensures clear variable identification. companyName preferred over company (local scope).
Boolean Variables Use positive naming with Is or Has prefixes. Imply True or False states clearly. Enhances readability and avoids confusion about variable state. isOrderValid, hasEnoughStock
Data Table Variables Append the suffix Dt for easy identification. Distinguish data tables from other variable types. Improves code organization and simplifies data table handling. customerListDt, extractedDataDt


UiPath Argument Naming Best Practices: A Comprehensive Guide

Aspect Description Recommendation Benefits Example
Case Sensitivity Arguments are case-sensitive. Employ Upper Camel Case with a direction prefix. Enhanced code readability and maintainability for your UiPath projects. in_DefaultTimeout, out_TextResult
Naming Convention Establish a clear and consistent convention. Utilize Upper Camel Case combined with direction prefixes (in_, out_, io_). Ensures all team members understand argument purpose and direction at a glance. in_ApplicationPath, out_ProcessedRecords, io_RetryCount
Direction Prefix Employ prefixes to denote argument direction. Standardize on: * in_ for input arguments * out_ for output arguments * io_ for arguments that function as both input and output. Improves code clarity and avoids confusion about how arguments are used. See examples above.
Default Values Consider incorporating default values for testing and reusability. Utilize default values for individual workflow testing or reusable components (remove before publishing). Simplifies testing workflows in isolation and promotes reusability by providing default configurations. in_DefaultTimeout=30
Length Strive for a balance between conciseness and readability (ideally less than 30 characters). Use abbreviations strategically, prioritizing clarity over brevity. Optimizes screen space and ensures clear identification of arguments within your workflows. in_Retries preferred over in_MaximumNumberOfRetries
Argument Count Maintain manageability within workflows. Aim for fewer than 20 arguments per workflow to enhance maintainability. Reduces complexity and improves the overall comprehension of your code. Consider splitting workflows into smaller components if the argument count becomes excessive.
Serialization Ensure data transferability when using isolated workflows. Avoid non-serializable types (e.g., SecureString) when arguments are passed in isolated workflows. Guarantees data can be safely transferred between separate system processes. Opt for string or integer types instead of SecureString for isolated workflows.


  • This table incorporates best practices for variables, with modifications specific to argument naming conventions.
  • The final row emphasizes an additional consideration for argument usage within isolated workflows.

By adhering to these professional guidelines, you can establish a well-structured and maintainable foundation for your UiPath arguments, fostering efficient collaboration and long-term project health.


  • Rename all the activities in a project: do not keep the default name of the activities, give meaning full name (including Log Message, Assign, If, Sequence) 
  • Give meaningful name for the (Click, Type Into, Element Exists, etc) for example  “Click” to “Click_Button_Save” ActivityName_Type_textName

Workflow files

Clear and descriptive workflow names are crucial for readability and maintainability in UiPath. Here’s a breakdown of key points:

  • Naming Convention: Use Upper Camel Case (each word starts with a capital letter, no separators). This makes names easy to read and understand.
  • Verb-Oriented Names: Except for “Main,” all workflows should have a verb at the beginning that describes their action (e.g., GetTransactionData.xamlProcessTransaction.xaml). Aim for clear verbs that convey the workflow’s purpose.
  • Application Prefix: Consider adding a prefix to indicate the application the workflow interacts with (e.g., SAP_Login.xamlSAP_ExtractClientReport.xaml). This helps with organization and identification.
  • Folder Structure: Group workflows for the same application or system together within a single folder under the project root. For large applications, use subfolders for further categorization.
  • Template Framework: Don’t modify standard framework files (including Main.xaml) that come pre-created when using a template framework.
  • Test Framework: Use the prefix Test_ for test workflow files and place them in the designated Test_Framework folder if using a test framework.

Benefits of Following These Guidelines:

  • Improved Code Readability: Clear names make it easier to understand what a workflow does without having to open it.
  • Enhanced Maintainability: Well-named workflows are easier to locate, modify, and troubleshoot later.
  • Efficient Project Organization: Grouping workflows by application and purpose simplifies project navigation.

Projects and sub-projects

UiPath projects and sub-projects require clear and consistent naming conventions to ensure efficient organization and collaboration. Here’s a breakdown of key points:

  • Naming Convention: Employ Upper Camel Case (each word starts with a capital letter, no separators) for both projects and sub-projects. This enhances readability and maintainability.
  • Project Naming: Consider incorporating a prefix that reflects the department or area responsible for the process (e.g., FIN_HR_RPA_). Additionally, include a unique ID and a descriptive name that captures the process’s purpose. Here are some examples:
    • FIN_001_DataCollection (Finance department, process ID 001, Data Collection functionality)
    • RPA005_InvoiceProcessing (No department prefix needed, process ID 005, Invoice Processing functionality)
  • Sub-project Naming: When using sub-processes (multiple packages for a single business process), append a suffix to the main project name to differentiate them. Common suffixes include:
    • _Dispatcher: Denotes a sub-project responsible for task distribution or initiation. (e.g., FIN_001_DataCollection_Dispatcher)
    • _Performer: Indicates a sub-project that executes the actual automation tasks. (e.g., FIN_001_DataCollection_Performer)

Orchestrator Naming Conventions


Robots are machines that execute UiPath automations. Here’s a breakdown of their naming conventions:

Environment Naming Convention Example Description
Development DEV_[Name of developer] (Upper Camel Case) DEV_JohnDoe Identifies the developer responsible for the development machine.
Test/QA QA_[Machine Name][Robot Number] QA_Server1_Robot2 Combines machine name and a robot number for test/QA environments.
Production [Machine Name][Robot Number] ServerA_Robot3 Uses machine name and robot number for production environments (no prefix).


Environments group robots working on the same processes. Their naming reflects this association:

Prefix Description Example
DEV_, TEST_, PROD_ Environment type (Development, Test, Production) DEV_Finance
Department prefix (Optional) Department or area using the automation FIN_ (Finance department)


Assets are reusable elements within UiPath projects. Here’s how to name them effectively:

Asset Type Naming Convention Example Description
Usual assets [Department][Project code][Asset Name] AR_CA_MappingTableURL Combines department, project code, and a descriptive asset name.
Credentials C_[Expiration period][Department][Project code]_[Asset Name] C_180_AP_SC_SapCredentials Includes expiration period, department, project code, and a descriptive name for credentials.


Queues Queues are used for communication between robots. Their naming follows this structure:

Naming Convention Example Description
[Department][Project code][Queue Name] AR_CA_ExcelItems Combines department, project code, and a descriptive name for the queue.

By adhering to these best practices, you can establish a well-structured and efficient Orchestrator environment, streamlining your UiPath automation processes.

Configurations Management Best Practices

This table summarizes key strategies for managing configurations in UiPath projects, ensuring maintainability, flexibility, and efficient development workflows.

Configuration Type Storage Recommendation Description Benefits Example
Never-Changing Values Hardcoded in Workflows Static selectors, labels in applications. – No maintenance overhead. – Simpler workflows. Directly include the value in the activity property (e.g., “Selector” for a UI element).
Rarely Changing Values (Multiple Use) Config File (JSON/INI) Log messages, log fields, paths, patterns. – Reusability across workflows. – Improved readability (meaningful keys). – Easier centralized updates. {"ReportID": "12361223", "LogMessageFormat": "{0} - {1}"}
Environment-Specific Values Orchestrator Assets Application paths, URLs, queue names, credentials. – Easy environment changes without code modification. – Centralized management in Orchestrator. Create assets with appropriate names (e.g., DEV_AppURL, Test_QueueName).
Runtime Settings (Unattended Robots) Orchestrator Assets/Queues Values needed during execution. – Centralized management. – Deployment flexibility across environments. Use assets for settings or queues for dynamic data.
Runtime Settings (Attended Robots) Input Dialogs User input during robot execution. – User interaction for dynamic data. Use “Input Dialog” activity to prompt users for values.
Robot-Specific Values Orchestrator Assets (Per-Robot Value) Settings that differ for each robot. – Flexibility for individual robot configurations. Set different values for the same asset name on different robots in Orchestrator.

Additional Considerations:

Choose a configuration file format (JSON, INI) based on project preference and complexity.

  • Consider using dedicated configuration libraries for complex projects.
  • Document your chosen approach and location of configuration files for team clarity.

By adhering to these best practices, you can establish a well-organized and adaptable configuration management system for your UiPath projects, leading to streamlined development, maintenance, and deployment processes.

UiPath Credential Security: A Summary for Attended and Unattended Robots

This guide highlights essential practices for securing credentials within UiPath projects, ensuring data protection and streamlined automation processes.

Robot Credentials (Unattended Robots):

  • Stored securely in Orchestrator robot definitions with 256-bit AES encryption.
  • Password retrieval not possible after initial setup.
  • Consider integration with CyberArk for enhanced security.

Robot Credentials (Unattended Robots):

  • Never store in plain text: Avoid storing credentials in workflows or config files.
  • Recommended Option: Orchestrator Credential Assets:

Secure storage in the SQL Server database (256-bit AES encryption).

Retrieved using “Get Credential” activity, returning username (String) and password (SecureString).

Supports per-robot values for flexibility.

  • Alternative: Windows Credential Store (Attended Robots Only):

Credentials stored locally on robots.

Requires manual creation on each robot for multi-robot deployments.

Less secure than Orchestrator assets, but suitable for attended robots where Orchestrator is not feasible.

  • Least Preferred Option: Get Password Activity (Avoid if possible):

Encrypts password within the XAML file (machine-specific).

Requires re-entering password and saving XAML for deployment.

Not recommended due to security limitations and deployment challenges.


  • Data type returned by “Get Credentials” activities for passwords.
  • Obfuscates password in memory, making retrieval difficult.
  • Released from memory upon variable scope end (unlike plain text strings).
  • Use “Type Secure Text” or “Send Keys Secure” activities for secure application logins.
  • Convert SecureString to String only if necessary (limited scope):
    • String UnsecurePassword = new System.Net.NetworkCredential("username", SecurePassword).Password

Additional Considerations:

Limit credential variable scope to the minimum required usage.

By adhering to these best practices, you can establish a robust and secure approach to credential management within your UiPath projects, safeguarding sensitive data and ensuring the smooth operation of your automations.

Important Note:

For attended robots where Orchestrator is not an option, using the Windows Credential Store with caution is an acceptable alternative. However, prioritize Orchestrator Credential Assets whenever possible for enhanced security.

Keep it clean

When you publish the code to production you need to make sure the code is updated, below are the things that need to be checked.


Workflow Annotation - UiPath
Workflow Annotation – UiPath

Add the annotation – Why this code was written 

Choosing an appropriate project name is paramount as it determines how the process will be identified within Orchestrator, aligning with internal naming conventions. While the project ID initially mirrors the project name, customization is possible via the project.json file. Equally significant is crafting a descriptive project description, visible in Orchestrator, aiding in easier differentiation between processes. Opting for a meaningful description enhances clarity and organization within your automation environment.

Workflow design

General design principles

This guide explores best practices for structuring UiPath workflows, ensuring clarity, maintainability, and efficient automation.

Breaking Down Workflows:

Layout diagrams


Within UiPath Studio, sequences serve as the fundamental building blocks for constructing automations. Their linear structure offers distinct advantages, but proper utilization is key to maximizing their effectiveness and fostering robust, maintainable workflows.

Addressing Complexity Challenges:

While sequences excel in simple scenarios, their linear nature can pose challenges for intricate automations. Lengthy sequences become unwieldy, hindering readability, maintainability, and the debugging process. To overcome this, a core best practice involves:

Atomic Workflows: Break down complex logic into smaller, reusable workflows. Each workflow should ideally encompass no more than 15-20 activities, representing a self-contained unit of functionality.

Single Responsibility Principle: Adhere to the Single Responsibility Principle by ensuring each workflow focuses on a specific task. For instance, a workflow might handle navigating to a particular web page, while another downloads a file from that page.

Descriptive Naming: Employ clear and concise names for both workflows and activities within them. This significantly enhances code comprehension and facilitates future modifications.

When selecting a layout for your UiPath workflow, prioritize clarity and maintainability. Sequences are well-suited for simple, linear automation tasks. However, for complex logic or decision-making scenarios, consider leveraging flowcharts or state machines to ensure your workflows remain organized, efficient, and easy to understand.

By following these professional design practices, you can leverage the strengths of sequences while effectively managing complexity within your UiPath workflows, paving the way for successful and sustainable automation solutions


UiPath Workflow Design: Flowcharts for Decision-Rich Processes

In UiPath Studio, flowcharts provide a powerful alternative to sequences for building workflows, particularly when dealing with complex decision-making logic. Here’s a breakdown of their strengths and how they align with the REFramework methodology.

Flowcharts: A Visual Advantage

Flexibility: Flowcharts offer greater flexibility in connecting activities compared to the linear structure of sequences. This allows for depicting workflows with multiple decision points, branching paths, and conditional execution.

Visual Appeal: The two-dimensional layout of flowcharts enhances readability by visually representing the various execution paths a workflow can take based on different conditions.

Decision-Making Scenarios: Flowcharts excel when an automation involves multiple decisions or relies on conditional logic to determine the next course of action. This makes them ideal for scenarios requiring complex validation, error handling, and conditional actions.


REFramework Integration:
The REFramework, a structured approach for building reusable and maintainable UiPath robots, leverages flowcharts effectively:

Process.xaml as Flowchart: When working with a process that necessitates multiple decisions, the REFramework recommends utilizing a flowchart within the Process.xaml file. This allows for the clear visualization and execution of conditional logic guiding the automation flow.

Sequences for Modularization: Within the REFramework, complex logic within the flowchart can be further broken down into smaller, reusable sequences. These sequences encapsulate specific tasks and are invoked from the main flowchart as needed. This promotes code modularity and simplifies maintenance.

TO-BE Diagram Alignment: For optimal readability, strive to design the flowchart within Process.xaml to resemble the decision-making structure depicted in the Process Definition Document’s (PDD) To-Be diagram. This creates a consistent visual representation of the automation’s intended behavior.

Best Practices for Effective Flowcharts:

Clear Conditions: Ensure the conditions used for branching within the flowchart are well-defined and easy to understand.
Descriptive Labels: Employ descriptive labels for decision points and connecting arrows to enhance code clarity.
Meaningful Naming: Assign clear and concise names to the invoked sequences and any variables used within the flowchart.

By capitalizing on the strengths of flowcharts and adhering to these best practices, you can create well-structured, maintainable workflows that effectively navigate complex decision-making scenarios within your UiPath automations. Remember, the REFramework provides a valuable framework for leveraging flowcharts in a structured and reusable manner.

State Machine

State machines offer a unique approach to structuring workflows within UiPath Studio, particularly suited for processes with well-defined states and transitions between them. Let’s delve into their capabilities and how they align with the REFramework.

State Machines: A Compact Approach to Logic

State Machines and REFramework:

While the REFramework primarily utilizes flowcharts within Process.xaml, state machines can be valuable in certain contexts:

Best Practices for Effective State Machines:

By understanding the strengths and limitations of each layout type, you can make informed decisions when designing your UiPath workflows, leading to more efficient, maintainable, and robust automation solutions.


If Activity

If Else Uipath Best Practices

Flow Decision

Flow - Best practices

If Operator

if Operators

Switch Activity

Flow Switch

Flow Swich Activities - Uipath best practices


Reusability - UiPath Best practices guide

Error Handling

Try Catch




Retry Scope



Custom Log fields



General rules

Init State

Get Transaction data state

Process Transaction Data State

End Process

UI Automation

How to choose the right approach

General UIA best practices

Input Methods

Timeouts and delays



Modern UIA best practices

UI Synchronization

Background Automation

Image Automation

Resolution Considerations

OCR Engines




Process Understanding

Automation Lifecycle

Process Understanding

Development and Code review

Development and Code review