# Automation Lifecycle

> Automation lifecycle in Studio, covering decisions between attended and unattended robots, exception handling, and development best practices.

## Process Understanding

Deciding between an automation for Attended Robots or Unattended Robots is the first important decision that impacts how developers build the code, as the general running framework (Robot triggering, interaction, exception handling) is different. Switching to the other type of Robots later may be cumbersome.

### When Attended Robots Make Sense

For time-critical, live, humanly triggered processes, like in a call center an Attended Robot working side by side with a human might be the only possible answer.

### Reconsidering Attended Robots

Not all processes requiring human input must use Attended Robots. If a judgmental decision is unavoidable, consider splitting the process into smaller sub-processes that can run unattended.

For example, one sub-process could collect data, and after human validation, a second sub-process continues automatically.

A typical case would be a process that requires a manual step somewhere during the process, such as checking the unstructured comments section of a ticket and, based on that, assign the ticket to certain categories.

### Benefits and Practical Considerations

Generally speaking, going with an Unattended Robot ensures a more efficient usage of the Robot load and a higher ROI, a better management and tracking of robotic capacities.

However, several factors affect this decision:

* Attended Robots typically run only during working hours
* Attended Robots keep machines and users busy until execution completes
* Input types and transaction volumes
* Time restrictions and scheduling
* Number of available Robots

## Documenting the Process - DSD

The process documentation guides the developer's work and provides help in tracking the requests and the application maintenance. Of course, there might be lots of other technical documents, but one is critical for a smooth implementation, namely **DSD** (Development Specification Document).

The Development Specification Document should contain the automated process details and focus on two main categories: **Runtime Guide** and **Development Details**.

### Runtime Guide

The **Runtime Guide** should contain a high-level runtime diagram and details about Robot functionality, including sub-processes, schedules, configuration settings, and file management.

Include details on prerequisites, error handling, process resumption, Orchestrator usage, logging, reporting, and credential management.

### Development Details

The **Development Details** should include packages, development environment, logging levels, source control information, and workflow components with descriptions.

Also include reusable components, invoke trees, custom logs, flowchart snapshots, automation levels, and other development details.

## Development and Code Review

The RPA Solution Architect is responsible for continuously coaching developers on the best practices. Hence, frequent and thorough code reviews are a must, to enforce a very high quality of the developed workflows. This way, the developers are motivated to build robust workflows and to follow the best practices guide.

## Test

After each component is built, conduct unit testing. Thorough component testing ensures smoother integration and faster debugging.

Use the **REFramework**’s **Test_Framework** folder for test files. The `RunAllTests.xaml` file enables automated testing of multiple `.xaml` files. Run tests outside office hours in testing environments to optimize developer time.

### Test environments

The recommended UiPath architecture includes **Dev** and **Test** environments that allow the processes to be tested outside the live production systems.

Sometimes applications look or behave differently between the **Dev**, **Test**, or **Production** environments and extra measures must be taken, sanitizing selectors or even conditional execution of some activities.

### Test mode

Use the `UiPath.config` file or Orchestrator assets to switch environment-specific flags. Define a test mode Boolean parameter to control behavior during debugging.

When **True**, the automation follows test routes and doesn’t execute fully. For example, skip notifications and use **Cancel** instead of **Save**. When **False**, follow normal production routes.

This allows you to make modifications and test them in processes that work directly in live systems.

## Release

There are various ways of designing the architecture and release flow, considering the infrastructure setup, concerns about the segregation of roles, etc.

In this proposed model UiPath developers can build their projects and test them on **Development** environments in Orchestrator. They are allowed to check in the project to a drive managed by a version control system (VCS), such as GIT, SVN, or TFS.

Publishing the package and making it available for **Test** and **Production** environments is the work of a different team, such as IT.

### Deployment model

The deployment paths on Orchestrator have been changed from their default to folders managed by the **VCS**, by changing the **Storage.Location** value in the `UiPath.Orchestrator.dll.config` file in the **Deployment** section..

The model also contains a repository of reusable components.

![Release architecture diagram showing Dev, Test, and Production Orchestrator environments with VCS-managed deployment paths](https://dev-assets.cms.uipath.com/assets/images/studio/studio-docs-image-168841-b56b2a41.webp)

Here is the project publishing flow, step by step:

1. Developers build the process, test & debug pieces of it locally (Studio).
2. Once the automation development is completed, the process is published to the **Development** Orchestrator and tested again end-to-end.
3. The project folder is committed (not packaged) to a **Master Library** folder (on **VCS**).
4. The IT/ RPA Operations team creates the project package for QA. This step is intended to be an additional safety measure: the automation source code is inspected (by a different entity) before being packaged and run by robots.For example, the packaged process is stored in the **Process Pckgs (QA)** folder on **VCS**, from which it is deployed to the QA robots and executed.
5. If any issue is revealed during the tests, the steps above are repeated.
6. Once all QA tests are passed, the package is pushed to a **Production** environment - **Process Pckgs (Prod)**.
7. When the Process goes live, the process package is deployed to the production Robots and executed.

**Reusable Content** is created and deployed separately, as UiPath code (**Reusable Code Library**) and **Invokes** (**Invokes Repository**).

Workflows with source code are `.xaml` files containing activities for automating common processes, such as *Log in to SAP*:

   ![Reusable Code Library workflow showing a Log in to SAP xaml file with activities](https://dev-assets.cms.uipath.com/assets/images/studio/studio-docs-image-171380-a90efa22.webp)

**Invokes** represent workflows composed only of one **Invoke** activity of the code workflows mentioned above.

   ![Invoke workflow containing a single Invoke activity referencing a reusable code workflow](https://dev-assets.cms.uipath.com/assets/images/studio/studio-docs-image-168221-5256fc59.webp)

The Snippet panel of a Studio developer should point to this **Invoke** repository in order to provide easy access (drag & drop) to **Reusable Content**.

   ![Studio Snippets panel pointing to the Invokes repository for drag-and-drop reusable content access](https://dev-assets.cms.uipath.com/assets/images/studio/studio-docs-image-168497-70775819.webp)

The local design authority in charge with maintaining the **Reusable Content** updates (due to a change in process, for instance) the workflows with code. The **Invokes** remain unchanged.

The advantage of this approach (as opposed to working directly with the library of source code) is that when a change is done to a reusable component, all the running projects reflect this change as well, as they only contain an **Invoke** of the changed workflow.

## Monitoring

Use **Log Message** activities to trace process execution for supervision, diagnosis, and debugging. Messages should include transaction IDs and state information for accurate identification.

Logging should be used:

* At the beginning and the end of every workflow;
* When data is coming in from external sources;
* Each time an exception is caught at the highest level.

Messages are sent with the specified priority (e.g. **Info, Trace, Warning**) to Orchestrator and are also saved in the local `.nlog` file.

### Custom Log Fields

To make data easily available in Kibana for reporting purposes, the Robot may tag log messages with extra values using the **Add Log Fields** activity. By default, any UiPath log output has several fields already, including `message`, `timestamp`, `level`, `processName`, `fileName`, and the Robot’s Windows Identity. Log Fields are persistent so if we do not need to mark all messages with a tag, fields should be removed immediately after logging, using the **Remove Log Fields** activity. **Do not use a field name that already exists.** It’s important to specify the proper type of argument the first time when you add the field. This is how Elasticsearch indexes it.

  ![Workflow using Add Log Fields and Remove Log Fields activities to tag and clean log messages](https://dev-assets.cms.uipath.com/assets/images/studio/studio-docs-image-171569-78160643.webp)