Ignition is very good at the plant floor: collecting data from PLCs, showing it to operators, and raising alarms. But the people who plan production, run finance, and answer to customers live in Microsoft 365. When the two don’t connect, someone ends up copying numbers from an HMI screen into a spreadsheet at the end of every shift.
Here are three patterns we use to close that gap, from the simplest to the most flexible.
1. SQL in the middle, Power BI on top
For reporting, the most reliable path is a SQL database between Ignition and Microsoft 365:
- Ignition writes to SQL through the Tag Historian (time-series values) and through transaction groups or scripts (event records such as batches, downtime, and counts).
- Power BI reads that database. If the database is on-premises, an on-premises data gateway lets the Power BI service refresh reports on a schedule.
This keeps the plant floor isolated: Microsoft 365 never talks to Ignition directly, and a reporting outage never touches production. Design the event tables for reporting from the start, with clear line, shift, product, and reason columns, rather than trying to reshape raw historian data later.
Use it for: OEE, downtime, production counts, and anything leadership reviews regularly.
2. Push events to Power Automate
Some things shouldn’t wait for a report: a line down longer than 15 minutes, a quality hold, a batch completed. For those, Ignition can call a Power Automate flow directly. A gateway script (a tag change script or a gateway event script) sends a small JSON payload over HTTPS with system.net.httpClient(), and the flow does the Microsoft 365 part: post to a Teams channel, add a row to a SharePoint list, or start an approval.
A few rules keep this safe and maintainable:
- Run it from the gateway, not from a client session, so events fire once regardless of who has a screen open.
- Keep payloads small and meaningful: what happened, where, when, and a link back to the Ignition screen.
- Treat the flow URL like a password. The HTTP-trigger URL grants access on its own; store it in configuration, not hard-coded across scripts, and rotate it if it leaks.
- Plan for licensing. The “When an HTTP request is received” trigger is a premium connector in Power Automate.
Use it for: notifications and workflows triggered by specific plant events.
3. Microsoft Graph for deeper integration
When you need Ignition to read from Microsoft 365, such as pulling a production schedule from a SharePoint list or writing documents to a library, call Microsoft Graph directly. Register an application in Entra ID with only the permissions it needs, authenticate with the client-credentials flow from a gateway script, and cache the token until it expires.
This is the most flexible option and also the one with the most to maintain: app registrations, secrets or certificates that expire, and permission reviews. Use it when the first two patterns can’t do the job.
Use it for: two-way integration, where the plant floor needs information that lives in Microsoft 365.
Choosing between them
Start with the reporting path. It answers most questions and carries the least risk. Add event pushes for the handful of things people genuinely need to know right away, and reach for Graph only when data has to flow back to the plant. In every case, keep the plant-floor network separated from the office and the internet, and let a controlled component (the gateway or a database) be the only bridge between them.