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.
Variables
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:
- Â
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 |
Arguments
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. |
Note:
- 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.
Activities
- 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.xaml,ÂProcessTransaction.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.xaml,ÂSAP_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Â
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Â
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
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 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
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.
SecureString
- 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.
Â
Add the annotation – Why this code was writtenÂ
- Close the app after automation
- Clear the commented code
- Remove the default variable
- Removed unwanted Variables or arguments
- Remove the unwanted workflow
- Check the naming pattern of the workflows, activities, variables, arguments
- Delete temporary Write Line outputs
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:
- Modular Design: Break down complex processes into smaller, reusable workflows. This promotes code organization and simplifies maintenance.
- Logical Grouping: Group activities with a common purpose into separate workflows. This enhances readability and reusability.
- Focus on Functionality: Each workflow should have a clear and well-defined function. Avoid creating workflows that are too large or encompass unrelated tasks.
- Consider Reusability: Design workflows with potential reuse in mind. This can save development time and effort in future projects.
Layout diagrams
Sequence
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.
- Intuitive Design: Sequences present a straightforward, top-down execution flow, making them ideal for beginners to grasp and build basic automations.
- Linear Execution: Activities execute sequentially, perfectly suited for scenarios where one task follows another in a predetermined order. This is particularly advantageous in user interface (UI) automation, where sequences can efficiently chain together actions like "Type Into" and "Click" activities.
- Simplicity for Common Tasks: Due to their ease of use, sequences are often the preferred layout for many workflows, especially when dealing with UI interactions or basic data manipulation tasks.
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
Flowchart
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
- Finite States: State machines excel at modeling processes with a finite set of distinct states (e.g., "Start," "Processing," "Completed," "Error"). Each state represents a specific stage in the automation process.
- Transitions: Conditional arrows, known as transitions, connect states and define the trigger for moving from one state to another. These transitions usually depend on specific conditions or events.
- Compact Representation: Compared to flowcharts, state machines can provide a more concise representation of complex logic, especially for processes with repetitive structures or predictable state changes. They are well-suited for high-level process diagrams of transactional business processes.
State Machines and REFramework:
While the REFramework primarily utilizes flowcharts within Process.xaml, state machines can be valuable in certain contexts:
- Template Starting Point: Consider a state machine as a foundational template, particularly for processes with clear states and transitions. This can provide a good starting point for designing the overall automation logic.
- Avoid Overuse: State machines are not a one-size-fits-all solution. While they offer a compact representation, overly complex state machines can become difficult to understand and maintain. Use them judiciously when they align well with the process structure.
Best Practices for Effective State Machines:
- Clear State Definitions:Ensure each state within the state machine has a well-defined purpose and represents a distinct stage in the process.
- Meaningful Transitions: Define clear and concise conditions for transitions between states. Use descriptive labels to explain the trigger for each transition.
- Error Handling: Implement robust error handling mechanisms within the state machine to gracefully manage unexpected situations and ensure the automation remains stable.
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.
Decisions
If Activity
Flow Decision
If Operator
Switch Activity
Flow Switch
Reusability
Error Handling
Try Catch
Throw
Rethrow
Retry Scope
Logging
Custom Log fields
