Pega Robotics

Pega Intelligent Automation — Robotics

Covers the full Pega RPA stack: Robot Studio (development), Robot Runtime (execution), and Robot Manager (fleet management). For Pega Platform case management and decisioning there is no dedicated skill yet — answer from general knowledge, or use web-research for current Pega Platform documentation.

1. Robot Studio Overview

Robot Studio is the Windows desktop IDE for developing Pega RPA automations. It provides a visual drag-and-drop design surface, component library, adapter framework for target application connectivity, and debugging/testing tools.

Project Structure

MyRPAProject/
├── Automations/           # Top-level orchestration flows
│   ├── ProcessInvoice.auto
│   └── UpdateCRM.auto
├── Components/            # Reusable building blocks
│   ├── Login_SAP.comp
│   ├── ExtractTableData.comp
│   └── NavigateToScreen.comp
├── Adapters/              # Target application connectors
│   ├── WebApp_Chrome.adapter
│   ├── SAPGui.adapter
│   └── Mainframe3270.adapter
├── GlobalVariables/       # Shared configuration
├── References/            # External assembly references
└── Project.rsproj         # Project file (XML-based)

Key Concepts

Automation vs Component

• Automations orchestrate the process — they call components in sequence, handle top-level exceptions, manage process state, and are the deployable unit.
• Components do the work — they interact with target applications through adapters, are independently testable, and are reusable across multiple automations.
• Rule of thumb: if you would copy-paste a section of logic, extract it into a component.

2. Automation Design

Automation Flow Structure

A well-structured automation follows this pattern:

Initialize
├── Load configuration (environment-specific)
├── Retrieve credentials from vault
├── Launch/attach to target applications
├── Validate prerequisites (app version, screen state)
│
Main Processing
├── Get work item from queue (or input parameters)
├── FOR EACH work item:
│   ├── Navigate to starting screen
│   ├── Process item (call components)
│   ├── Validate result
│   ├── Update work item status (completed/failed)
│   └── Log outcome
│
Cleanup
├── Close/detach target applications
├── Release credentials
└── Report summary (items processed, failed, skipped)

Component Design Principles

• Single Responsibility — one component does one thing (e.g., "Login to SAP", not "Login to SAP and navigate to transaction and extract data").
• Defined Contract — every component declares explicit input and output parameters with types.
• Adapter Independence — components reference adapters by logical name, not hard-coded paths. This allows adapter swapping between environments.
• Error Propagation — components should throw typed exceptions, not silently swallow errors. Let the calling automation decide how to handle failures.

Adapter Types

3. Component Development

Design Surface

Robot Studio's visual designer presents components as flowchart-like diagrams with:

• Start — entry point, defines input parameters.
• End — exit point, defines output parameters.
• Steps — actions (click, type, read, set variable, call component).
• Decisions — conditional branches (if/else, switch).
• Loops — iteration (for each, while, do-while).
• Error Handling — try/catch/finally blocks.
• Connectors — flow control arrows between elements.

Variable Management

Data Types

String          — text values
Integer         — whole numbers (Int32)
Long            — large whole numbers (Int64)
Double          — decimal numbers
Boolean         — true/false
DateTime        — date and time values
DataTable       — tabular data (rows and columns)
List<T>         — typed collections
Object          — generic (avoid when possible — prefer typed)
SecureString    — encrypted credential values

Expressions and VB.NET Snippets

Robot Studio uses VB.NET syntax for expressions in steps and decisions:

' String manipulation
result = AccountNumber.Trim().Substring(0, 8).ToUpper()

' Date formatting
formattedDate = DateTime.Now.ToString("yyyy-MM-dd")

' Null/empty checks (common in decisions)
Not String.IsNullOrEmpty(CustomerName)

' DataTable row access
cellValue = MyTable.Rows(rowIndex)("ColumnName").ToString()

' Collection operations
itemCount = MyList.Count
exists = MyList.Contains("SearchValue")

' Type conversion
amount = CDbl(amountString.Replace(",", ""))
intValue = CInt(textValue)

' Regex matching
Dim match As Boolean = System.Text.RegularExpressions.Regex.IsMatch(input, "^\d{8}$")

Collections — DataTable Operations

' Create a DataTable
Dim dt As New DataTable()
dt.Columns.Add("Name", GetType(String))
dt.Columns.Add("Amount", GetType(Double))

