● How it works

Four steps from many systems to one answer.

Vorkar is a diagnosis layer, not another silo. It reads your systems where they already live, relates the same record across all of them, enforces what may reach the model, and answers in plain English — always with its sources.

GUIDED FLOW · connect → ask → answer
1 Connect the systems
SalesforceREST
Legacy billingSOAP
2 Ask in plain English
3 Vorkar reads across both systems
02:13:58Salesforce → billing sync · order=SO-4471
02:14:02ERROR 401 credential_expired — billing app
02:14:073 orders held pending billing sync
4 Get a sourced answer
Root cause found

SO-4471 stopped between Salesforce and the billing app — the API credential expired at 02:14. 3 orders held.

Sources: Salesforce · Legacy billing · sync.log

The example we'll follow

An order that vanished: SO-4471

A customer's order was created in the CRM but never showed up in the ERP. Nobody knows why. Four teams, four systems, four tabs open. Here's how Vorkar answers it in one question.

01

Connect by protocol

You don't install a "Salesforce connector" and a "SAP connector" and wait for a vendor to ship the next one. You connect by protocol — SOAP, REST, SQL, NoSQL, document stores, local files, chat. Point Vorkar at an endpoint, give it credentials, and its schema is discovered automatically. The system appears on the canvas as a node orbiting Aura, with its live status, type badge (record / log / infra / knowledge) and security badge (OAuth 2.0, API key, DB user).

For SO-4471 that means four connections: the CRM (SOAP), the ERP (REST + SQL), the sync logs (NoSQL), and service health (infra). Adding a fifth system later is config, not code — and every question below starts working for it immediately.
Which platforms is the Vorkar agent available on? The Vorkar platform runs in any modern browser. The downloadable device agent — used to connect a machine's local files — is available for Windows and Linux today. A macOS agent is in progress. You don't need the agent to use Vorkar with cloud and networked systems; it's only for connecting a local machine.
02

Correlate through the entity map

The same business object has a different name and a different key in every system. An Opportunity in the CRM is a Sales Order in the ERP is an order_id in the logs. The entity map declares those relationships once, so Vorkar recognizes one real-world order across every system it touches — and can join related records on demand.

Vorkar resolves SO-4471 to the CRM Opportunity, looks for the matching ERP Sales Order (po_no = SO-4471), pulls every sync-log event carrying that order_id, and checks the infra health windows around those timestamps. Four systems, one timeline.
03

Govern what reaches the model

Before anything is sent to Aura, the record filter decides what's allowed. You author rules visually — grouped AND / OR / nested conditions over each system's real fields — at three explicit layers: per system+object ("from Salesforce Opportunities where Amount > 10,000"), per entity ("this customer, in every system it appears in"), or per field ("never send salary or cost, anywhere"). Matching data still flows through your pipeline and is still counted — only the model is blocked.

If a rule covers SO-4471, Vorkar tells you plainly: "1 record withheld from Aura by the record filter — processed, but its content was not sent to the LLM." Nothing is silently dropped, and nothing sensitive is silently shared. Values that differ per environment are supplied in Extensions, not baked into the rule.
04

Ask Aura — and get the evidence

Ask in plain English: a specific record, a broad "what's happening today?", or anything in between. Aura answers only from what the connectors actually returned, cites every system it queried, and lets you drill from the answer down to the raw record in the source system. If the data doesn't support a conclusion, it says so. A quiet day gets an honest quiet answer — never an invented summary.

Ask "Where is SO-4471?" → "Created in the CRM at 14:02. It never reached the ERP: the sync failed at 14:03 with an HTTPConnectionError (connection refused) while the ERP was in a known outage window from 14:00–14:31. 12 other orders failed the same way." — with the CRM record, the failed log line, and the health window all cited, one click away.
Then what

Answers you can act on — safely.

⚙️

Approval-gated actions

The only write path is propose → approve → execute → undo. Vorkar can rebuild those 13 failed orders — but only after a human approves, and every step is audited.

🧭

Environments & Extensions

Build once against Dev or UAT; deploy the same thing to Production. Credentials and environment-specific values are supplied in Extensions — production secrets never live on the canvas.

📈

Reports & drill-down

Every run is listed with its records in/out and status. Paste any id to trace its full parent → child → grandchild journey across systems.

Open the platform → See pricing