Uipath Code Review Checklist Template

UiPath Code Review Checklist Template

---

1. Document Control & Revision History

---

2. Executive Summary & Scope

This Standard Operating Procedure (SOP) establishes a rigorous framework for conducting code reviews of UiPath Robotic Process Automation (RPA) solutions. The primary objective is to systematically identify, document, and remediate technical and logical deficiencies, thereby ensuring the delivered automations consistently meet organizational standards for quality, maintainability, performance, security, and resilience.

Operational Boundaries: This SOP applies to all UiPath Studio projects, including attended and unattended automations, reusable components (libraries), and custom activities, prior to their deployment into User Acceptance Testing (UAT) or production environments. It encompasses both initial code submissions and subsequent modifications, ensuring a standardized validation gateway for all RPA solution increments.

Regulatory Standards: Adherence to this SOP facilitates compliance with internal coding guidelines, secure coding principles, data privacy regulations (e.g., GDPR, CCPA where applicable), and industry best practices for RPA development and governance.

---

3. Prerequisites & Tool Requirements

3.1. Personnel Qualifications & Certifications:

• Reviewer: UiPath Certified Advanced RPA Developer (UiARD) or equivalent demonstrated expertise in UiPath development, architecture, and best practices. Completion of internal Code Reviewer Training module.
• Developer: UiPath Certified RPA Developer Associate (UiRPA) or equivalent demonstrated proficiency in UiPath development.

3.2. Software & System Access:

• Development Workstation: Configured with UiPath Studio (minimum required version as per project standards), sufficient CPU, RAM, and storage.
• Version Control System (VCS): Access to the project's designated VCS (e.g., Git, Azure DevOps Repos, SVN) with appropriate permissions for pull request creation, review, and merging.
• Code Review Platform: Integrated VCS features (e.g., GitHub Pull Requests, Azure DevOps Pull Requests) or a dedicated code review tool (e.g., SonarQube integrated with UiPath projects) for comment management and status tracking.
• UiPath Orchestrator: Read-only access to relevant folders for understanding project context, existing assets, queues, and credentials if applicable.
• Documentation Repository: Access to organizational coding standards, architectural guidelines, and project-specific documentation.

3.3. Equipment:

• Standard enterprise workstation with reliable network connectivity.

3.4. Safety PPE:

• Not Applicable (N/A) for this procedural context.

---

4. Roles & Responsibilities (RACI Matrix Table)

RACI Designations:

• R (Responsible): The individual(s) who perform the task.
• A (Accountable): The individual ultimately answerable for the correct and thorough completion of the deliverable or task. Only one "A" per activity.
• C (Consulted): Individuals whose opinions are sought; they provide input and insights.
• I (Informed): Individuals who are kept up-to-date on progress or decisions; they are recipients of communication.

---

5. Step-by-Step Operational Procedure

This procedure outlines the structured process for conducting a UiPath code review.

Phase 1: Developer Preparation and Submission

• 1.1. Complete Development: Ensure all functional requirements for the current development increment are met and the code is stable.
• 1.2. Perform Local Testing: Execute comprehensive unit testing and integration testing within UiPath Studio to validate functionality and identify immediate issues.
• 1.3. Conduct Developer Self-Review:
  • Review adherence to project-specific naming conventions for variables, arguments, workflows, and activities.
  • Verify proper use of annotations and comments for clarity.
  • Confirm error handling mechanisms (Try-Catch blocks) are implemented where exceptions are anticipated.
  • Validate credential management and sensitive data handling align with security policies.
  • Ensure all necessary project dependencies are correctly configured.
  • Remove all temporary or commented-out code segments.
• 1.4. Update Documentation: Ensure relevant documentation (e.g., Process Design Document, Solution Design Document, Technical Specification) is updated to reflect changes.
• 1.5. Commit to VCS: Commit the completed and self-reviewed code to the designated version control branch.
• 1.6. Create Pull Request (PR): Initiate a pull request or code review request within the VCS, clearly specifying the scope of changes, associated user stories/tasks, and assigning the designated reviewer(s).

Phase 2: Reviewer Execution and Evaluation

• 2.1. Understand Review Scope:
  • Review the PR description, linked work items, and developer comments to understand the objective and context of the changes.
  • Access the relevant VCS branch to view the committed code.
• 2.2. General Project Structure & Standards:
  • Folder Structure: Verify logical organization of workflows (e.g., Framework, Process, Data, Tests).
  • Naming Conventions:
    • Activities: VerbNoun (e.g., ReadConfig, LoginSAP).
    • Variables: camelCase (e.g., configData, transactionItem).
    • Arguments: in_, out_, io_ prefixes (e.g., in_Config, out_Result).
    • Workflows (.xaml): PascalCase (e.g., InitAllApplications.xaml, ProcessTransaction.xaml).
    • Assets: Consistent naming and appropriate scope in Orchestrator.
  • Solution Description: Check if Main.xaml and other primary workflows have clear descriptions.