' Add rows
dt.Rows.Add("Invoice001", 1500.00)

' Filter rows
Dim filtered() As DataRow = dt.Select("Amount > 1000")

' Sort
Dim view As New DataView(dt)
view.Sort = "Amount DESC"

' Loop (in the designer, use a For Each loop step targeting DataRow)
For Each row As DataRow In dt.Rows
    Dim name As String = row("Name").ToString()
Next

4. Adapters & Interrogation

Web Adapter (Chrome / Edge / Firefox)

The Web adapter connects to browsers via native messaging extensions. It provides full DOM access for control identification.

Interrogation strategies (in order of preference):

1. ID attribute — #submitButton — most stable, survives layout changes.
2. data- attributes* — [data-testid="login-btn"] — designed for automation, framework-agnostic.
3. Name attribute — [name="username"] — stable for form fields.
4. CSS selector — div.modal-content > form > input:nth-child(2) — flexible but fragile if DOM restructures.
5. XPath — //table[@id='results']//tr[3]/td[2] — powerful for complex traversal, but verbose and brittle.

Common operations:

SetValue        — type text into an input field
Click           — click a button/link/element
GetValue        — read text from an element
GetAttribute    — read an HTML attribute value
GetTable        — extract an HTML table into a DataTable
WaitForControl  — wait until an element appears in the DOM
ExecuteScript   — run JavaScript in the browser context
SelectItem      — choose from a dropdown (by text/value/index)

Browser extension requirement: Each target browser needs the Pega Robot Studio browser extension installed and enabled. Chrome and Edge (Chromium) use the same extension. Firefox uses a separate extension.

Windows Adapter (Win32 / UI Automation / MSAA)

Connects to native Windows applications using the UI Automation (UIA) framework, with fallback to MSAA and raw Win32 messaging.

Identification hierarchy:

1. AutomationId — assigned by the developer, most reliable.
2. Name — visible text label or accessible name.
3. ClassName — Win32 window class (e.g., Edit, Button, SysListView32).
4. ControlType — UIA control type (Button, Edit, DataGrid, TreeItem).
5. Window title + child index — last resort, positional.

Diagnostics: Use the Interrogation Spy tool (magnifying glass icon) to inspect live control trees. Compare with Windows Accessibility Insights or Inspect.exe for verification.

SAP Adapter

Connects through the SAP GUI Scripting API. Requires SAP GUI Scripting to be enabled on both the SAP application server (sapgui/user_scripting = TRUE in profile parameter rdisp/gui_comp_level) and the local SAP GUI client.

Key operations:

SetField        — populate a SAP GUI field by technical name (e.g., "usr/txtRSYST-BNAME")
GetField        — read a field value
PressButton     — activate a SAP GUI button
SelectNode      — navigate tree controls
RunTransaction  — execute a transaction code (e.g., "VA01", "ME21N")
GetStatusBar    — read the SAP status bar message (type + text)
ReadGridView    — extract ALV grid data into a DataTable

Field identification: Use SAP GUI's built-in script recorder (Alt+F12 → Script Recording) or Robot Studio's SAP Interrogation mode to discover field technical names.

Terminal Adapter (3270 / 5250 Mainframe)

Connects to mainframe terminal sessions via terminal emulators (IBM Personal Communications, Micro Focus Rumba, HLLAPI-compatible emulators).

Identification: Position-based using row and column coordinates. Screen identification uses title fields or unique text at known positions.

SetField(row, col, value)    — type text at a screen position
GetField(row, col, length)   — read text from a screen position
SendKey(key)                 — send a terminal key (Enter, PF1-PF24, Tab, Clear)
WaitForScreen(identifier)    — wait for a specific screen to appear
GetScreenText()              — capture entire screen as text

Screen navigation pattern:

1. WaitForScreen("MAIN MENU")         — verify starting screen
2. SetField(21, 7, "3")               — type option number
3. SendKey(Keys.Enter)                 — submit
4. WaitForScreen("CUSTOMER INQUIRY")  — verify target screen loaded
5. SetField(5, 22, customerNumber)     — populate search field
6. SendKey(Keys.Enter)                 — execute search
7. WaitForField(8, 22, isNotEmpty)     — wait for results

Citrix / RDP Adapter

Used when the target application runs in a remote session where direct control-tree access is unavailable. This is the adapter of last resort.

Capabilities:

