AutoServa/Integrations
Connection layer

It works your stack. You do not migrate anything.

There is no new database, no data warehouse to build and no screen for your staff to learn. The operator reaches the systems your team already uses, in the same order of preference a good engineer would choose. This page is organised by connection method rather than by vendor, because the method is what determines the permissions, the failure mode and the effort.

An integration mesh with a central hub connecting outward to distinct system nodes
One operator, many systems, each reached the most appropriate way.

Four ways in, in order of preference.

We reach for the highest option on this list that a given system actually supports. Dropping to a lower one is a deliberate decision recorded during the engagement, not a default.

Preferred

Direct API

Where a system exposes a documented interface, that is what the operator uses. It is faster, it fails loudly rather than silently, and its permissions can be scoped precisely to the records the queue actually touches.

  • Scoped credentials issued to the operator alone, never shared with a person
  • Read-only during Observe and Capture; write access granted only at supervised live run
  • Rate limited on our side so the operator can never overwhelm a production system
  • Failures surface as explicit errors and route the case to a person
Where no API exists

The browser, signed in as itself

A great deal of real work happens in portals nobody ever built an integration for: government filing sites, bank portals, insurer systems, supplier extranets. The operator signs in and works them the way your staff do.

  • Its own named account with its own password, provisioned like a new employee
  • Reads the page by meaning rather than by fixed selectors, so a layout change does not break it
  • Every session recorded as part of the evidence trail
  • Never uses a human colleague's login, so the audit log stays truthful
Documents

Mail and file stores

Most queues start with something arriving as an attachment or landing in a folder. The operator monitors the specific mailbox or location in scope and nothing else.

  • A dedicated mailbox or a scoped folder, not a person's inbox
  • Reads attachments in the formats your queue actually receives, including scans
  • Files output back to the location your process already uses
  • Retention and deletion follow the policy you set, not a default
Databases

Direct data access, read-mostly

Where a reporting or reconciliation queue needs to read at volume, direct database access is sometimes the only sensible route. We treat write access here as exceptional rather than normal.

  • A dedicated database user with read permissions on the specific tables in scope
  • Write access only where the workflow genuinely requires it and policy permits
  • Queries reviewed with your DBA before the operator ever runs them live
  • Never granted broad schema access "to make things easier"

The system categories we work alongside.

Listed by what the system does rather than by vendor name. We do not claim certified partnerships, and we would rather tell you honestly during the audit that a particular system is awkward than discover it at week five.

Finance and accounting

General ledger, accounts payable and receivable, expense systems and the reporting layer on top of them. Usually the first system in scope because finance queues are where most engagements start.

ERP and operations

The system of record for orders, inventory, projects and production. Typically read-heavy for the operator, with writes limited to the specific transaction types the queue owns.

CRM and customer systems

Accounts, contacts, opportunities, cases and the history attached to them. Most often used as context the operator reads rather than a system it writes to.

Service desk and ticketing

Queues, tickets, knowledge bases and resolution history. The knowledge base and past resolutions are usually part of the tuning material, not just a system to act on.

Document and contract stores

Where the agreements, templates and signed copies live. Read access for precedent and playbook material; filing an executed document is a human action.

HR and payroll

Approached carefully and usually last, because the data is sensitive and the approval chains are strict. Scope is normally narrower here than anywhere else.

Portals with no interface

Regulator filing sites, bank portals, insurer systems, supplier extranets, customs and logistics portals. This is where the browser route earns its place.

Reporting and analytics

Warehouses, BI layers and the spreadsheets that quietly sit beside them. Often both a source the operator reads and a destination it writes a prepared pack into.

How access is actually granted.

Permissions widen slowly and only after the operator has demonstrated it decides the way your team does. It never starts with write access to anything.

01

Inventory

During Observe we list every system the queue genuinely touches, including the ones people forget because they only open them on a Friday.

02

Choose the method

For each system we establish whether an interface exists, and default to it. Browser access is a considered choice, not a shortcut.

03

Provision

Your IT lead issues the operator its own named account with permissions scoped to the queue. Nothing is shared with a human account.

04

Read-only first

Through Observe, Capture and Codify the operator can read and nothing else. It cannot change anything while we are still learning how you decide.

05

Test against history

Before any write access, the operator is scored on historical cases where we already know what your team decided.

06

Write, supervised

Write access is granted for the supervised live run, still behind Workflow Guard and still with your team holding release on anything irreversible.

Bring the awkward system.

Every organisation has one: the portal with no interface, the legacy system nobody will touch, the spreadsheet that is somehow load-bearing. Those are usually the most interesting part of the conversation, and often the reason the queue was never automated before.