Integrations

What connects, and how far each one has actually been taken.

The overlay claim is only worth anything if it is checkable. So every item on this page is labelled with what it really is: part of the product, or work delivered for a specific site.

How to read this page.

In the product means it ships with AMS and is configured, not built. Delivered for a site means it exists and is running in production, but it was scoped and built for one customer against their systems. We can repeat it; we are not going to imply it is a switch.

Integration	Status	What it does
Microsoft Entra ID	In the product	OpenID Connect on web, MSAL on mobile, with cached offline sessions
Power BI Embedded	In the product	Reports embedded in AMS, authenticated server-side with per-session embed tokens
AMS REST hub	In the product	Documented OpenAPI surface, API-key secured, the same one the mobile app uses
Excel	In the product	Export from grids, and bulk import through the import workbench
SAP Plant Maintenance	Delivered for a site	Typed services against a production SAP BTP API Management surface
SSRS	Delivered for a site	Rendering into an existing report server against that site’s report definitions
MCP server for AI agents	Delivered for a site, read-only	Natural-language querying of the SAP maintenance estate

SAP Plant Maintenance

The deepest integration, and the clearest proof of the overlay claim.

At the smelting deployment, AMS runs against a production SAP PM estate through SAP BTP API Management. Eight typed SAP service and model pairs sit in the shared library, plus a work-order service on the mobile side, generated against 23 schema definitions taken from that customer’s own SAP API surface.

What is covered

PM work orders
Notifications
Functional locations
Equipment
Task lists
Work centres
Planner groups
Confirmations
Damage and cause catalogues

Ask in the technical walkthrough for the full endpoint list. We would rather show it against your own SAP surface than publish a list that does not match what you have.

What a technician sees

The work orders assigned to them, on the phone. They open an operation, do the work, and post a time confirmation straight back to SAP. The long text on the order is read and written in place, so notes survive.

Read this before you assume it applies to you.

This was built against one customer’s SAP configuration, their catalogues, their status profiles and their API gateway. It is a proven implementation rather than a connector you install. The right question is not “does AMS integrate with SAP” — it is “what would it take against ours”, and that is a scoping conversation.

We do not have a Maximo integration.

No AMS deployment currently runs against Maximo or any other CMMS. The architecture does not care — everything already goes over HTTP — but we are not going to describe a path we have not walked.

The AMS REST hub

Your systems can talk to AMS without asking us for an export.

AMS publishes its own REST hub with an OpenAPI description and API-key authentication. It is a small, stable surface rather than a generated catalogue of everything, and it is the same one the mobile app uses in production.

Readable: planned inspection rounds by assignment and date range, and risk assessment logs.

Writable: defect notifications, inspection answers, and questionnaire definitions including drafts.

Site-specific endpoints live in that site’s own hub. That keeps the published surface something we can actually promise to keep working.

# Rounds assigned to a position, for a window GET /questionnaire/planned/assignedto/{id}/{from}/{to} # Post the answers back POST /questionnaire/planned/saveanswers # Raise a defect from your own system POST /notification/create # Risk assessment logs GET /api/risk/assessmentlogs # Authenticated by API key. OpenAPI described.

Reporting

Power BI in the product, SSRS where a site already lives there.

Power BI Embedded — in the product

AMS authenticates to Power BI server-side with client credentials and mints an embed token per session, then renders the report inside the application. Your analysts build in the tool they already use; access follows your workspace permissions rather than a shared link. A risk management overview report ships as a worked example.

SSRS — delivered for a site

Where a site has standardised on SQL Server Reporting Services, AMS can render into their existing report server. This was built for one customer against their report definitions. It is a deployment option we can repeat, not a feature in the base navigation.

AI agents

An MCP server over the maintenance estate. Read-only, and early.

There is a working Model Context Protocol server that exposes the SAP maintenance estate to AI agents: 28 tools, each described well enough for a model to use correctly. An engineer can ask which orders are open on a functional location, or what the damage catalogue allows, in ordinary English.

Every tool is a read. They get, select and check. There are no write tools, so an agent cannot create a notification, release an order or change a status. That is a deliberate constraint, not an oversight.

Maturity. This is built on a preview release of the MCP server libraries and was delivered for one site. Interesting and real; not something to put on a critical path yet.

> What is open on the number 2 roaster? SelectWorkOrders(functionalLocation: "...") 3 orders open. 1 released, 1 with a do-not-execute flag. > Which damage codes apply to it? GetDamageCodes(catalogProfile: "...") # read-only: nothing is created or changed