• Image recognition — locate UI elements by matching bitmap templates (buttons, icons, text regions).
• OCR — read text from screen regions using built-in or external OCR engines.
• Coordinate-based clicks — click at pixel positions relative to anchors.
• Keyboard simulation — send keystrokes to the remote session.

Mitigations for fragility:

• Pin display resolution, DPI scaling, color depth, and Windows theme on the Citrix/RDP host.
• Use anchored regions (relative to a stable reference point) rather than absolute coordinates.
• Implement generous wait conditions with image-based screen verification.
• Maintain separate image libraries per environment if UI differs.
• Prefer OCR text matching over image matching where possible.

5. Error Handling & Resilience

Try/Catch Pattern

Every component and automation should use structured error handling:

TRY
├── Navigate to screen
├── Fill form fields
├── Submit
├── WaitForControl("ConfirmationMessage", timeout: 30s)
│
CATCH (ElementNotFoundException)
├── Take screenshot
├── Log "Target control not found — UI may have changed"
├── Throw (propagate to automation for work-item-level handling)
│
CATCH (TimeoutException)
├── Take screenshot
├── Check if application is responding (WaitForControl with short timeout)
├── IF application frozen:
│   ├── Kill and restart application
│   └── Throw RetryableException
├── ELSE:
│   └── Throw (non-recoverable)
│
CATCH (Exception)    — generic catch-all, always last
├── Take screenshot
├── Log full exception details (type, message, stack trace)
├── Throw (never silently swallow)
│
FINALLY
├── Reset to known state (navigate to home screen)
└── Release any locks held

Wait Conditions

All wait methods accept a timeout parameter (in seconds). Always set explicit timeouts — the default may be too short for slow applications or too long for responsive ones.

Anti-pattern — fixed sleep:

❌  Sleep(5000)                                    — arbitrary, wastes time or breaks
✅  WaitForControl("ResultGrid", timeout: 30)      — precise, adapts to app speed

Retry Logic

Implement retry at the work-item level, not inside individual steps:

FOR EACH workItem IN queue:
    retryCount = 0
    maxRetries = 3

    WHILE retryCount < maxRetries:
        TRY:
            ProcessWorkItem(workItem)
            MarkCompleted(workItem)
            BREAK    — success, exit retry loop
        CATCH RetryableException:
            retryCount += 1
            Log("Retry {retryCount}/{maxRetries} for {workItem.Id}")
            ResetApplicationState()
            IF retryCount >= maxRetries:
                MarkFailed(workItem, "Exceeded max retries")
        CATCH NonRetryableException:
            MarkFailed(workItem, exception.Message)
            BREAK    — no point retrying

Screenshot on Failure

Always capture a screenshot when an exception occurs — it is the most valuable diagnostic artifact for RPA failures:

CATCH (Exception ex)
    screenshotPath = "C:\RobotLogs\Screenshots\" +
                     DateTime.Now.ToString("yyyyMMdd_HHmmss") +
                     "_" + workItemId + ".png"
    TakeScreenshot(screenshotPath)
    Log.Error("Failed processing " + workItemId, ex, screenshotPath)
    THROW

6. Design Patterns

Page Object Model (POM)

Abstract the UI layer from business logic — just as in test automation:

Component: SAP_LoginPage
├── Inputs: username (String), password (SecureString)
├── Outputs: isLoggedIn (Boolean)
├── Methods:
│   ├── EnterUsername(username)     — SetField("usr/txtRSYST-BNAME", username)
│   ├── EnterPassword(password)    — SetField("usr/pwdRSYST-BCODE", password)
│   ├── ClickLogin()               — PressButton("btn[0]")
│   └── IsOnMainMenu() → Boolean  — GetStatusBar().Type != "E"

Component: SAP_TransactionVA01
├── Inputs: orderData (DataTable)
├── Outputs: orderNumber (String)
├── Methods:
│   ├── NavigateToTransaction()    — RunTransaction("VA01")
│   ├── FillHeader(...)
│   ├── AddLineItems(orderData)
│   └── SaveAndGetOrderNumber() → String

Benefits: when SAP screens change (field IDs, layout), you update only the page component — the calling automation is untouched.

Configuration-Driven Automations

Externalize environment-specific values — never embed them in automation logic:

