For CIOs, CDOs & IT Leaders

Your data doesn't move. We build intelligence on top of where it already lives.

OpsGrid reads from Business Central using your existing BC credentials and permission model. Nothing is extracted to an external data store. QHub Wiki AI runs entirely on your own server. Both products are designed for organisations where data sovereignty is non-negotiable.

Request an architecture overview → See OpsGrid

Data architecture

What OpsGrid reads, where it reads it, and what it never touches.

How OpsGrid accesses Business Central

OpsGrid connects to your BC tenant using the BC API and the service account credentials you provide. It reads from the operational tables you configure — nothing more. Data is retrieved at query time to generate a decision or answer, then released. There is no persistent data copy, no ETL, and no external warehouse.

Write operations are strictly bounded. OpsGrid can only write to the specific action types you explicitly enable — and every write requires a human approval event in Teams before anything is committed to BC.

Architecture at a glance

  • Connects via BC API using credentials you provision
  • Reads from configured tables only — purchase, inventory, production, sales
  • Read-only by default; writes require explicit configuration and human approval
  • No data extracted to an external store — retrieval is query-time only
  • Teams integration via webhook — no additional infrastructure
  • All actions logged to an audit channel you specify

Integration model

Three integration points. All of them use infrastructure you already have.

OpsGrid is not a generic ERP middleware layer. It was built specifically for the BC schema and permission model, and connects to Teams using standard webhook infrastructure.

Business Central

BC-native integration

OpsGrid is built for the BC schema — not a generic ERP abstraction. It uses BC's API, respects your existing permission model, and works with the table structure BC already uses. No schema mapping, no custom connectors, no middleware.

Microsoft Teams

Teams via standard webhook

Decision cards and approval requests are delivered via Teams webhook. No new Teams apps, no additional licences, no changes to your Teams tenant configuration. Uses the notification and approval mechanisms Teams already provides.

QHub

Self-hosted, open source

QHub Wiki AI is fully self-hosted: WikiJS, Qdrant vector store, and the LLM connector all run on your own server. Apache 2.0 licence. Auditable codebase. No vendor-managed infrastructure involved in document retrieval or query answering.

What you control

Every configuration decision is yours.

OpsGrid is not a black box. You define the scope, the permission boundaries, the routing logic, and what gets logged. Your security team can audit every layer.

BC credentials and permissions

You provision the service account OpsGrid uses. You set the BC permissions. OpsGrid operates only within the scope you define — it cannot escalate its own access.

Which decision types surface and to whom

You configure which operational events trigger a decision card, which Teams channels receive them, and which users or roles see each type. No decisions surface outside the channels you specify.

Approval routing by decision type and value

High-value decisions can be routed to senior approvers. Routine decisions can be delegated. Escalation paths are defined in configuration, not hardcoded.

Audit log — every action, every outcome

Every decision surfaced, every approval or rejection, every BC write — logged to the audit channel you designate. Exportable. Retainable under your own data retention policies.

Compliance and sovereignty

Built for environments where data governance isn't optional.

Four commitments to your data governance team

For organisations where a CIO or CDO must sign off on any AI deployment, these are the guarantees that matter.

Human-in-the-loop by design

$0 in BC writes without explicit human approval. The approval event is a prerequisite, not a courtesy — the write pathway is blocked until a named user approves in Teams.

LLM sees retrieved chunks only

The language model receives only the specific data chunks retrieved to answer a query. It has no persistent access to your BC data and does not store or train on your data between sessions.

Self-hosted option available

QHub runs entirely on your infrastructure. If full on-premises deployment is a requirement for OpsGrid, talk to us — we can scope an architecture that keeps everything inside your perimeter.

Open source and auditable

QHub is Apache 2.0. The full codebase is auditable by your security team. No proprietary black boxes in the document retrieval or query answering pipeline.

Common questions

What CIOs and IT leaders ask us first.

Does any data leave our Business Central environment?
No. OpsGrid reads from Business Central using your existing BC API credentials. It does not extract or copy data to an external data store. Data is retrieved at query time, used to generate a decision or answer, and not persisted outside of BC.
What Business Central permissions does OpsGrid require?
OpsGrid uses your existing BC permission model. It requires read access to the operational tables you configure — typically purchase, inventory, production, and sales. Write access is scoped only to the specific action types you enable and requires explicit human approval before any BC write occurs.
Can we run everything on our own servers?
Yes. QHub Wiki AI is fully self-hosted — WikiJS, Qdrant vector store, and the LLM connector all run on your own infrastructure. OpsGrid is a managed service but reads only from your BC tenant. If full on-premises deployment is a requirement, talk to us about the architecture options.
What LLMs does it use and do they see our data?
OpsGrid uses an LLM to generate recommendations and natural language answers. The LLM receives only the retrieved data chunks necessary to answer the query — it does not have persistent access to your BC data and does not store or train on your data. The LLM provider can be configured to use a model hosted within your own environment if required.
How does it integrate with our existing Teams setup?
OpsGrid connects to your existing Teams tenant using a standard webhook. No new Teams infrastructure is required. You specify which channels receive which decision types during configuration. The integration uses Teams' existing notification and approval mechanisms.

From our insights

See all insights →
Pillar Guide
How to unify ERP, CRM, and operations data (without ripping everything out)
The real cost of fragmented data isn't the gap — it's the decisions made without the full picture. This guide covers integration patterns that work without a rip-and-replace.
Read → Article
We stopped asking executives to find their reports. We took the reports to them.
Deploying Apache Superset for a manufacturer meant rethinking delivery, not just dashboards. Here's how push-based BI changed adoption rates overnight.
Read → Article
Why your BI implementation will fail — 4 pitfalls we've seen firsthand
Most BI projects fail not because of the tool, but because of the four things that happen before anyone opens a dashboard. We've seen each one kill a deployment.
Read →

Talk to us about your architecture requirements.

We walk through your BC environment, data governance constraints, and Teams setup — and map exactly what deployment looks like for your organisation.

Request an architecture overview →
Not the right role? For Ops Heads & Plant Managers — how OpsGrid works day to day → For CEOs & MDs — ROI and time to value →