• 2.3. Workflow Design & Logic:
  • Activity Usage:
    • Avoid deprecated activities.
    • Use modern activities where appropriate (e.g., Use Application/Browser over Open Application/Browser).
    • Ensure activity properties are configured correctly and optimally (e.g., TimeoutMS, ContinueOnError).
  • Flow Control:
    • Appropriate use of Sequence, Flowchart, State Machine.
    • Avoid excessive nesting of sequences.
    • Verify conditional logic (If/Else, Switch) is clear, concise, and covers all relevant scenarios.
  • Variable & Argument Management:
    • Minimize variable scope to the activity or workflow where they are used.
    • Avoid global variables unless absolutely necessary and justified.
    • Correct direction (In/Out/InOut) for arguments.
    • Data types are appropriate for the data being handled.
    • Unused variables/arguments are removed.
  • Reusability:
    • Identify opportunities for refactoring repetitive logic into reusable workflows or library components.
    • Verify existing reusable components are leveraged appropriately.
• 2.4. Error Handling & Resilience:
  • Try-Catch Blocks:
    • Correctly implemented around critical operations that may fail.
    • Specific exception types are caught where appropriate (e.g., SelectorNotFoundException, BusinessRuleException).
    • Robust actions within Catch blocks (e.g., logging, retries, graceful exits).
  • Global Exception Handler: Confirm adherence to organizational G.E.H. standards, if applicable.
  • Retry Mechanisms: Verify appropriate retry logic (e.g., Retry Scope activity) for transient errors.
  • Fatal vs. Business Exceptions: Clear distinction and handling.
• 2.5. Performance Optimization:
  • Delays: Avoid unnecessary Delay activities; use explicit waits or orchestrator schedules instead.
  • Data Loading: Optimize data retrieval (e.g., retrieve data in batches, filter at source).
  • UI Interactions: Minimize redundant UI interactions. Ensure selectors are robust and optimized.
  • Resource Management: Ensure files, database connections, and applications are properly closed.
• 2.6. Security & Compliance:
  • Credential Management:
    • No hardcoded credentials. All credentials retrieved from Orchestrator Assets or secure credential stores.
    • Secure String data type used for sensitive data.
  • Sensitive Data Handling:
    • Data masked or encrypted where required in logs.
    • Data purged from memory after use if no longer needed.
    • No PII or sensitive data written to unprotected logs or temporary files.
  • Input Validation: Ensure all inputs, especially from external systems or users, are validated to prevent injection or unexpected behavior.
• 2.7. Maintainability & Readability:
  • Annotations & Comments:
    • Critical decision points and complex logic are explained.
    • Business logic or technical explanations where code alone is insufficient.
    • Outdated comments are removed.
  • Modularity: Workflows broken down into logical, manageable units.
  • Logging:
    • Meaningful Log Message activities at key steps (e.g., start/end of major transactions, error points).
    • Appropriate log levels (Trace, Debug, Info, Warn, Error, Fatal).
    • No sensitive data in logs.
• 2.8. Testability:
  • Clear inputs and outputs for workflows to facilitate unit testing.
  • Separation of configuration from business logic.

Phase 3: Feedback and Remediation

• 3.1. Provide Constructive Feedback:
  • Document all identified issues clearly within the code review platform (VCS PR comments).
  • Categorize issues by severity (e.g., Critical, Major, Minor, Suggestion).
  • Provide specific examples and suggest corrective actions or best practices.
• 3.2. Developer Remediation:
  • Developer reviews all feedback and implements necessary changes.
  • Developer commits revised code to the feature branch.
  • Developer addresses each comment in the review platform, indicating action taken.
• 3.3. Iterative Review: Reviewer re-evaluates the updated code to ensure all feedback has been adequately addressed. Repeat Phase 2 and 3 as necessary until all critical and major issues are resolved.

Phase 4: Approval and Merge

• 4.1. Final Approval: Once all review comments are addressed and the code meets quality standards, the reviewer grants final approval on the pull request.
• 4.2. Merge to Target Branch: The approved code is merged into the designated target branch (e.g., develop, main).
• 4.3. Communicate Completion: Inform relevant stakeholders of the successful code review and merge.

---

6. Quality Assurance & Verification Criteria

This section defines the benchmarks and audit points for ensuring the effectiveness of the code review process.

6.1. Code Review Audit Checklist:

• Has every pull request undergone a formal code review by an approved reviewer?
• Are all critical and major issues identified during the review logged and demonstrably resolved?
• Is there evidence of adherence to the step-by-step operational procedure for each review?
• Are code review comments constructive, specific, and actionable?
• Is the average time from PR creation to merge within established SLAs?

