Solution Design Document

Invoice Entry Project

Revision History
Rev. # Date Section/Page# Revision Summary Author
1 26/11/2024 All Created first version Meenakshi Bhatia

Contents
I. PURPOSE...............................................................................................................................................3
II. AUTOMATED PROCESS DETAILS.......................................................................................................3
Summary............................................................................................................................................. 3
III. RUNTIME GUIDE.................................................................................................................................4
1. Architectural structure of the Master Project......................................................................... 4
2. Master Project Runtime Details................................................................................................5
3. VendorDispatcher..................................................................................................................... 6
4. VendorPerformer...................................................................................................................... 6
5. Project(s) workflows................................................................................................................. 7
6. Packages.....................................................................................................................................7
7. Assets..........................................................................................................................................7
8. Exceptions..................................................................................................................................7
9. REPORTING................................................................................................................................ 8
10. Security..................................................................................................................................9
11. Compliance Considerations.................................................................................................9
IV. OTHER DETAILS............................................................................................................................... 10
V. GLOSSARY......................................................................................................................................... 10
I. PURPOSE
Outlines the major components of the Master Project (the overall output of the development,
containing one or multiple projects that together cover the scope of the robotic process automation)
taking into account all the business restrictions (scheduling, peaks, future increases in volume etc.).
The focus of the Solution Architect will be on:
 Robustness;
 Scalability;
 Efficiency;
 Replicability;
 Reusability of component
The information herein is targeted primarily at the developers that will initially implement the
solution and subsequently at the support developers in case of change requests.
The automation solution will utilize the RE framework with separate Dispatcher and Performer
model. The Dispatcher will be responsible for collecting all key data necessary to generate a
VendorOnboarding transaction item which will be committed to the appropriate Work Queue
within the UiPath Orchestrator. In turn, the Performer will work each transaction
sequentially, focusing on the work steps required to enter vendor details or notify the vendor
that they are already entered in the system..

II. AUTOMATED PROCESS DETAILS

Details filled in need to reflect the actual information for the Master Project released for production.
The following table will be populated:

Item Description
Master Project Name Invoice Entry Project
Robot Type Unattended
Orchestrator used? Yes
Scalable Yes
UiPath version used 2024.10

Summary
The process saves attachments from unread emails, extracts the information within and inputs the
data into 2 external applications – an ERP (System1) and a CRM (System3).
From a technical perspective, the process will be split into 2 subprocesses:
1. VendorDispatcher – reads the information in the attachments and performs a Bulk
Upload to add all data found to the Orchestrator Queue. One dispatcher job will run 20
times per day according to business requirements.
2. VendorPerformer – Retrieves one queue item from the Orchestrator Queue,
processes it in the ERP and CRM apps according to the rules described in the PDD.
III. RUNTIME GUIDE
1. Architectural structure of the Master Project
Display the interaction between components (package / robots, Orchestrator queues, and running
order) in a diagram.
 2. Master Project Runtime Details
Outlines the details of the automated process by filling in the table below.
ITEM NAME DESCRIPTION
Fill in each bolded section - empty fields are not
allowed. If the section does not apply to your
automation then mark as
n/a.
Production environment details ACME local machine
Prerequisites to run Dispatcher: Web browser (Chrome), Excel
Performer: Excel, ERP system
Input Data Dispatcher: Unread emails containing invoice
attachments
Performer: Queue items that contain the extracted
invoice data
Expected output Dispatcher: Email notifications to vendors confirming
invoice receipt, queued items for processing
Performer: Processed invoices posted to ERP system,
vendor notification emails, MIS reports
How to start the automated Dispatcher: Triggered by a scheduled time
process Performer: Triggered by the completion of Dispatcher
tasks in the queue (queue-based trigger)
Reporting Queues reporting via
(queues reporting, Kibana or Orchestrator
another platform)
How is Orchestrator used? Orchestrator is used for scheduling the automation,
managing robots, storing assets, and maintaining queues
for Dispatcher and Performer jobs.
Password policies n/a
(mention any specific compliance
requests)
Stored credentials Credentials stored in Orchestrator Assets, linked to the
(Never use hardcoded credentials current folder.
in the workflow!)

List of queues names Naming convention: ProcessName_QueueName

(Naming convention: Example: InvoiceEntry_Queue
Retries: 3 attempts per queue item,
ProcessName_QueueName)
Unique Reference: Tax ID or Invoice Number
Schedule Details daily
Multiple Resolutions Supported? n/a
(in case of image automation /
Citrix and VDI)
Recommended Resolution n/a
 3. Project(s) workflows
TO BE ADDED AFTER DEVELOPMENT

Workflow Name Description

Main.xaml The entry point workflow that
orchestrates the execution of all other
workflows.

4. Packages
Include the list of packages and high-level description for each of them, to explain their purpose
Package Name Description
UiPath.Excel.Activities
UiPath.System.Activities
UiPath.Testing.Activities
UiPath.UIAutomation.Activities
UiPath.PDF.Activities

5. Assets
TO BE ADDED AFTER DEVELOPMENT

