Connect FactoryTalk Data Logger to Copilot
You're building a Copilot agent that should answer questions about production equipment — and the data lives in FactoryTalk Data Logger, writing to SQL Express databases on HMI workstations across the plant floor. Unlike a dedicated historian server, Data Logger scatters data across multiple workstation-hosted SQL instances, each with its own schema, its own network location, and no REST interface. Getting a Copilot agent to query live equipment data from there requires solving problems that don't appear in any Copilot Studio documentation.
The barriers below are what makes this integration harder than it looks.
Why it's hard
Seven reasons connecting a Copilot agent to FactoryTalk Data Logger is harder than expected.
Copilot agents call HTTP — Data Logger writes to SQL Express with no REST API
Copilot Studio agents retrieve data through Custom Connectors making HTTP calls. FactoryTalk Data Logger has no REST or HTTP interface — it writes tag values to a SQL Express database on the HMI workstation. Reaching that data from a Copilot agent requires an intermediary that bridges SQL Express to an HTTP endpoint accessible from Microsoft's cloud.
SQL Express is on HMI workstations — Copilot Studio calls from Microsoft's cloud
HMI workstations sit on the plant floor network and are air-gapped or heavily firewalled from the internet. Microsoft's Power Platform infrastructure makes outbound HTTP calls from the cloud — it has no path to SQL Express running on a production HMI. Making that connection would require exposing plant floor machines to internet traffic, which is a security risk most OT teams won't accept.
Two-table schema requires joins the agent can't perform
Data Logger stores tag definitions in one table and logged values in another. Returning a meaningful result — a tag name alongside its value and timestamp — requires joining both tables. An agent querying either table directly gets either a list of tag definitions with no values, or a column of numeric IDs alongside values with no tag context. The join logic has to live in the integration layer.
SQL Express 10 GB cap means history may be incomplete
SQL Express has a 10 GB database size cap. Once reached, Data Logger silently stops writing new records — old data remains but recent data is missing. An agent querying a full SQL Express database gets incomplete history with no indication of where the data ends. Without monitoring and rollover management, any historical query the agent makes may return an incomplete picture.
Multiple Data Logger instances mean no unified data surface
Distributed plants run one Data Logger instance per HMI workstation or per PLC — each writing to its own SQL Express database on its own machine. An agent that needs to answer questions across the plant — comparing equipment performance, for example — has no single endpoint to query. Each instance is a separate connection with its own schema, its own location, and potentially its own version.
Power Platform Custom Connectors require admin approval
Any Copilot Studio agent accessing external data needs a Custom Connector with an approved OpenAPI spec. In enterprise Microsoft 365 environments, connectors that touch OT-adjacent endpoints go through Power Platform admin review, security assessment, and sometimes change management. The approval timeline regularly runs to weeks before a connector reaches production use.
High-frequency logging produces enormous row counts
Data Logger is typically configured to log at high frequencies — every second or faster per tag. A history query for even a few hours returns tens of thousands of rows. Action responses in Copilot Studio have payload size limits — raw Data Logger query results will breach them. The endpoint serving the agent must aggregate before responding, which requires logic the raw SQL Express database doesn't provide.
What teams usually try
REST wrapper on the HMI network querying SQL Express
Build a service on a machine with SQL Express access. It queries Data Logger tables, joins tag and value data, and exposes a REST API. Define a Custom Connector against this endpoint.
The catch: The wrapper runs on plant floor infrastructure and needs a path to Microsoft's cloud — a security decision most OT teams won't approve. Each Data Logger instance is a separate connection to maintain. SQL Express caps and schema quirks have to be handled in the wrapper code.
ETL from SQL Express to a cloud database
Run a scheduled extract from each Data Logger SQL Express instance to Azure SQL or a cloud database. Point the Custom Connector at the cloud database. No plant floor network path from Copilot's side.
The catch: The agent answers questions about stale snapshots. ETL pipelines for multiple Data Logger instances add infrastructure complexity. Schema mapping between the two-table Data Logger schema and the cloud target requires design and ongoing maintenance.
Flat-file exports to SharePoint
Export Data Logger data periodically to CSV files in SharePoint. Configure the Copilot agent to read those files as its knowledge source for equipment questions.
The catch: High-frequency Data Logger exports produce very large files that SharePoint-based agent search can't handle effectively. The agent answers questions about past snapshots. Real-time equipment questions can't be answered accurately.
How TrendOps solves it
TrendOps Edge connects to FactoryTalk Data Logger on the plant network — joining tag and value tables, handling SQL Express connections, and normalising data across all instances — and forwards structured, context-rich data to TrendOps Platform in the cloud. Your Copilot Studio agent calls TrendOps Web API through a single Custom Connector. No SQL Express on any cloud component, no HMI workstation access from Microsoft's cloud, no two-table join logic in the action layer.
The agent calls TrendOps Web API — a cloud-accessible HTTPS endpoint. No SQL Express driver, no HMI workstation connection, no plant floor network path from Microsoft's infrastructure.
TrendOps Edge performs the tag/value join on the OT side. Action responses include tag names and values together — the agent doesn't receive raw numeric IDs it has to resolve separately.
TrendOps normalises data from all connected Data Logger instances into a single platform. The agent queries across HMI workstations through one endpoint — no separate connector per machine.
TrendOps handles aggregation server-side. Action responses return interval-based summaries — not tens of thousands of high-frequency Data Logger rows that overflow payload limits.
TrendOps Edge reads Data Logger continuously. The agent returns current equipment values — not a snapshot from an export that ran on a schedule.
TrendOps Edge pushes data out over a single outbound MQTT connection. No inbound path from Microsoft's cloud to HMI workstations. The Copilot agent's calls never touch the plant floor network.
What you end up with
No connection to HMI workstations — the agent calls a cloud API, not SQL Express on the plant floor.
Current equipment values — the agent knows what's happening right now.
Tag and value tables joined — the agent receives named, structured responses.
One connector, every OT source — not limited to Data Logger.
Don't want to build your own AI agent integration?
TrendGuru — TrendOps's built-in AI agent — already has access to your plant data. Ask questions about your FactoryTalk Data Logger equipment in plain language and get answers instantly, deployed directly in Microsoft Teams. No Custom Connector to configure, no OpenAPI spec to write, no Power Platform admin approval to wait for.
Learn about TrendGuru →Your Copilot agent shouldn't need direct access to HMI workstations to answer a question about equipment data
TrendOps gives your Copilot agent a clean, cloud-accessible API for FactoryTalk Data Logger — joined, aggregated, and available without touching the plant floor network.
Book a Demo