Clio Operate (formerly Sharedo)
A pre-built, two-surface integration that lets Clio Operate read and write to Aderant in production — with credentials kept on-premises, transactions logged end-to-end, and each Aderant capability used for what it does best.
Clio Operate reads from Aderant and writes back to it in production. Users get one search across both systems. Workflows push data into Aderant without anyone writing custom code.
Aderant credentials never leave your network. The gateway lives inside it. Every write goes through an auth layer we issue, and every call is logged.
Reads run off SQL views on the Aderant database you already manage. Writes go through the ClientMatter API your team already uses. The integration sits alongside both, not in place of them.
The heavy lifting is choosing which SQL views to expose, whitelisting one IP, and signing off UAT. The code is already written.
Every request is logged with who, what, when and how it ended up. Admins can see the live log inside Clio Operate. Your SIEM can ingest the same files off disk.
It's Node.js in front of SQL Server. Any competent in-house team can pick it up if they need to. You get the source. We're around if you'd rather we kept running it.
Aderant gives you a perfectly good API for writes, and a perfectly good database for reads. Forcing one to do the other's job is where most integrations get expensive. So we built two small services, each pointed at the part of Aderant that's good at the job.
A thin Alterspective REST proxy sits in front of Aderant's out-of-the-box ClientMatter API and handles every create / update path — the API's intended purpose.
AltAderantClient, AltAderantMatter and AltAderantMatterParty.Surface: aderant-rest.alterspective.io — status: Delivered
A Node.js gateway over the Aderant SQL database that auto-discovers views and stored procedures and exposes them as REST endpoints — covering what the Aderant API deliberately doesn't: list, search and discovery.
Surface: aderant.alterspective.io — status: Delivered · Conflict search: Next
The Aderant OOB API was designed for writes, not for list or search. Forcing reads through it means N+1 lookups and no fuzzy matching. The database, conversely, is rich for reads but not the right place to write. By splitting the surfaces we use each Aderant capability for what it does best — and we wrap both in Clio Operate-friendly proxies that handle authentication, logging and observability uniformly.
This Aderant integration is one piece of Alterspective's broader File Opening Solution for Clio Operate — an end-to-end workflow covering new-matter intake, party capture, conflict checking, and downstream practice-management write-back. The Aderant CRUD and DB proxies provide the practice-management leg of that workflow.
Browse the full design at The File Opening Design Explorer: fileopen.alterspective.com.au/explore →
Legal teams working across Clio Operate for matter management and Aderant for practice/financial data had to switch between systems to search for clients, matters, and parties — losing time and context on every lookup.
Users searched Clio Operate and Aderant separately, duplicating effort and missing cross-system matches.
Aderant's official API only supports creating and updating records — it cannot search or list data.
Without a single point of search, teams re-key contact and matter details, miss cross-system matches, and create duplicates that have to be reconciled later.
We do use the Aderant API — it's the right surface for writes, and that's exactly what we use it for via our authenticated CRUD proxy. The limitation is read-side: every Aderant read endpoint requires a known entity ID. You cannot list, search, or check whether an entity exists without already having its ID. So we use the Aderant API for the writes it's designed for, and pair it with our DB Proxy for the list, search and discovery the API deliberately doesn't cover.
All Aderant read endpoints require a known entity ID as input. There is no way to list entities, search by name, or check if a record already exists. This means you cannot verify whether a client or matter exists in Aderant before creating one — making duplicate prevention, conflict checking, and unified search impossible via the official API alone.
| Capability | Aderant API | Query Service | Alterspective |
|---|---|---|---|
| Search / list records | No — requires known ID | Unofficial | Yes |
| Check if entity exists | No | Unofficial | Yes |
| Complex search logic | No | Limited OData | Full SQL |
| Phonetic / fuzzy matching | No | No | Yes |
| Write / create / update | Yes — native | No | Yes — via CRUD proxy |
| Officially supported | Yes | No SLA | Alterspective |
| Additional annual licence | Per Aderant pricing | — | $0 |
Used for all writes via our authenticated CRUD proxy — the API's intended purpose. Not used for reads: every read endpoint requires a known entity ID, so it cannot list, search, or check existence before writing.
"The ClientMatter API does not support getting lists of clients or matters." — Aderant
Too risky for production. Unofficial, undocumented, no SLA, no guaranteed backwards compatibility. Suitable for evaluation only.
Selected for all reads. Full query flexibility, advanced search capabilities, and proven in production via our POC.
Reads → Direct database via Alterspective Gateway (search, list, conflict check, entity lookup)
Writes → Aderant API via Clio Operate workflow actions (create, update — the API's intended purpose)
A lightweight Node.js gateway sits between the Aderant SQL database and Clio Operate's proxy linked services. Data flows through clearly separated on-premises and cloud environments.
flowchart LR
subgraph ONPREM["CLIENT ON-PREMISES"]
direction LR
subgraph ADERANT_ENV["Aderant Environment"]
A["fa:fa-database Aderant\nDatabase\n(SQL Server)"]
B["fa:fa-layer-group SQL Views\n& Stored Procs"]
end
subgraph GW_ENV["Alterspective Gateway"]
C["fa:fa-server Node.js\nGateway API"]
D["fa:fa-heartbeat PM2\nProcess Manager"]
end
end
subgraph CLOUD["CLIO OPERATE CLOUD"]
direction LR
E["fa:fa-plug Proxy\nLinked Service"]
F["fa:fa-cube ODS\nData Store"]
G["fa:fa-search Unified Search\nWidget"]
end
A --> B --> C
D -.->|monitors| C
C -->|HTTPS| E --> F --> G
style ONPREM fill:#fdf6ec,stroke:#c0862b,stroke-width:2px,color:#17232D
style ADERANT_ENV fill:#E5EEEF,stroke:#075156,stroke-width:2px,color:#17232D
style GW_ENV fill:#E5EEEF,stroke:#2C8248,stroke-width:2px,color:#17232D
style CLOUD fill:#e8f4f5,stroke:#075156,stroke-width:2px,color:#17232D
style A fill:#075156,color:#fff,stroke:#064045
style B fill:#075156,color:#fff,stroke:#064045
style C fill:#2C8248,color:#fff,stroke:#246a3d
style D fill:#2C8248,color:#fff,stroke:#246a3d
style E fill:#075156,color:#fff,stroke:#064045
style F fill:#075156,color:#fff,stroke:#064045
style G fill:#ABDD65,color:#17232D,stroke:#7aa832,stroke-width:2px
Managed by: Client IT
Built by: Alterspective | Hosted by: Client
Managed by: Clio Operate SaaS | Configured by: Alterspective
The Gateway API is the single crossing point between the client's on-premises network and Clio Operate's cloud. The client whitelists the Gateway API IP in Clio Operate, and all data flows over HTTPS. No direct database access leaves the client's network.
The Gateway API automatically discovers every SQL view and stored procedure exposed through the linked database. Add a new view or stored procedure on the SQL instance — it is immediately available as a new API endpoint in Clio Operate. No code changes. No redeployment. No downtime.
The Gateway periodically introspects the SQL schema. New views and stored procedures are detected and registered as API endpoints automatically.
No code changes, no container rebuilds, no service restarts. The DBA adds a view, and it flows through to Clio Operate in minutes.
Need financial data? Add a view. Time entries? Add a view. Conflict parties? Add a view. Every view becomes a searchable, queryable surface in Clio Operate.
Clients can independently monitor service health, validate connectivity, and test search results — without contacting Alterspective. Full observability is built in from day one.
A dedicated portal built into Clio Operate displays live schema information, validates database connectivity, and allows administrators to run test searches — all from within the Clio Operate UI.
Every API request is logged with full request/response payloads, execution times, and error details. Logs are accessible via the diagnostics UI for independent troubleshooting.
PM2 provides automatic restart on failure, memory monitoring, and process health metrics. The Gateway's /health endpoint enables integration with any monitoring stack.
The Unified Search uses a multi-layer scoring model executed entirely in SQL for maximum performance.
flowchart TD
Q["User types search query"]
Q --> SP["Stored Procedure executes"]
SP --> L1["Layer 1: Direct Match\nExact name / reference"]
SP --> L2["Layer 2: Partial Match\nContains / starts with"]
SP --> L3["Layer 3: Phonetic Match\nSimilar-sounding names"]
L1 --> RANK["Weighted Ranking Engine"]
L2 --> RANK
L3 --> RANK
RANK --> MERGE["Merge with Clio Operate ODS\nDeduplicate"]
MERGE --> TOP["Return ranked results\nwith source badges"]
style Q fill:#075156,color:#fff,stroke:#064045
style SP fill:#2C8248,color:#fff,stroke:#246a3d
style L1 fill:#075156,color:#fff,stroke:#064045
style L2 fill:#0a6b72,color:#fff,stroke:#075156
style L3 fill:#E5EEEF,color:#17232D,stroke:#075156
style RANK fill:#ABDD65,color:#17232D,stroke:#7aa832,stroke-width:2px
style MERGE fill:#2C8248,color:#fff,stroke:#246a3d
style TOP fill:#075156,color:#fff,stroke:#064045
Searching “Smith” across both systems returned 8 results from Clio Operate and 198 from Aderant — merged and deduplicated to 191 unique results in under one second. Each result displayed with name, contact details (email, phone, address), and a clear source badge.
Users search once from within Clio Operate. Results from both Clio Operate and Aderant appear in a single, ranked list with clear source badges and contextual actions.
sequenceDiagram
participant User as Legal Staff
participant Widget as Unified Search
participant Clio Operate as Clio Operate ODS
participant Proxy as Proxy Service
participant API as Gateway API
participant DB as Aderant DB
User->>Widget: Type search query
Widget->>Clio Operate: Search Clio Operate contacts
Widget->>Proxy: Search Aderant contacts
Proxy->>API: GET /search?q=...
API->>DB: Execute stored procedure
DB-->>API: Ranked results (JSON)
API-->>Proxy: Structured response
Proxy-->>Widget: Aderant results
Clio Operate-->>Widget: Clio Operate results
Widget->>Widget: Merge & rank
Widget-->>User: Combined results with source badges
~3–5 minutes per lookup
~5 seconds per lookup
The POC validated every success criterion — and came in under budget.
Production-ready Clio Operate IDE components shipping with this integration — configurable widgets for portals and dashboards, plus workflow actions that read from and write back to Aderant.
AlterspectiveWidgets.AltAderantDBProxyClientSearch
Searches for clients directly in the Aderant database via the Gateway API. Configurable portal widget with parameter introspection.
AlterspectiveWidgets.AltAderantDBProxyNameSearch
Person / Organisation name search across Aderant entities with weighted, partial, and phonetic ranking.
AlterspectiveWidgets.AltAderantDBProxyLogs
Operational view of Gateway API transaction and error logs — live diagnostics surface inside Clio Operate.
AlterspectiveWidgets.AltAderantClientPmsDetails
Reads ud-aderant-client-id from the current work item and displays the full Aderant client record (code, status, opened date, sub-resource URLs).
AlterspectiveWidgets.AltAderantDBProxy
Shared designer host providing configuration scaffolding consumed by the Aderant DB Proxy widget family.
AltAderantClient — Alterspective Aderant integration
Creates or updates a client record in Aderant from a Clio Operate workflow. Output is the JSON response from the Aderant API.
AltAderantMatter — Alterspective Aderant integration
Creates or updates a matter in Aderant via the Alterspective REST API proxy — the write-back path, no code required.
AltAderantMatterParty — Alterspective integration
Adds matter party information to the workflow context by matter number and party role — the building block for automated conflict checking.
Answered here so the conversation can move on quickly.
Inside your network. The SQL account and the Aderant ClientMatter API account are held only by the on-prem gateway and CRUD proxy. Clio Operate calls in with an API key we issue and that the proxy validates.
Nowhere, unless someone asks for it. Aderant data leaves your network only in response to an authenticated request from Clio Operate, over HTTPS, through one whitelisted IP. There's no bulk replication and no third-party data store.
Every read and every write. Timestamp, source IP, endpoint, parameters, outcome. Admins see it live inside Clio Operate through the logs widget, and your SIEM can pick up the same records straight off disk.
Only what you grant. The DB proxy uses a SQL account scoped to whichever views and stored procedures you choose to expose. The CRUD proxy reuses the Aderant API account you already have for writes. No new privileged accounts.
About as hard as updating a firewall rule. Revoke the whitelisted IP and traffic stops. Nothing in Aderant changes, nothing in Clio Operate is left behind, and there's no migration to unwind.
The Node.js / TypeScript source, the SQL scripts, the Clio Operate widget and workflow-action bundles, and the operational runbooks. No compiled-only binaries. Nothing that needs us to be in the room for you to keep it running.
No hidden assumptions about who'll be doing the work.
| Component | Runs where | Operated by | Cost driver |
|---|---|---|---|
| Aderant SQL views & stored procedures | Client's Aderant SQL Server | Client DBA | Runs on your existing Aderant database |
| Gateway (DB Proxy) | Client's Clio Operate-dev server (on-prem / private cloud) | Client infra team (Alterspective supports) | One small VM / container, Node.js runtime |
| CRUD proxy | Same host as Gateway | Client infra team (Alterspective supports) | Uses your existing Aderant ClientMatter API |
| Clio Operate widgets & workflow actions | Clio Operate SaaS | Alterspective + client admins | Runs in your existing Clio Operate tenant |
| Observability dashboards | Inside Clio Operate (widget) + on-host log files | Client admins / SIEM team | No additional tooling required |
We deliver, harden and walk you through UAT, then stay close for a defined window after go-live. After that, anyone with Node.js and SQL Server in their team can keep it running. We're usually on retainer for new features and the occasional incident, but you don't need us in the loop day-to-day.
A clear, phased plan to move from validated POC to production-grade deployment with full observability.
All proof points met. Architecture validated. Search ranking operational.
Error logging, request tracing, monitoring dashboards, diagnostics UI for independent health checks.
Unified Search widget installed and tested against Aderant data in a controlled environment.
SQL instance, Gateway API, proxy services, whitelisting, and Unified Search deployed to production.
The same two surfaces underpin a longer arc — matter records that exist in both systems and stay in step. Each tier is independently useful, independently priced, and builds on the last.
Search Aderant matters from inside Clio Operate, preview the header and parties, click Import. A Clio Operate matter is created with all the details, ODS participants attached, and both Aderant IDs stamped onto the work item for future link-up.
A "Refresh from Aderant" button on any imported matter pulls the latest values. Where the two sides disagree, the user sees a field-level diff and chooses what to keep. Nothing is overwritten silently.
A small on-prem service watches every linked matter. It pulls changes from Aderant on a schedule, applies per-field rules about which side wins, and queues anything that needs a human decision for an admin to review.
SQL Change Tracking on the Aderant side and Clio Operate webhooks on the other. Updates flow each way in under a minute. A mapping editor lets admins set the source of truth field-by-field per work-type, without touching code.
Each tier solves a real problem on its own. Most firms only need Tier 1 or Tier 2 to get the day-one benefit — users stop re-keying matters between systems. Tiers 3 and 4 are for firms that want the two systems to feel like one. Buy what you need now; upgrade when the case is clear.
The same architecture opens up adjacent use cases — the next one we're prioritising is automated conflict checking.
flowchart TB
subgraph READ["Read Path (Proven)"]
direction LR
R1["Aderant DB"] --> R2["SQL Views"] --> R3["Gateway API"] --> R4["Clio Operate"]
end
subgraph WRITE["Write Path (Future)"]
direction LR
W1["Clio Operate"] --> W2["Workflow\nActions"] --> W3["ClientMatter\nAPI"] --> W4["Aderant"]
end
subgraph CONFLICT["Conflict Check (Exploring)"]
direction LR
C1["New Matter\nCreated"] --> C2["Conflict Check\nWorkflow Action"] --> C3["Gateway API\nParty Search"] --> C4["Results &\nAlerts"]
end
style READ fill:#E5EEEF,stroke:#2C8248,stroke-width:2px,color:#17232D
style WRITE fill:#E5EEEF,stroke:#075156,stroke-width:2px,color:#17232D
style CONFLICT fill:#E5EEEF,stroke:#ABDD65,stroke-width:2px,color:#17232D
style R1 fill:#075156,color:#fff
style R2 fill:#075156,color:#fff
style R3 fill:#2C8248,color:#fff
style R4 fill:#ABDD65,color:#17232D,stroke:#7aa832
style W1 fill:#ABDD65,color:#17232D,stroke:#7aa832
style W2 fill:#2C8248,color:#fff
style W3 fill:#075156,color:#fff
style W4 fill:#075156,color:#fff
style C1 fill:#ABDD65,color:#17232D,stroke:#7aa832
style C2 fill:#2C8248,color:#fff
style C3 fill:#075156,color:#fff
style C4 fill:#075156,color:#fff
Three Clio Operate workflow actions — Client, Matter, and Matter Party — already consume the authenticated CRUD proxy, letting developers push data back to Aderant from visual workflows with no code. Expanding coverage to additional Aderant entities is the next step.
The authenticated REST proxy wrapping Aderant's OOB ClientMatter API is now live — one consistent surface for all writes, with Alterspective-issued authentication so Clio Operate workflows never hold Aderant credentials directly.
We are exploring the use of this same direct-database integration approach to power automated conflict checking within Clio Operate. When a new matter or party is created, a workflow action would query Aderant's client and matter party data through the Gateway API — leveraging the same weighted and phonetic search — to surface potential conflicts before engagement begins.
The proven search ranking model (direct, partial, phonetic) is ideally suited to the fuzzy name-matching that conflict checks demand.
Discovery takes under two weeks. We agree which SQL views to expose, sort the network boundary, point the search at your own data so you can judge the ranking yourself, and write back a fixed-price plan to production.