Configuration values (stored in Robot Manager or external config):
├── TargetURL           = "https://crm.prod.company.com"
├── MaxRetries          = 3
├── TimeoutSeconds      = 30
├── ReportEmailAddress  = "rpa-team@company.com"
├── SAPSystemId         = "PRD"
├── SAPClient           = "100"
└── LogLevel            = "Info"

Load configuration at automation start. Components receive config values as input parameters — they never read config directly.

Logging Best Practices

Log levels:
├── DEBUG   — control-level detail (clicked button X, read value Y) — dev/test only
├── INFO    — business milestones (processing item 42, invoice created)
├── WARN    — recoverable issues (retry triggered, fallback used)
├── ERROR   — failures (exception details, screenshot path)
└── FATAL   — automation cannot continue (application crash, credential failure)

Every log entry should include:
├── Timestamp (UTC)
├── Automation name
├── Component name
├── Work item ID (if applicable)
├── Robot machine name
└── Message with context

Modular Component Design

Structure components in layers:

Layer 1 — Adapters (technology coupling)
├── Web_Chrome.adapter
├── SAPGui.adapter
└── Terminal3270.adapter

Layer 2 — Page Components (UI abstraction)
├── CRM_LoginPage.comp
├── CRM_SearchCustomer.comp
├── SAP_CreateOrder.comp
└── Mainframe_AccountInquiry.comp

Layer 3 — Business Components (process logic)
├── ValidateInvoiceData.comp
├── CalculateDiscount.comp
└── FormatOutputReport.comp

Layer 4 — Automations (orchestration)
├── ProcessInvoice.auto        — calls Layer 2 + 3 components
└── ReconcileAccounts.auto

Data-Driven Automation

Separate test/process data from automation logic:

Input sources:
├── Work queues (Robot Manager)     — preferred for production
├── Excel/CSV files                  — batch processing
├── Database queries                 — dynamic data sets
├── API responses                    — real-time integration
└── Pega case data                  — platform integration

Pattern:
1. Read all input records into a DataTable
2. Validate each record before processing (schema, required fields, format)
3. Process valid records, skip and report invalid ones
4. Write results back to source (queue status, output file, API callback)

7. Robot Manager Architecture

Robot Manager is the web-based management console for the Pega RPA fleet. It runs on the Pega Platform application server and provides centralized control over robot agents, deployments, work queues, schedules, and monitoring.

Architecture Overview

┌─────────────────────────────────────────────────┐
│              Pega Platform Server                │
│  ┌───────────────────────────────────────────┐  │
│  │           Robot Manager                    │  │
│  │  ┌──────────┐ ┌──────────┐ ┌───────────┐ │  │
│  │  │Deployment│ │  Work    │ │ Scheduling│ │  │
│  │  │ Manager  │ │  Queues  │ │  Engine   │ │  │
│  │  └──────────┘ └──────────┘ └───────────┘ │  │
│  │  ┌──────────┐ ┌──────────┐ ┌───────────┐ │  │
│  │  │ Fleet    │ │Analytics │ │ Credential│ │  │
│  │  │ Monitor  │ │Dashboard │ │  Vault    │ │  │
│  │  └──────────┘ └──────────┘ └───────────┘ │  │
│  └───────────────────────────────────────────┘  │
└───────────────────────┬─────────────────────────┘
                        │ HTTPS
        ┌───────────────┼───────────────┐
        │               │               │
   ┌────▼────┐    ┌─────▼────┐   ┌─────▼────┐
   │ Robot   │    │ Robot    │   │ Robot    │
   │ Agent 1 │    │ Agent 2  │   │ Agent 3  │
   │(Attended)│   │(Unattend)│   │(Unattend)│
   │ Desktop  │   │  VM 1    │   │  VM 2    │
   └──────────┘   └──────────┘   └──────────┘

Environment Hierarchy

Organization
└── Environment
    ├── Development    — Robot Studio connected, debugging enabled
    ├── Test/QA        — pre-production validation, test queues
    └── Production     — live execution, full monitoring

Each environment has its own Robot Manager instance (or tenant), credential vault entries, configuration sets, and robot agents.

RBAC — Roles

8. Robot Fleet Management

Robot Agent Registration

Each machine running automations requires a Robot Runtime agent registered with Robot Manager:

1. Install Pega Robot Runtime on the target machine (Windows desktop or VM).
2. Configure the agent to connect to Robot Manager (server URL, port, TLS certificate).
3. Register the agent in Robot Manager — assign a name, group, and mode (attended/unattended).
4. Verify connectivity — agent status should show as "Connected" in the fleet dashboard.