6.2. Tolerance Thresholds:

• Critical Defects: Zero (0) critical defects per code review. Critical defects include security vulnerabilities, data integrity issues, significant performance degradation, or fundamental logical errors leading to incorrect outcomes.
• Major Defects: Maximum three (3) major defects per code review. Major defects include significant deviations from coding standards, poor error handling in critical paths, or design flaws impacting maintainability.
• Minor Defects/Suggestions: Maximum ten (10) minor defects/suggestions per code review. Minor defects include cosmetic issues, minor logging omissions, or slight deviations from optimal activity usage.
• Coverage: Minimum 85% adherence to organizational coding standards as assessed by automated static code analysis tools (if integrated) and manual review.

6.3. Acceptance Benchmarks:

• Approval Status: The pull request status is "Approved" by the designated Senior RPA Developer (Accountable role).
• Issue Resolution: All "Critical" and "Major" findings from the review have been remediated and re-verified by the reviewer.
• Test Case Execution: Associated unit and integration test cases (if applicable) pass successfully post-review and merge.
• Documentation Alignment: Code changes are reflected accurately in accompanying technical documentation.
• Performance Baseline: No measurable degradation in performance metrics compared to previous versions or established baselines.

---

7. Practical Troubleshooting Scenarios

7.1. Scenario 1: Persistent Quality Issues from a Developer

• Failure Scenario: A particular RPA Developer consistently submits code that exhibits recurring critical or major defects, indicating a lack of understanding of best practices or organizational standards, despite previous review feedback.
• Immediate Corrective Action Protocol:
  1. Direct Feedback & Coaching: The Senior RPA Developer (Reviewer) schedules a direct, one-on-one session with the developer to discuss specific patterns of issues, provide targeted coaching, and reiterate expectations.
  2. Mandatory Retraining: Assign the developer to re-complete relevant UiPath Academy modules (e.g., Advanced RPA Developer, Best Practices for Production Ready Bots) and any internal code standard training.
  3. Pair Programming/Mentorship: Implement a temporary measure where the developer is paired with a highly experienced Senior RPA Developer for their next 2-3 development cycles, focusing on real-time best practice application.
  4. Pre-Review Checkpoint: For subsequent submissions, introduce an informal pre-review by a peer or mentor before the formal pull request to catch obvious issues early.
  5. Performance Improvement Plan: If issues persist, escalate to the Project Manager and Team Lead to initiate a formal performance improvement plan.

7.2. Scenario 2: Code Review Bottleneck

• Failure Scenario: The volume of code review requests exceeds the capacity of available reviewers, leading to significant delays in PR approval, impacting project timelines and release cycles.
• Immediate Corrective Action Protocol:
  1. Prioritization Matrix: Implement a review prioritization matrix based on project criticality, risk, and pending deployment deadlines. Communicate review SLAs based on this prioritization.
  2. Temporary Reviewer Assignment: Identify and onboard additional qualified Senior RPA Developers or Solution Architects to serve as temporary reviewers, distributing the workload. This may require expedited training on the specific project's context.
  3. Dedicated Review Time: Institute dedicated blocks of time for all reviewers to focus solely on code reviews, minimizing context switching.
  4. Automated Static Analysis: Explore or enhance the integration of static code analysis tools (e.g., UiPath's Workflow Analyzer, SonarQube) into the CI/CD pipeline. This offloads detection of common, easily identifiable issues, allowing human reviewers to focus on complex logical and architectural concerns.
  5. Reviewer Training Optimization: Provide training to existing reviewers on efficient review techniques, focusing on high-impact areas rather than exhaustive line-by-line checks for every minor detail.

7.3. Scenario 3: Disagreement on Best Practice Implementation

• Failure Scenario: During a code review, the RPA Developer and Senior RPA Developer (Reviewer) hold differing, but seemingly valid, opinions on the optimal implementation of a particular logic or architectural pattern, leading to an impasse.
• Immediate Corrective Action Protocol:
  1. Consult Established Standards: Reference official organizational coding standards, architectural guidelines, or UiPath official documentation for clarification. If a standard exists, it takes precedence.
  2. Escalation to Solution Architect: If standards are ambiguous or non-existent for the specific scenario, escalate the discussion to the Solution Architect or Lead Developer for arbitration and a definitive decision.
  3. Document Decision & Rationale: Once a decision is made, document the agreed-upon approach and its rationale. This serves as a future reference and potentially as an update to organizational standards.
  4. Evaluate Impact: Assess the short-term and long-term impact of each proposed solution (e.g., performance, maintainability, scalability, cost) to inform the decision-making process.
  5. Standardization Initiative: If such disagreements are frequent, it indicates a gap in organizational standards. Initiate a working group to formalize guidelines for the contentious areas.