Package Name Description

System1.Credentials Credentials used to login to System1

6. Exceptions
During the process run, certain scenarios might arise that the robot cannot process and will
require manual intervention. These are defined as exceptions. Below are the two types of
exceptions:

Business Exceptions – A business logic error or missing data which is encountered on a daily
basis by the business unit. There is a clear workaround that can be resolved by reviewing the
case.

Application Exceptions – This is defined as an unexpected error encountered by the robot such
as a network error or an application error which is outside the control of the business unit and
will need to be resolved by IT or the RPA team
 10. Testing
Testing is an essential part of any development process. Its main purpose is to ensure the
automated process is functioning in the way it is supposed to. By beginning the testing process
during development, any issues, bugs, and errors can be identified and potentially corrected at
the earliest possible opportunity.

Each level of testing is responsible for different parts of the automated solution, reassuring high
quality of each of the elements delivered. Each of the stages must be completed before the
solution is released to the production environment.

The stages of testing are:

Unit Testing - Focuses on the individual components and workflows created specifically for the
process in scope, assessing whether they function as according to the original design.

Responsibility: Development Team

System Integration Testing – Ensuring all required functionalities, both business and
technical, are implemented, as well as ensure unit testing has been completed successfully,
development Best Practices have been applied and code review has been completed by a
Solution Architect. There will usually be a round of fixes to be implemented before the
automation can proceed further.

Responsibility: Dedicated tester / Solution Architect

User Acceptance Testing – Process team take responsibility of this phase of testing to ensure
they are happy with the results of the automated business process. Sign-off of this phase is
business led and mandatory in order to proceed further. Generally, there will be iterative fixes
to be implemented that have been discovered during the user testing of the automation.

Responsibility: Dedicated tester C Business Unit

Pre-Production Testing – Validates the readiness of the product prior to Production
deployment.

Responsibility: Dedicated tester, Development Team C Solution Architect

Dry-Run –Monitor the initial cases run by the process to account for any environmental
differences between Pre-Production and Production.

Responsibility: RPA Business Analyst C Business Unit

11. Security
Security is a vital aspect of digital processes as it provides an extra layer of protection from the
public. There are different ways in which security is implemented when automating an existing
process, some of which are discussed in this section.
Sensitive data such as passwords and client/customer information (like information stored in
databases) must never be unnecessarily stored outside of its origin application when handled
by the RPA solution.

Similarly, user and application credentials used by the RPA solution must also never be
unnecessarily stored or shared with any unauthorized persons. In addition to that, if the robot is
dealing with password reset policies that are internal to the client, those policies must be
followed to ensure security is maintained.

API keys are often used within RPA solutions to allow access to certain applications, and these
are ideally stored in Orchestrator credential assets and only accessed when needed. As with
credentials, they should never be shared or stored elsewhere.

12. Compliance Considerations

Display the interaction between components (package / robots, Orchestrator queues, and running
order) in a diagram.
Item Specific Considerations (use N/A if not applicable)
Sarbanes Oxley (SOX) n/a
HIPAA Orchestrator approved for storing confidential information
(in queue items).
Do not store PII or PHI to Logs.
FERC Standards of Conduct n/a
Personally Identifiable Information Orchestrator approved for storing confidential information
(ensure process follows PoLP) (in queue items).
Do not store PII or PHI to Logs.
Others
IV. OTHER DETAILS
Future Improvements
Fill in any improvements that need to be considered for the future:

Other Remarks
Please mention here any other points that you consider relevant for the automation process.

V. GLOSSARY
The main terms used in the Solution Architecture Document are defined below:
Master project - the overall output of the development, containing one or multiple projects that
together cover the scope of the robotic process automation. There is a 1 to 1 connection between
the Master Project and the Process to be automated (As presented in the PDD).
Project - an UiPath Studio project containing one or multiple workflow files. A project can be
converted to a package and run independently, covering a particular scope within the master
project. Or multiple projects can be converted into one package depending on the aims and
restrictions of the automation. The project is used when defining the development and support
phase of the automation.
Package - the output of compiling one or multiple projects. A package can be deployed on the robot
machine and be executed by the robot service. Only one package can be executed at a given time by
a robot. The package is used when defining the running phase of the automation.
Workflow - a component of the package, the workflow encapsulates a part of the project logic. The
workflow can be of type: sequence, flowchart or state machine. A workflow is saved as an .xaml file
inside the project folder. A workflow file can be invoked from another workflow and by default there
is an initial workflow file that will run when executing the package.
Activity - an action that the robot executes.
Sequence - a workflow where activities are executed one after another, in a sequential order
Flowchart - a workflow where activities are connected by arrows and the logic of the workflow can
be easily followed in a visual manner. The flowchart can also be exported as an image from UiPath
studio.
State machine - a more advanced way of organizing a workflow, similar to a flowchart.
BOR - Back office robot
FOR – Front office robot
Orchestrator – Enterprise architecture server platform supporting: release management,
centralized logging, reporting, auditing and monitoring tools, remote control, centralized scheduling,
queue/robot workload management, assets management.