Attended vs Unattended Modes

Robot Groups

Group robots by function, environment, or capacity:

Robot Groups:
├── Finance-Attended        — 50 user desktops, attended mode
├── Finance-Unattended      — 10 VMs, invoice processing
├── HR-Unattended           — 5 VMs, employee onboarding
└── IT-Unattended           — 3 VMs, account provisioning

Automations are assigned to groups, not individual robots. Robot Manager distributes work across available robots in the group.

License Management

Robot Runtime licenses are consumed per concurrent agent connection. Monitor license usage in Robot Manager:

• Active licenses — currently connected agents.
• Peak usage — maximum concurrent agents in a period.
• License pool — total available licenses by type (attended/unattended).

9. Deployment Pipeline

Package Creation (Robot Studio)

1. Build the project in Robot Studio (Build → Build Solution)
2. Resolve any compilation errors
3. Create a deployment package (Build → Create Package)
4. Package output: .zip file containing compiled automations, components, adapters, and dependencies
5. Version the package (follows semantic versioning: MAJOR.MINOR.PATCH)

Deployment to Robot Manager

1. Upload the package to Robot Manager (Deployments → Upload Package)
2. Select target environment (dev/test/prod)
3. Assign to robot groups
4. Configure runtime parameters (if any)
5. Activate the deployment
6. Robot agents in the assigned group pull the new package on next check-in

Version Management

• Robot Manager retains previous package versions.
• Only one version of an automation can be active per environment at a time.
• Agents running an older version complete their current execution before switching to the new version.

Environment Promotion

Development                    Test/QA                      Production
┌──────────────┐   promote    ┌──────────────┐   promote   ┌──────────────┐
│ Package v1.3 │────────────►│ Package v1.3 │────────────►│ Package v1.3 │
│ Dev config   │             │ Test config  │             │ Prod config  │
│ Test queues  │             │ QA queues    │             │ Live queues  │
│ Dev creds    │             │ Test creds   │             │ Prod creds   │
└──────────────┘             └──────────────┘             └──────────────┘

Each environment uses its own configuration, credentials, and queue data. The automation package binary is identical across environments — only configuration changes.

Rollback

If a deployment causes issues:

1. Deactivate the current package version.
2. Reactivate the previous version.
3. Agents pick up the rolled-back version on next check-in.
4. Active executions on the faulty version complete (or are terminated) before the rollback takes effect.

10. Work Queues

Work queues are the primary mechanism for distributing work items to unattended robots.

Queue Structure

Queue: InvoiceProcessing
├── Properties:
│   ├── Name: InvoiceProcessing
│   ├── Description: Incoming invoices from AP mailbox
│   ├── Priority: Normal (1-10 scale, 10 = highest)
│   ├── SLA: 4 hours from creation
│   ├── Max retries: 3
│   └── Retry delay: 5 minutes
│
├── Work Item Fields:
│   ├── InvoiceNumber (String, required)
│   ├── VendorName (String, required)
│   ├── Amount (Decimal, required)
│   ├── DueDate (DateTime)
│   └── AttachmentPath (String)

Work Item Lifecycle

        ┌──────┐
        │ New  │◄──── Item added to queue (API, case, manual)
        └──┬───┘
           │ Robot picks up item
        ┌──▼────────┐
        │In Progress │
        └──┬────┬───┘
           │    │
    success │    │ failure
           │    │
   ┌───────▼┐  ┌▼─────────┐
   │Complete│  │  Failed   │
   └────────┘  └──┬───────┘
                   │ retry policy
                   │ (if retries remaining)
               ┌───▼──┐
               │ New  │ — re-queued with incremented retry count
               └──────┘

Work Item States

Queue Operations from Automations

' Get next work item (called at automation start or in processing loop)
workItem = Queue.GetNext("InvoiceProcessing")

' Check if item was returned (queue may be empty)
IF workItem Is Nothing THEN
    Log.Info("Queue empty, exiting")
    EXIT
END IF

' Read work item data
invoiceNumber = workItem.GetField("InvoiceNumber")
amount = CDbl(workItem.GetField("Amount"))

' Process...

' Mark complete with output data
workItem.SetField("ProcessedBy", Environment.MachineName)
workItem.SetField("ERPReference", erpDocNumber)
workItem.MarkCompleted()

