Skip to main content
When you need Duvo to interact with an external system, there are five distinct ways to connect. Picking the right one upfront saves significant setup time and avoids reliability problems down the line. This page walks through each pattern, a decision tree to choose between them, their trade-offs, and how to combine them.

​
The Five Connection Patterns

​
Pattern 1 — Hosted Connection

Pre-built, OAuth-authenticated connections maintained by Duvo. Examples: Gmail, Google Sheets, Slack, HubSpot, Salesforce, Snowflake, Microsoft 365.
  • No server to deploy or maintain.
  • Authentication is handled through a standard OAuth or credential flow in the Connections page.
  • Duvo keeps the connection current as APIs change.
  • Best for services that have a stable, public API and are already in Duvo’s catalog.

​
Pattern 2 — Browser Automation with Stored Login

Duvo controls a real browser to interact with a web application, using credentials stored via Logins and Secrets. Examples: legacy portals, internal dashboards, procurement systems that don’t expose APIs.
  • No API needed on the target system.
  • Works with any website a human can navigate.
  • Slower and less reliable than an API at high volumes.
  • Subject to breaking when the target site changes its UI.
  • Best for low-to-medium volume workflows against web UIs that lack APIs.

​
Pattern 3 — Custom MCP Connection

You deploy and maintain your own MCP server that exposes the tools your assignment needs, then register it in Duvo. See Custom MCP and Building Custom Connections.
  • Full control over what tools are exposed and how they authenticate.
  • Works with internal APIs, proprietary systems, and anything reachable over HTTPS.
  • Requires technical expertise to build, deploy, and maintain.
  • Best when you control the target system’s API and need custom logic or access patterns not available in hosted connections.

​
Pattern 4 — Computer Use / Windows Remote Desktop

Duvo controls a Windows desktop environment — either a Duvo-managed cloud sandbox or your own Windows machine via RDP. See Computer Use.
  • Automates any Windows application regardless of whether it has an API or a web UI.
  • Works with installed desktop software, SAP GUI, Citrix, and Windows-only ERPs.
  • Slowest pattern; screen-reading adds latency.
  • Best for desktop applications that cannot be reached any other way.

​
Pattern 5 — Event and File Intake

Receive structured input from external systems through email attachments, file drops, webhooks, or Duvo’s Intelligent Document Reader. Examples: invoices arriving by email, reports uploaded to a shared folder, form submissions.
  • Passive intake — the external system pushes data to Duvo rather than Duvo polling.
  • Often paired with another pattern to take action after the intake step.
  • Best for document-heavy or event-driven workflows where a human or system sends Duvo something to process.

​
Decision Tree

Answer these questions in order. Stop at the first match. 1. Is the system already in Duvo’s connections catalog?
  • Yes → Use Pattern 1 (Hosted Connection). Connect it from the Connections page and move on.
2. Does the workflow start when someone sends Duvo a file, email, or document?
  • Yes → Start with Pattern 5 (Event and File Intake), then chain to Pattern 1 or 3 for downstream actions.
3. Is the target system a Windows desktop application (no web UI, no API)?
  • Yes → Use Pattern 4 (Computer Use / Windows Remote Desktop).
    • Need access to your own installed software or internal network? Use Windows Remote Desktop.
    • Need a clean sandbox without your own infrastructure? Use Computer Use.
4. Do you control the target system’s API and have technical resources to build a server?
  • Yes → Use Pattern 3 (Custom MCP). You get the most reliability, the most control, and the cleanest tool interface for your assignments.
5. Does the target system have a web UI that a human can log into?
  • Yes → Use Pattern 2 (Browser Automation). Store credentials as a Login in Duvo and point the assignment at the site.
6. None of the above fit?
  • Contact Duvo support to discuss whether a new hosted connection can be added to the catalog.

​
Trade-offs at a Glance

Hosted ConnectionBrowser AutomationCustom MCPComputer Use / RDPEvent & File Intake
ReliabilityHighMediumHighMediumHigh
LatencyLowMediumLowHighLow
Setup effortMinimalLowHighLow–MediumLow
Maintenance burdenNoneMedium (UI changes)High (your server)LowNone
Auth complexityLow (OAuth managed)Low (stored login)Medium–HighLow (RDP creds)None
AuditabilityFullFullFullFullFull
Suitable for high volumeYesNoYesNoYes
Requires APIYesNoYesNoNo

​
When to Combine Patterns

Most real-world workflows use more than one pattern. The common combinations: Browser intake + API actions An order form or legacy portal doesn’t have an export API, so the assignment reads it via browser automation (Pattern 2). It then writes the extracted data to a CRM using a hosted connection (Pattern 1). This is common in procurement and logistics workflows. Event intake + document processing + system update A supplier emails an invoice as a PDF attachment. The assignment receives it via Email Attachments Reader or Intelligent Document Reader (Pattern 5), extracts line items, then posts the result to NetSuite or SAP using a custom MCP server (Pattern 3). RDP capture + Sheets export A Windows ERP like SAP GUI holds operational data with no API surface. The assignment logs in via Windows Remote Desktop (Pattern 4), extracts the data, and writes a formatted report to Google Sheets using a hosted connection (Pattern 1). This is the standard pattern for SAP reporting workflows. Email intake + hosted connection actions Inbound customer requests arrive by email. The assignment reads the email via Gmail (Pattern 1 — hosted), classifies the request, updates the relevant record in Salesforce or HubSpot (also Pattern 1), and sends a reply. No additional patterns needed because everything is in the catalog. Custom MCP + Browser An internal system exposes a partial API. The assignment reads structured records from it via custom MCP (Pattern 3) and then uses browser automation (Pattern 2) to submit those records into a legacy web portal that accepts no API calls.