Naming conventions

Meaningful names should be assigned to workflow files, activities, arguments, and variables in order to accurately describe their usage throughout the project.

Firstly, projects should have meaningful descriptions, as they are also displayed in the Orchestrator user interface. Moreover, adopting a good naming strategy for environments, assets, and queues makes the management of the virtual workforce in Orchestrator more manageable.

Only argument names are case sensitive, but to improve readability, variables and the other entities should also align to the same naming convention.

• Variables should be upper Camel Case, e.g. FirstName, LastName.
• Arguments should be in upper Camel Case with a prefix stating the argument type, e.g. in_DefaultTimeout, in_FileName, out_TextResult, io_RetryNumber.
• Activity names should concisely reflect the action taken, e.g. Click ‘Save’ Button. Keep the part of the title that describes the action (Click, Type Into, Element exists, etc).

Except for Main, all workflow names should contain the verb describing what the workflow does, e.g. GetTransactionData, ProcessTransation, TakeScreenshot

Variables

1. Use one variable for one and only one purpose.
2. Minimize the scope of each variable.
3. Keep statements that work with the same variable(s) as close together as possible.
4. Variables will always have meaningful names. The variable name should fully and accurately describe the entity the variable represents. State in words what the variable represents.
5. We will use the upper Camel Case (Pascal case) for naming variables. This practice used compound words, no other characters between the words, where each word will start with a capital letter. Ex: TransactionNumber, FilePath, ReportName, etc.
6. The length of the variable name should be between 6 and 20 characters long. If you feel that 20 characters are not enough, consider abbreviating longer words. Shorter variables names can be used when using a local scope (like index, file, row).
7. Datatable object: Start with dt_ prefix followed by the normal name. Ex: dt_Employees, dt_Reports.
8. Boolean type: Give Boolean variables names that imply True or False. You can use the prefix is followed by the name. Ex. ApplicationExists, isRed, isFound, etc. Always use positive names, negatives names (Ex: notFound) should be avoided if possible.

Arguments

Same guidelines as for variables, with the below differences:

1. Each argument will have a prefix depending on the direction: in, out, io followed by the underscore character (“_”). Example: in_Config, out_InvoiceNumber, io_RetryNumber, in_dt_Employees.
2. Use default values for arguments either for testing individual workflow files, or, in case of reusable components, for using default configuration. When invoking a workflow file, UiPath allows the flexibility to pass a value to any of the defined arguments, having essentially all possible signatures defined by the argument list. This allows for using the default value of an argument for which no value is passed upon invoking the file. Specify what is the default configuration in the description of the reusable workflow file.

Activities

Activity names should concisely reflect the action taken, e.g. Click ‘Save’ Button. Keep the part of the title that describe the action (Click, Type Into, Element exists etc). In case an activity throws an exception the source of the exception will contain the activity name, so a proper name to each activity is advisable for an easy understanding of the exception. Take extra care in renaming activities that have a standard name, like Assign, If, For each or Sequence for which the name doesn’t automatically change – one would need to manually rename them.

Workflow files

1. Upper Camel Case naming.
2. A workflow file starts with the prefix containing Application Name. E.g. for working in SAP: SAP_Login.xaml, or SAP_ExtractClientReport. Typically, workflow files belonging to the same application or system will be grouped together in one folder under the project root folder. In case there are many files for one application, further categorizing by using subfolders can be used.
3. When using a template framework – the framework files come already created and are standard (including Main.xaml) – they should not be changed.
4. When using a test framework – for the Test_Framework files – Use the prefix Test_ for a workflow file that runs tests. Place these files in the Test_Framework folder.
5. For an easier understanding, use number prefixes to emphasize the calling (invoking) hierarchy of the Project, where the root is always Process (in REFrameWork) if the hierarchy grows too large.

Projects and Sub-projects

1. Upper Camel Case naming
2. Group by department using a prefix: E.g. AP_, AR_.
3. In case the process is automated using sub-processes (using multiple packages for the same business process, like using Dispatcher and Performer), use the business process code as the next prefix.

Orchestrator

A good and consistent naming strategy must be used when defining the Orchestrator entities.

Robots

1. Development machines: DEV_[Name of developer in upper Camel Case] E.g. DEV_DanielDines .
2. Test machines: TEST_[Machine Name][Robot Number].
3. Prod machines: [Machine Name][Robot Number]

Environments

An environment links together multiple robots that are running the same process. Hence, the naming will include a combination from robots and projects:

1. Use prefix DEV_ or TEST_ or PROD_.
2. Group by department using a prefix: E.g. AP_, AR_.
3. In case of sub-processes, use the business process code as the next prefix

Assets

1. For normal assets: [Department][Project code][Asset Name] E.g. AR_CA_MappingTableURL.
2. For credentials: C_[expiration period][Department][Project code]_[Asset Name] E.g. C_180_AP_SC_SapCredentials.

Queues

[Department][Project code][Queue Name] E.g. AR_CA_ExcelItems