' Or mark failed
workItem.MarkFailed("Vendor not found in ERP system")

Queue Monitoring

Key metrics to track per queue:

• Backlog — number of items in "New" state.
• Throughput — items completed per hour.
• Failure rate — percentage of items that failed after all retries.
• Average processing time — time from "In Progress" to "Completed".
• SLA compliance — percentage of items completed within the defined SLA.
• Oldest item — age of the longest-waiting item (indicates bottlenecks).

11. Scheduling

Schedule Types

Schedule Configuration

Schedule: NightlyInvoiceProcessing
├── Automation: ProcessInvoice v2.1
├── Robot Group: Finance-Unattended
├── Frequency: Daily at 22:00 UTC
├── Business Calendar: US-Banking (skip federal holidays)
├── Concurrent limit: 5 robots max
├── Timeout: 4 hours (kill if exceeds)
├── Blackout windows:
│   ├── Last day of quarter: 18:00-06:00 (month-end close)
│   └── Maintenance windows: per IT calendar
├── On failure: Alert rpa-team@company.com
└── Enabled: Yes

Concurrent Execution Limits

Set maximum concurrent robots per automation to prevent:

• Overwhelming target application servers.
• License conflicts on target applications (e.g., SAP GUI licenses).
• Database contention from parallel writes.

Concurrency planning:
├── Target app can handle 10 concurrent sessions → set limit to 8 (20% headroom)
├── Available unattended robots in group: 10
├── Available target app licenses: 15
└── Effective concurrency: min(8, 10, 15) = 8

Blackout Windows

Prevent automation execution during:

• System maintenance windows.
• Month-end/quarter-end close periods.
• Peak user hours (for attended robots that share resources).
• Deployment windows.

12. Monitoring & Analytics

Execution Dashboard

Robot Manager provides real-time dashboards showing:

Fleet Status:
├── Connected: 45/50 agents
├── Executing: 12 robots
├── Idle: 30 robots
├── Disconnected: 5 robots (investigate!)
└── Disabled: 3 robots (maintenance)

Today's Execution Summary:
├── Total executions: 1,247
├── Successful: 1,189 (95.3%)
├── Failed: 42 (3.4%)
├── In Progress: 16 (1.3%)
└── Average duration: 3m 22s

Queue Health:
├── InvoiceProcessing: 142 pending, 4h avg wait
├── CustomerOnboarding: 0 pending, current
├── AccountReconciliation: 23 pending, 1h avg wait
└── ReportGeneration: 567 pending, SLA breach risk ⚠

Key Metrics

Audit Trail

Robot Manager logs all administrative and execution events:

• Deployment actions (upload, activate, rollback) — who, when, what version.
• Schedule changes — who modified, old vs new configuration.
• Robot status changes — connected, disconnected, disabled.
• Work item state transitions — with timestamp and robot identity.
• Credential access — which robot accessed which credential, when.

Alerting

Configure alerts for:

• Robot disconnection (agent offline for > N minutes).
• Automation failure (single failure or consecutive failure threshold).
• Queue SLA breach risk (backlog * avg processing time > remaining SLA window).
• License utilization (approaching maximum concurrent licenses).
• Schedule missed execution (automation did not start at scheduled time).

13. Credential Management

Credential Vault

Robot Manager provides a centralized credential vault — the only sanctioned location for storing automation credentials.

Credential Store:
├── SAP-Production
│   ├── Username: svc_rpa_sap_prd
│   ├── Password: ********** (encrypted)
│   ├── Environment: Production
│   ├── Robot override: None (all robots in group use this)
│   └── Rotation: 90 days
│
├── SAP-Test
│   ├── Username: svc_rpa_sap_tst
│   ├── Password: **********
│   ├── Environment: Test
│   └── Rotation: 90 days
│
├── WebApp-Production
│   ├── Username: rpa_service@company.com
│   ├── Password: **********
│   ├── Environment: Production
│   ├── Robot override:
│   │   ├── Robot-VM-01: rpa_service_01@company.com
│   │   └── Robot-VM-02: rpa_service_02@company.com
│   └── Rotation: 60 days

Credential Access from Automations

' Retrieve credential at runtime — never store in variables longer than needed
Dim cred As Credential = CredentialVault.Get("SAP-Production")

