OpsGrid · Security & Architecture · Dynamics 365 Business Central required · Active Beta

Your security questions about OpsGrid and Business Central, answered.

How it connects to BC. What it reads. What it never writes without explicit approval. The engine, the permission model, the audit trail — everything your IT and security teams need before sign-off.

BC Read LangGraph Teams Approve BC Write
Book a technical review session →
Technical architecture

Three components. One data flow. No black boxes.

OpsGrid is built on open standards. Every layer is inspectable during onboarding.

Engine
LangGraph (Apache 2.0)
Open-source orchestration framework. The graph structure that defines OpsGrid's decision flows — which BC entities it reads, which thresholds trigger signals, which LLM calls it makes — is fully inspectable. Every node and state transition is logged. Nothing runs as a black box.
ERP connection
BC APIs (official Microsoft)
OpsGrid connects via Dynamics 365 Business Central's official API layer using a service account your BC admin provisions with appropriate permissions — including write access for specific approved operations. Connection tokens are created following documented Microsoft guidelines. OpsGrid never requests admin or global access. Permission scope is defined during setup and does not change without admin action.
Decision interface
MS Teams Chat Framework
Decision cards are delivered and actioned inside Microsoft Teams using the official Teams Chat Framework. No new app install for end users — they see OpsGrid cards in their existing Teams channels. The webhook is provisioned by your Teams admin during Week 2 of deployment.
Deployment process

Three admin steps. Three weeks. No middleware to maintain.

Enable BC APIs — create connect tokens
Your BC admin enables the API layer, creates a service account with permission sets scoped to OpsGrid's needs — read access to monitored entities, write access for human-approved operations (draft POs, transfer orders, reschedules) — and generates connect tokens following standard Microsoft BC documentation. OpsGrid does not handle credentials — tokens are provisioned entirely within your environment.
Deploy MS Teams OpsGrid Chat
Your Teams admin provisions the OpsGrid webhook and configures the channels where decision cards will appear. Users don't install anything — they receive cards in their existing Teams workspace. Notification scope is configurable per decision type and routing rule.
Deploy the OpsGrid Engine
OpsGrid engine deployment completes the connection: LangGraph graph configured for your signal types and thresholds, routing rules set per decision type and decision owner, SLA windows configured, escalation chains defined. Engine can run on your infrastructure (self-hosted) or as a managed deployment — your choice, scoped in Week 1.
Security questions

What IT and security teams ask before sign-off

Two separate questions. Storage: OpsGrid reads from Business Central at query time using a service account your admin configures. Nothing is copied to an external data store. LLM processing: when OpsGrid generates a recommendation or answer, it sends the relevant BC data chunks to an LLM. If you use an external LLM API (OpenAI, Azure OpenAI, Anthropic — via API keys you provide), the provider processes those chunks on their servers. Standard API terms bar providers from retaining or training on your data. If on-premises inference is a hard requirement, OpsGrid supports self-hosted LLMs: data stays entirely within your environment.
No. OpsGrid does not execute autonomously. The service account is configured by your BC admin with write permissions scoped to the specific actions OpsGrid can perform — draft POs, transfer orders, production reschedules. Every write is triggered explicitly by a named decision owner approving in Teams. The governance constraint is: zero writes without a human approval event. This is not a policy setting that can be toggled — it is baked into how OpsGrid is deployed.
During setup, your BC admin creates a service account with permissions scoped to what OpsGrid needs: read access to the entities it monitors (production orders, purchase orders, inventory ledger entries, sales orders, general ledger budget entries) and write access for the specific operations it performs when a human approves — draft purchase orders, transfer orders, production reschedules. All scoped following standard BC permission set procedures. OpsGrid does not request admin or global access.
Yes. Every signal detected, every card routed, every approval or rejection, every BC write — all logged with timestamp, actor, BC data snapshot at decision time, and outcome. The audit trail is accessible via the OpsGrid dashboard and exportable. For regulated environments: the trail satisfies standard operational control documentation requirements. OpsGrid does not delete or modify audit records.
LangGraph is open source (Apache 2.0). The graph structure that defines OpsGrid's decision flows is inspectable — every node, edge, and state transition is logged. During onboarding, we walk your IT team through the engine configuration: which BC entities it reads, which thresholds trigger signals, which LLM calls it makes, and what the approval gate enforces before any write. Nothing runs as a black box.
OpsGrid operates within the BC permission model, not around it. The service account respects whatever data visibility rules your BC admin configures — if a company or dimension is excluded from the service account's scope, OpsGrid cannot see it. Write access is scoped to specific actions (draft PO, transfer order) and cannot post to entities outside that scope. OpsGrid cannot elevate its own permissions.
Technical review · Active Beta

Walk through the OpsGrid architecture with your IT team before you commit

We run a technical review session: engine configuration, BC permission scope, data flow, audit trail. Your team sees exactly what OpsGrid does and doesn't do before any BC admin work begins.

Book a technical review →