Blueprint Before Bots: Mastering PDD and SDD Documentation for Enterprise RPA
RPA UiPath PDD SDD Documentation Enterprise Automation
“Just build it, we’ll figure out the details later.”
Famous last words before a failed RPA project.
The difference between a successful automation and a maintenance nightmare often comes down to what happens before the first line of code is written. That’s where PDD and SDD come in.
The Cost of Skipping Documentation
Let’s start with reality:
| Scenario | Without PDD/SDD | With PDD/SDD |
|---|---|---|
| Requirement changes mid-project | Complete rework, “that’s not what I meant” | Reference the signed-off document |
| Developer leaves the team | Months of reverse-engineering | New developer reads the SDD |
| Bug in production | ”What was this supposed to do?” | Check the business rules in PDD |
| Scaling to new regions | Start from scratch | Adapt existing templates |
| Audit/compliance review | Panic and scramble | Hand over documentation |
The Math:
- Time to write PDD: 4-8 hours
- Time to write SDD: 8-16 hours
- Time wasted on one major misunderstanding: 40+ hours
Documentation isn’t overhead. It’s insurance.
Where PDD & SDD Fit in the RPA Lifecycle
┌──────────────────────────────────────────────────────────────────────────┐
│ RPA Project Lifecycle & Documentation │
├──────────────────────────────────────────────────────────────────────────┤
│ │
│ DISCOVERY DESIGN BUILD TEST DEPLOY OPS │
│ ──────── ────── ───── ──── ────── ─── │
│ │
│ Process Solution Coding UAT Go-Live Support │
│ Analysis Design & Unit & & & Main- │
│ Testing Sign-off Hypercare tenance │
│ │
│ │ │ │ │ │ │ │
│ ▼ ▼ │ │ │ │ │
│ ┌──────┐ ┌──────┐ │ │ │ │ │
│ │ PDD │ │ SDD │ │ │ │ │ │
│ └──────┘ └──────┘ │ │ │ │ │
│ │ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ ▼ │
│ ●……………● ●……………● ●……………● ●……………● ●……………● ● │
│ GATE 1 GATE 2 GATE 3 GATE 4 GATE 5 │
│ Business Tech Code UAT Prod │
│ Sign-off Sign-off Review Sign-off Release │
│ ●……………● ●……………● ●……………● ●……………● ●……………● ● │
│ │
│ ➜ Key Milestones: │
│ • PDD Sign-off before development starts (Gate 1) │
│ • SDD Sign-off before coding starts (Gate 2) │
│ • No scope changes after Gate 2 without Change Request │
│ │
└──────────────────────────────────────────────────────────────────────────┘PDD vs SDD: What’s the Difference?
┌─────────────────────────────────────────────────────────────────────────────┐
│ PDD vs SDD Overview │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────┐ ┌──────────────────────────┐ │
│ │ PDD │ │ SDD │ │
│ │ Process Definition │ │ Solution Design │ │
│ │ Document │ │ Document │ │
│ ├──────────────────────────┤ ├──────────────────────────┤ │
│ │ │ │ │ │
│ │ WHAT the process does │ │ HOW automation will work │ │
│ │ │ │ │ │
│ │ Written by: BA / SME │ │ Written by: RPA Dev │ │
│ │ │ │ │ │
│ │ Audience: Business │ │ Audience: Technical │ │
│ │ │ │ │ │
│ │ When: Discovery Phase │ │ When: Design Phase │ │
│ │ │ │ │ │
│ │ Approval: Business Owner │ │ Approval: Tech Lead │ │
│ │ │ │ │ │
│ └────────────┬─────────────┘ └─────────────┬────────────┘ │
│ │ │ │
│ │ ┌────────────────────────┐ │ │
│ └───────▶│ Development │◀──────┘ │
│ └────────────┬───────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ Deployed │ │
│ │ Automation │ │
│ └────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Quick Comparison
| Aspect | PDD | SDD |
|---|---|---|
| Focus | Business process | Technical solution |
| Language | Business terminology | Technical terminology |
| Author | Business Analyst, SME | RPA Developer, Solution Architect |
| Primary Reader | Business stakeholders, Process owner | Development team, Support team |
| Timing | Before development starts | Before coding starts |
| Sign-off | Business owner, Process owner | Technical lead, Architecture review |
| Updates | When business process changes | When technical implementation changes |
A Note on Agile RPA Development
ℹ️ Agile Consideration: The PDD → SDD → Development flow described here follows a traditional V-Model / Waterfall approach, which is the enterprise standard for regulated environments.
In Agile RPA settings (startups, fast-paced teams), documentation is often streamlined:
| Traditional (Enterprise) | Agile (Lightweight) |
|---|---|
| Full PDD (20-30 pages) | User Stories + Process Map |
| Formal SDD (30-50 pages) | Technical Notes in Wiki |
| Sign-off meetings | PR reviews with documentation |
| Separate documents | Living documentation in Git |
When to use which:
| Context | Recommended Approach |
|---|---|
| Regulated industry (Finance, Healthcare) | Full PDD/SDD |
| Audit requirements | Full PDD/SDD |
| Large team (5+ developers) | Full PDD/SDD |
| Complex integrations | Full PDD/SDD |
| Small team, fast iteration | Agile lightweight |
| POC/Prototype | Agile lightweight |
💡 This article focuses on the Enterprise Standard (full PDD/SDD), which is appropriate for most production RPA deployments. Even in Agile environments, the concepts here apply—just the formality level varies.
Part 1: The Process Definition Document (PDD)
The PDD is your contract with the business. It captures exactly what the process does today (As-Is) and what the automated version will do (To-Be).
PDD Structure Overview
┌─────────────────────────────────────────────────────────────────────────────┐
│ PDD Document Structure │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. Executive Summary │
│ └── One-page overview for executives │
│ │
│ 2. Process Overview │
│ ├── Process name, owner, department │
│ ├── Business context and objectives │
│ └── Scope (in-scope / out-of-scope) │
│ │
│ 3. As-Is Process │
│ ├── Current process flow diagram │
│ ├── Step-by-step description │
│ ├── Systems and applications used │
│ └── Pain points and inefficiencies │
│ │
│ 4. To-Be Process │
│ ├── Automated process flow diagram │
│ ├── Human touchpoints (where manual intervention needed) │
│ └── Expected improvements │
│ │
│ 5. Business Rules │
│ ├── Decision logic tables │
│ ├── Validation rules │
│ └── Exception conditions │
│ │
│ 6. Data Requirements │
│ ├── Input data (sources, formats, examples) │
│ ├── Output data (destinations, formats) │
│ └── Data transformations │
│ │
│ 7. System Landscape │
│ ├── Applications list with versions │
│ ├── Access requirements (credentials, permissions) │
│ └── System dependencies │
│ │
│ 8. Metrics & KPIs │
│ ├── Current performance baseline │
│ ├── Target metrics post-automation │
│ └── How success will be measured │
│ │
│ 9. Appendices │
│ ├── Sample documents │
│ ├── Screenshots │
│ └── Glossary │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Section Deep Dives
1. Executive Summary
One page maximum. Written last, read first.
## Executive Summary
**Process Name:** Invoice Processing - Accounts Payable
**Business Owner:** Jane Smith, AP Manager
**Automation Candidate Score:** 85/100
### Current State
- 500 invoices processed manually per week
- Average processing time: 12 minutes per invoice
- Error rate: 3.2%
- FTE involved: 2.5
### Proposed Automation
- Bot processes 450 invoices (90% straight-through)
- Human handles 50 exceptions (10%)
- Processing time: 2 minutes per invoice (83% reduction)
- Expected error rate: 0.5%
### Expected Benefits
- Annual time savings: 1,300 hours
- Cost savings: $52,000/year
- Improved accuracy and audit trail2. As-Is Process Flow
Use swimlane diagrams to show who does what:
┌───────────────────────────────────────────────────────────────────────┐
│ As-Is: Invoice Processing Flow │
├───────────────┬───────────────────────────────────────────────────────┤
│ │ │
│ Mailroom │ ┌───────┐ │
│ │ │Receive│ │
│ │ │Invoice│───────┐ │
│ │ │(Email)│ │ │
│ │ └───────┘ │ │
│ │ │ │
├───────────────┼─────────────────┼─────────────────────────────────────┤
│ │ │ │
│ AP Clerk │ ▼ ┌────────┐ │
│ │ ┌───────┐ │Download│ │
│ │ │ Open │──▶│PDF │ │
│ │ │ Email │ └───┬────┘ │
│ │ └───────┘ │ │
│ │ │ │
│ │ ┌───────┐ ┌───────┐│ ┌───────┐ │
│ │ │Enter │ │Valid- │▼ │Extract│ │
│ │ │in SAP │◀────│ate vs │◀────│Data │ │
│ │ │ │ │PO │ │Manua- │ │
│ │ └───────┘ └───────┘ │lly │ │
│ │ │ └───────┘ │
│ │ ▼ │
│ │ ◇ Amount │
│ │ ╱ ╲ > $10k │
│ │ ◇ ◇───────────────────┐ │
│ │ ╲ ╱ │ │
│ │ ◇ No │ │
├───────────────┼──────┼─────────────────────┼──────────────────────────┤
│ │ │ │ │
│ AP Manager │ ▼ │ │
│ │ ┌────┐ ▼ │
│ │ │Done│ ┌────────┐ │
│ │ └───┐│ │Review &│ │
│ │ └┘ │Approve │ │
│ │ └────┬───┘ │
│ │ │ │
│ │ ▼ │
│ │ ┌────┐ │
│ │ │Done│ │
│ │ └────┘ │
└───────────────┴───────────────────────────────────────────────────────┘
Pain Points Identified:
• Manual data entry from PDF → Error-prone, time-consuming
• Email inbox management → Invoices get lost
• No tracking until entered in SAP → Visibility gapStandard BPMN Notation Reference:
[!TIP] Use proper BPMN 2.0 symbols for professional process maps:
┌─────────────────────────────────────────────────────────────────────┐
│ BPMN Symbol Reference │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ( ) Start Event ┌─────────┐ Task/Activity │
│ │ │ │
│ (◎) End Event └─────────┘ │
│ │
│ ◇ Gateway ┌ ─ ─ ─ ─ ┐ System (dashed border) │
│ (Decision) │ │ │
│ └ ─ ─ ─ ─ ┘ │
│ │
│ ─────────────────────────────────── Swimlane (role/department) │
│ Sales Dept │
│ ─────────────────────────────────── │
│ │
│ Common Gateways: │
│ ◇ Exclusive (XOR) - Only one path │
│ + Parallel (AND) - All paths execute │
│ O Inclusive (OR) - One or more paths │
│ │
└─────────────────────────────────────────────────────────────────────┘3. Business Rules Table
Capture every decision the human makes:
| Rule ID | Condition | Action | Exception Handling |
|---|---|---|---|
| BR-001 | Invoice amount matches PO ± 2% | Proceed to posting | - |
| BR-002 | Invoice amount differs > 2% from PO | Flag for manual review | Create exception queue item |
| BR-003 | Vendor not found in SAP | Search by tax ID | If still not found, escalate to AP Manager |
| BR-004 | Invoice date > 90 days old | Reject automatically | Send rejection email to vendor |
| BR-005 | Duplicate invoice number detected | Skip processing | Log and notify AP Clerk |
| BR-006 | Amount > $10,000 | Requires manager approval | Route to approval workflow |
🚨 Critical: Business rules are the #1 source of scope creep. Get sign-off on this table.
4. Data Requirements
Input Data
| Field | Source | Format | Required | Example | Validation |
|---|---|---|---|---|---|
| Invoice Number | String | Yes | INV-2024-00123 | Alphanumeric, max 20 chars | |
| Vendor Name | String | Yes | ACME Corporation | Match against vendor master | |
| Invoice Date | Date | Yes | 2024-01-15 | Not future, not > 90 days old | |
| Amount | Decimal | Yes | 1,234.56 | Positive, max 2 decimal places | |
| PO Number | String | Conditional | PO-2024-001 | Required if amount > $500 | |
| Currency | String | Yes | USD | ISO 4217 code |
Output Data
| Field | Destination | Format | Example |
|---|---|---|---|
| SAP Document Number | SAP, Excel Report | String | 5100001234 |
| Posting Date | SAP | Date | 2024-01-16 |
| Processing Status | Orchestrator Queue | Enum | Successful / Failed / Pending |
| Error Message | Orchestrator Queue | String | ”Vendor not found” |
Test Data Strategy
[!IMPORTANT] Test Data is Where Projects Stall
Many projects are delayed because UAT environment lacks realistic data.
| Environment | Data Source | Masking Required? | Notes |
|---|---|---|---|
| Development | Synthetic | No | Create 50 sample invoices |
| UAT | Copy of Prod (masked) | Yes | Use data masking tool |
| Prod | Live data | N/A | - |
Data Masking Requirements:
- PII fields (vendor contacts, bank accounts) must be masked
- Referential integrity preserved (masked vendor ID must exist in vendor master)
- Edge cases included: multi-line invoices, foreign currencies, credit notes
5. System Landscape
| System | Version | Purpose | Access Method | Credentials |
|---|---|---|---|---|
| Outlook | M365 | Email inbox | Desktop App | Service account |
| SAP ECC | 6.0 EHP8 | ERP posting | SAP GUI 7.70 | Service account |
| SharePoint | Online | Document storage | Browser/API | Service account |
| Oracle DB | 19c | Vendor validation | ODBC | Read-only account |
Access Requirements:
- SAP: Transaction codes FB60, FBL1N, XK03
- Outlook: Shared mailbox access
- SharePoint: Contribute permission to AP folder
- Network: Access to file share \server\ap\invoices
6. Metrics & KPIs
| Metric | Current (Baseline) | Target | Measurement Method |
|---|---|---|---|
| Processing time per invoice | 12 minutes | 2 minutes | Orchestrator logs |
| Error rate | 3.2% | < 0.5% | Exception count / total |
| Invoices processed per day | 100 | 400 | Queue completion count |
| SLA compliance (48h) | 85% | 98% | Timestamp analysis |
| FTE effort | 2.5 FTE | 0.5 FTE | Time tracking |
Part 2: The Solution Design Document (SDD)
The SDD is your technical blueprint. It’s the developer’s bible and the support team’s lifeline.
SDD Structure Overview
┌─────────────────────────────────────────────────────────────────────────────┐
│ SDD Document Structure │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. Solution Overview │
│ ├── Architecture pattern (REFramework, Linear, etc.) │
│ ├── High-level flow diagram │
│ └── Key design decisions │
│ │
│ 2. Component Design │
│ ├── Workflow inventory │
│ ├── Each workflow: purpose, inputs, outputs │
│ └── Reusable components / libraries │
│ │
│ 3. Queue Design │
│ ├── Queue configuration │
│ ├── Queue item schema │
│ └── Retry strategy │
│ │
│ 4. Exception Handling │
│ ├── Business exceptions list │
│ ├── System exceptions handling │
│ └── Retry vs fail decision matrix │
│ │
│ 5. Configuration & Assets │
│ ├── Config.xlsx structure │
│ ├── Orchestrator assets │
│ └── Environment-specific settings │
│ │
│ 6. Selector Strategy │
│ ├── Critical selectors │
│ ├── Fallback approaches │
│ └── Known selector risks │
│ │
│ 7. Logging Strategy │
│ ├── Log fields definition │
│ ├── Log level by environment │
│ └── Key log messages │
│ │
│ 8. Security Considerations │
│ ├── Credential storage │
│ ├── Data handling (PII, sensitive) │
│ └── Audit trail │
│ │
│ 9. Deployment & Maintenance │
│ ├── Deployment steps │
│ ├── Rollback procedure │
│ └── Monitoring and alerts │
│ │
└─────────────────────────────────────────────────────────────────────────────┘[!NOTE] For Very Large Projects: Consider HLD/LLD Split
On multinational or cross-platform projects (10+ developers), the SDD may be split:
Document Scope Audience HLD (High-Level Design) Architecture, integration points Architects, PMs LLD/DSD (Detailed Design) Component-level specs per workflow Developers For typical RPA projects (1-3 developers), a single SDD is sufficient.
Section Deep Dives
1. Solution Architecture
Pattern Selection:
| Pattern | When to Use |
|---|---|
| REFramework + Queue | High volume, needs scalability, multiple performers |
| REFramework + Tabular | Fixed dataset (Excel), single performer |
| Linear Process | Simple, sequential, < 50 transactions |
| State Machine | Complex branching, non-linear flow |
Architecture Diagram:
┌─────────────────────────────────────────────────────────────────────────────┐
│ Invoice Processing Architecture │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────┐ │
│ │ Outlook │ │
│ │ Inbox │ │
│ └──────┬─────┘ │
│ │ │
│ │ │
│ ┌──────▼─────┐ ┌──────────────────────────────────────────────────────┐ │
│ │ DISPATCHER │ │ Orchestrator Queue │ │
│ │ (Scheduled │ │ "Invoice_Processing" │ │
│ │ 6 AM) │ │ │ │
│ └──────┬─────┘ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │
│ └─────────▶│ │Item 1│ │Item 2│ │Item 3│ │... │ │ │
│ │ └──────┘ └──────┘ └──────┘ └──────┘ │ │
│ └───────────────────────┬──────────────────────────────┘ │
│ │ │
│ ┌───────────────────┼───────────────────┐ │
│ │ │ │ │
│ │ │ │ │
│ ┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼─────┐ │
│ │ PERFORMER │ │ PERFORMER │ │ PERFORMER │ │
│ │ Robot 1 │ │ Robot 2 │ │ Robot 3 │ │
│ └──────┬─────┘ └──────┬─────┘ └──────┬─────┘ │
│ │ │ │ │
│ └─────────┬─────────┴─────────┬─────────┘ │
│ │ │ │
│ │ │ │
│ ┌────▼──────────────┐ │ │
│ │ SAP ECC 6.0 │ │ │
│ │ (Transaction FB60)│ │ │
│ └───────────────────┘ │ │
│ │ │
│ ┌───────────────────────────────────────────────────▼─────────────────────┐ │
│ │ Monitoring: Orchestrator Dashboard + Email alerts on failure │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘2. Component Design (Workflow Inventory)
| Workflow | Type | Purpose | Input | Output |
|---|---|---|---|---|
Main.xaml | Entry Point | REFramework orchestration | - | - |
InitAllSettings.xaml | Initialization | Load config, initialize apps | Config path | Config dictionary |
GetTransactionData.xaml | Get Data | Fetch next queue item | Queue name | Transaction item or Nothing |
Process.xaml | Process | Main processing logic | Transaction item | Success/Exception |
SAP_Login.xaml | Utility | Login to SAP | Credential name | Boolean (success) |
SAP_PostInvoice.xaml | Utility | Post invoice in SAP | Invoice data | SAP document number |
ExtractPDF_Data.xaml | Utility | Extract data from PDF | PDF path | Invoice object |
ValidateInvoice.xaml | Validation | Apply business rules | Invoice object | Validation result + errors |
SendExceptionEmail.xaml | Notification | Email on exceptions | Exception details | - |
3. Queue Design
Queue Configuration:
| Setting | Value | Rationale |
|---|---|---|
| Queue Name | Invoice_Processing | Clear, matches process name |
| Max Retries | 2 | Transient errors (network, SAP busy) may resolve |
| Auto Retry | Yes | System exceptions auto-retry |
| Unique Reference | Yes | Prevent duplicate invoice processing |
| SLA | 4 hours | Business requirement |
Queue Item Schema:
{
"Reference": "INV-2024-00123",
"SpecificContent": {
"InvoiceNumber": "INV-2024-00123",
"VendorName": "ACME Corporation",
"VendorID": "V001234",
"InvoiceDate": "2024-01-15",
"Amount": 1234.56,
"Currency": "USD",
"PONumber": "PO-2024-001",
"PDFPath": "\\\\server\\ap\\inbox\\INV-2024-00123.pdf",
"EmailSubject": "Invoice from ACME Corporation",
"ReceivedDate": "2024-01-15T08:30:00Z"
}
}Output Data (set on completion):
{
"Status": "Successful",
"SAPDocumentNumber": "5100001234",
"PostingDate": "2024-01-16",
"ProcessingDuration_ms": 45000
}4. Exception Handling Strategy
Business Exceptions (Do NOT Retry):
| Code | Exception | Action | Notification |
|---|---|---|---|
| BE-001 | Vendor not found | Set failed, log | Email to AP Clerk |
| BE-002 | Duplicate invoice | Set failed, log | Log only |
| BE-003 | Amount mismatch > 2% | Set failed, log | Email to AP Clerk |
| BE-004 | Invoice too old (> 90 days) | Set failed, log | Auto-rejection email |
| BE-005 | Missing required field | Set failed, log | Email to AP Clerk |
System Exceptions (Retry):
| Code | Exception | Max Retries | Action After Max |
|---|---|---|---|
| SE-001 | SAP login failed | 3 | Fail, alert support |
| SE-002 | SAP transaction timeout | 2 | Fail, log details |
| SE-003 | Network error | 2 | Retry after 60s |
| SE-004 | PDF file not accessible | 2 | Fail, alert support |
| SE-005 | Orchestrator connection lost | 3 | Retry after 30s |
Decision Matrix:
┌─────────────────────────────────────────────────────────────────┐
│ Exception Handling Decision Matrix │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Exception Occurs │
│ │ │
│ ▼ │
│ ┌───────────────┐ Yes ┌───────────────────────────┐ │
│ │Is it a known │──────────▶│Business Exception │ │
│ │Business Rule │ │• Don't retry │ │
│ │violation? │ │• Set item Failed │ │
│ └───────────────┘ │• Log reason │ │
│ │ │• Notify if needed │ │
│ │ No └───────────────────────────┘ │
│ ▼ │
│ ┌───────────────┐ No ┌───────────────────────────┐ │
│ │Is app still │──────────▶│App Exception │ │
│ │responsive? │ │• Kill app │ │
│ │ │ │• Restart app │ │
│ └───────────────┘ │• Retry transaction │ │
│ │ └───────────────────────────┘ │
│ │ Yes │
│ ▼ │
│ ┌───────────────┐ Yes ┌───────────────────────────┐ │
│ │Retry count │──────────▶│System Exception │ │
│ │exceeded? │ │• Fail item │ │
│ │ │ │• Escalate alert │ │
│ └───────────────┘ └───────────────────────────┘ │
│ │ │
│ │ No │
│ ▼ │
│ ┌───────────────┐ │
│ │Retry with │ │
│ │exponential │ │
│ │backoff │ │
│ └───────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘5. Configuration & Assets
Config.xlsx Structure:
| Sheet | Purpose |
|---|---|
| Settings | General settings (URLs, timeouts, toggles) |
| Constants | Values that never change across environments |
| Assets | Names of Orchestrator assets to retrieve |
Settings Sheet Example:
| Name | Value | Description |
|---|---|---|
| OrchestratorQueueName | Invoice_Processing | Queue to process |
| MaxRetryNumber | 3 | Max retries per transaction |
| SAPTimeout_seconds | 60 | SAP operation timeout |
| EmailRecipients_OnError | ap-support@company.com | Error notification emails |
| LogLevel | Info | Trace/Info/Warn/Error |
Orchestrator Assets:
| Asset Name | Type | Scope | Description |
|---|---|---|---|
| SAP_ServiceAccount | Credential | Process | SAP login credentials |
| Outlook_ServiceAccount | Credential | Process | Email account credentials |
| AP_SharePoint_URL | Text | Per-environment | SharePoint site URL |
| Feature_SendErrorEmails | Bool | Per-environment | Enable/disable error emails |
6. Selector Strategy
Critical Selectors:
| Application | Element | Selector | Stability Risk | Fallback |
|---|---|---|---|---|
| SAP | Invoice Number field | <sap id='usr/ctxt*'/> | Low | - |
| SAP | Post button | <sap name='btn[11]'/> | Medium | Keyboard shortcut F8 |
| Outlook | Inbox folder | <wnd cls='NetUIHWND' name='*Inbox*'/> | Low | - |
| Amount field | Anchor-based | High | RegEx extraction |
Selector Best Practices Applied:
- Using wildcards for dynamic parts
- Avoiding idx where possible
- Using anchor-based approach for PDF data
- Defining keyboard shortcuts as fallback
7. Logging Strategy
Log Fields (Add Log Fields activity):
| Field | Type | When Added | Purpose |
|---|---|---|---|
| ProcessName | String | Init | Filter by process |
| TransactionID | String | Each transaction | Trace specific item |
| InvoiceNumber | String | Each transaction | Business correlation |
| VendorName | String | Each transaction | Business correlation |
| Amount | Decimal | Each transaction | Analytics |
| Environment | String | Init | Distinguish Dev/UAT/Prod |
Key Log Messages:
| When | Level | Message Template |
|---|---|---|
| Process start | Info | ”Process started. Version: {version}“ |
| Queue item retrieved | Info | ”Processing invoice {InvoiceNumber} from {VendorName}“ |
| Validation passed | Trace | ”Validation passed for {InvoiceNumber}“ |
| SAP posting success | Info | ”Posted to SAP. Document: {SAPDocNumber}“ |
| Business exception | Warn | ”Business exception: {ExceptionType} - {Details}“ |
| System exception | Error | ”System exception in {Workflow}: {Message}“ |
| Process end | Info | ”Process complete. Processed: {Count}, Failed: {FailCount}“ |
8. Security Matrix
[!IMPORTANT] For Security Audits: Document every credential and data access point.
Security Matrix:
| Asset Name | Asset Type | Access Level | Users/Processes | Storage Location | Rotation Policy |
|---|---|---|---|---|---|
| SAP_ServiceAccount | Credential | Read/Write | Invoice_Process | Orchestrator | 90 days |
| Outlook_ServiceAccount | Credential | Read | Invoice_Process | Orchestrator | 90 days |
| DB_ConnectionString | Credential | Read-only | Invoice_Process | CyberArk | 365 days |
| SharePoint_SiteURL | Text | Read/Write | Invoice_Process | Orchestrator | N/A |
| Invoice_PDFs | Data | Read | Bot only | \\server\ap\ | N/A |
Data Classification:
| Data Type | Classification | Handling |
|---|---|---|
| Vendor bank account | Confidential | Never log, mask in exceptions |
| Invoice amounts | Internal | Log for audit, no external sharing |
| Processing status | Internal | Can display in dashboards |
Part 3: Best Practices and Anti-Patterns
Documentation Anti-Patterns
| Anti-Pattern | Problem | Solution |
|---|---|---|
| Outdated docs | Documentation written once, never updated | Include doc updates in Definition of Done |
| Novel-length PDD | 50+ pages no one reads | Keep it concise, use tables and diagrams |
| Missing business rules | ”I thought that was obvious” | Table every single decision |
| Copy-paste SDD | Same template, wrong details | Review each section for THIS project |
| Developer-only SDD | Support team can’t understand | Include troubleshooting guide |
| No version control | ”Which version is current?” | Store docs in Git/SharePoint with versions |
[!WARNING] Documentation “Rots” Faster Than Code
An SDD that hasn’t been updated with Change Requests is more dangerous than no documentation at all—it will mislead maintainers.Golden Rule: Add documentation updates to your Definition of Done (DoD). No ticket can be closed without updating the SDD.
Documentation Maintenance Workflow
┌─────────────────────────────────────────────────────────────────┐
│ Documentation Lifecycle │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────┐ Review ┌────────────┐ Approve ┌───────────┐
│ │ Draft │ ──────────▶ │ Review │ ───────────▶ │ Final │
│ │ v0.1 │ │ v0.9 │ │ v1.0 │
│ └────────────┘ └────────────┘ └───────────┘
│ ▲ │
│ │ │
│ │ Development & UAT │
│ │ │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ Change Request or Bug Fix │ │
│ │ │ │
│ │ 1. Update code │ │
│ │ 2. Update SDD (if technical change) │◀───┘
│ │ 3. Update PDD (if business rule change) │
│ │ 4. Increment version (v1.1, v1.2, ...) │
│ │ 5. PR review includes doc review │
│ │ │
│ └───────────────────────────────────────────────────────┘
│ │
│ Version History Table: │
│ ┌──────────┬────────────┬──────────┬─────────────────────────┐ │
│ │ Version │ Date │ Author │ Changes │ │
│ ├──────────┼────────────┼──────────┼─────────────────────────┤ │
│ │ 1.0 │ 2024-01-15 │ J. Smith │ Initial release │ │
│ │ 1.1 │ 2024-02-01 │ A. Lee │ Added BR-007 │ │
│ │ 1.2 │ 2024-03-10 │ J. Smith │ Updated SAP selectors │ │
│ └──────────┴────────────┴──────────┴─────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘Templates & Checklists
PDD Review Checklist
- Executive summary is complete and accurate
- As-Is process is documented with flow diagram
- To-Be process shows clear automation boundaries
- All business rules are captured in table format
- Input/output data is fully specified with examples
- All systems and access requirements are listed
- Success metrics are defined and measurable
- Business owner has signed off
SDD Review Checklist
- Architecture pattern is justified
- All workflows are listed with inputs/outputs
- Queue schema is fully defined
- Exception handling covers all known scenarios
- Config settings are documented
- Critical selectors are documented with fallbacks
- Logging strategy includes transaction correlation
- Deployment steps are clear and tested
- Technical lead has signed off
Conclusion
Documentation isn’t glamorous. It won’t demo well in sprint reviews. But it’s the difference between:
- A project (runs for 6 months, then abandoned)
- A product (runs for years, maintained, evolved)
The investment:
- PDD: 4-8 hours upfront
- SDD: 8-16 hours upfront
The return:
- Fewer misunderstandings (saves 20+ hours per incident)
- Faster onboarding (saves 40+ hours per new team member)
- Easier maintenance (saves countless hours over lifetime)
- Audit-ready documentation (potentially priceless)
Write the docs. Your future self will thank you.
Real-World Example: Bank Reconciliation RPA
Want to see PDD and SDD templates applied to a real project? Check out the Bank Reconciliation automation:
| Aspect | Details |
|---|---|
| Process | Bank Statement Reconciliation |
| Pattern | Dispatcher-Performer with Orchestrator Queue |
| Matching Logic | Exact Match, Fuzzy Match, BATCH, SPLIT |
| Technology | UiPath REFramework, SQL Server, OCR, Regex |
| ROI | 81.8% with 14.7 month payback |
👉 View Project with PDD/SDD Downloads
💡 Tip: Use these documents as templates for your own projects. Replace the specific details while keeping the structure.