' Use immediately
SAPLogin.EnterUsername(cred.Username)
SAPLogin.EnterPassword(cred.SecurePassword)

' Do NOT log credentials
Log.Info("Logging in to SAP as " + cred.Username)    — OK (username only)
Log.Info("Password is " + cred.Password)              — NEVER DO THIS

Per-Robot Overrides

Some applications require unique credentials per robot session (to avoid concurrent login conflicts). Configure per-robot credential overrides in Robot Manager:

• Same credential name used in the automation code.
• Robot Manager resolves the correct username/password based on which robot is executing.
• Automations are credential-agnostic — they request by name, Robot Manager supplies the right values.

Rotation Policies

• Set expiry reminders in Robot Manager (e.g., 14 days before password expiry).
• Coordinate rotation with the target application's password policy.
• Test new credentials in the test environment before rotating production.
• Stagger rotation across robot groups to avoid simultaneous lockouts.

Windows Credential Manager Integration

For attended robots, Robot Manager can integrate with Windows Credential Manager to store credentials locally (encrypted by Windows DPAPI), with centralized management and push from Robot Manager.

14. Pega Platform Integration

Triggering Automations from Pega Cases

Pega Platform cases can invoke RPA automations as part of case processing:

Case: InsuranceClaim
├── Stage: Data Collection
│   ├── Step: Receive claim (human)
│   └── Step: Validate documents (human)
├── Stage: Processing
│   ├── Step: Extract claim data from legacy system ← ROBOT AUTOMATION
│   ├── Step: Calculate settlement (decisioning)
│   └── Step: Review settlement (human, if above threshold)
├── Stage: Resolution
│   └── Step: Post payment to ERP ← ROBOT AUTOMATION

The case lifecycle can seamlessly hand off work to robots and resume when the robot completes.

Data Flow Between Cases and Robots

Pega Case                          Robot Automation
┌──────────────┐                  ┌──────────────────┐
│ ClaimNumber  │────────────────►│ Input: ClaimNumber│
│ PolicyId     │────────────────►│ Input: PolicyId   │
│ ClaimantName │────────────────►│ Input: ClaimantName│
│              │                  │                    │
│              │                  │ ... processing ... │
│              │                  │                    │
│ LegacyRef   │◄────────────────│ Output: LegacyRef  │
│ ClaimAmount  │◄────────────────│ Output: Amount     │
│ StatusCode   │◄────────────────│ Output: Status     │
└──────────────┘                  └──────────────────┘

Data mapping is configured in the Pega case flow — the automation shape maps case properties to robot input parameters and robot output parameters back to case properties.

Decisioning Integration

Pega Decisioning (AI/ML engine) can determine whether to route work to a robot or a human:

Decision Strategy: RouteClaimProcessing
├── IF claim is straightforward (amount < $5,000, standard type, known vendor):
│   └── Route to Robot Queue (fully automated)
├── IF claim is complex but data extraction is robotic:
│   ├── Route data extraction to Robot Queue
│   └── Route review to Human Work Queue
└── IF claim requires judgment:
    └── Route entirely to Human Work Queue

This creates a hybrid workforce — robots handle high-volume repetitive work, humans handle exceptions and judgment calls, and decisioning optimally routes between them.

DX API Integration

For custom integrations, Robot Manager exposes REST APIs:

# Queue management
POST   /api/v1/queues/{queueId}/items              — add work item
GET    /api/v1/queues/{queueId}/items/{itemId}      — get work item status
PUT    /api/v1/queues/{queueId}/items/{itemId}      — update work item
DELETE /api/v1/queues/{queueId}/items/{itemId}      — remove work item

# Robot management
GET    /api/v1/robots                                — list all robots
GET    /api/v1/robots/{robotId}/status               — get robot status
POST   /api/v1/robots/{robotId}/execute              — trigger automation on specific robot

# Deployment
POST   /api/v1/deployments                           — upload package
PUT    /api/v1/deployments/{deploymentId}/activate    — activate package
PUT    /api/v1/deployments/{deploymentId}/deactivate  — deactivate package

# Schedules
GET    /api/v1/schedules                             — list schedules
POST   /api/v1/schedules                             — create schedule
PUT    /api/v1/schedules/{scheduleId}                — update schedule

# Authentication: OAuth 2.0 bearer token or Pega operator credentials
# Content-Type: application/json

Related Skills