MFR (Mobile Field Report)

Connect AI agents to MFR (Mobile Field Report), a field service platform from simPlias GmbH. Agents open service requests, schedule appointments, track service objects and parts, and read the reports technicians file.

27 actions Basic auth available

Platform Documentation ↗

A deal closes in a CRM or a ticket is escalated to a site visit

The agent reads the customer, the equipment and the fault description from the source record

List Companies filtered on the External ID resolves whether this customer already exists in MFR

List Service Objects confirms whether the equipment is already registered under a matching External ID

Create Service Request (Deep) opens the jobs whose customer and service objects both resolved, then Create Appointment schedules each visit

The service coordinator is shown the jobs opened and the ones whose identifiers did not resolve

A person decides match or create on every job whose External ID came back ambiguous

What This Integration Enables

MFR, Mobile Field Report, is the field service platform from simPlias GmbH used to dispatch service technicians and subcontractors, document jobs and bill the work. This connector talks to the MFR OData v4 API, and the OData shape is the practical thing about it: list actions accept a raw $filter expression such as State eq 'Open', CustomerId eq 42 or contains(Name,'boiler'), plus Top, Skip and Order By with a sort direction. That means an agent narrows a query at the vendor rather than pulling everything and filtering in the flow, which matters when a service business has years of orders. List responses come back in an OData envelope, with results in the value array and the total in @odata.count when Include Count is enabled. Entity keys are 64-bit integers, and Get, Update and Delete actions address a record as Collection(id).

Service requests are the centre of it. List Service Requests, Get Service Request, Create Service Request, Update Service Request and Delete Service Request cover the ordinary path, and Create Service Request (Deep) covers the interesting one: it posts to the REST endpoint /mfr/ServiceRequest/Deep rather than the OData collection, and can create the customer, service objects and contacts alongside the order in one call, with the Customer and Service Objects graphs passed as objects matching MFR's ServiceRequestCreation schema. Around that sit appointments, which is where dispatch actually happens, through List Appointments, Create Appointment, Update Appointment and Delete Appointment. Companies and contacts are the customer side, service objects are the equipment a job is logged against, items are the material and labor lines booked onto a request, and List Reports pulls the generated service reports and invoices for archival or accounting. Comments carry the running narrative through List Comments and Create Comment.

Two things about this connector need stating plainly rather than glossed. First, most create actions accept an External ID so records can be matched to an external system, and the deep create reuses records with a matching External ID instead of duplicating them. That is the single most useful behaviour here and also the most consequential to get wrong. Second, fields such as a service request State or an appointment Type are open strings in MFR's model with no fixed enumeration published in the metadata, so they are plain text inputs rather than dropdowns, and the only dropdown in the connector is Sort Direction. A state string that nobody else uses is accepted and creates a silo of one.

On events, be careful, because this connector has webhook actions and no trigger, and those are different things. MFR exposes a webhook subscription API, the WebHooks collection, and the connector surfaces it as List Webhooks, Create Webhook and Delete Webhook. Those actions register an external endpoint of your choosing with MFR. They do not create a FlowRunner trigger, and nothing here listens for an MFR event. The reason is that the shape of the payloads MFR delivers to a callback URL is not published in the primary documentation, so webhook management is offered honestly as plain actions rather than dressed up as an event source. Change detection inside a flow is a scheduled poll: List Service Requests with a $filter on the state or a date field, keeping the last seen position between runs, which is exactly what the reconciliation pattern below does.

Without FlowRunner

A job is opened in three systems by hand The customer, the equipment and the work order are each entered separately, and the links between them are typed

Duplicate customers arrive through the back door A second record for the same site is created because nobody checked, and future jobs attach to the wrong one

Reports and invoices are fetched when someone asks A completed job's paperwork sits in MFR until accounting chases it

With FlowRunner

One call opens the whole job Create Service Request (Deep) creates the customer, service objects and contacts alongside the order in a single request

Matching is explicit External IDs are checked first, and the ambiguous ones go to a person rather than being resolved by guess

Paperwork is pulled on completion List Reports runs on the closed order and the documents are archived and forwarded automatically

Use Case Scenarios

A job opened from a CRM in one call

A deal closes or a support ticket is escalated to a site visit, and the field service system needs a customer, the equipment and a work order, all correctly linked. The agent reads the record from HubSpot, then calls List Companies with an OData filter on the External ID carried from the CRM to see whether this customer already exists in MFR. Where it resolves to exactly one company, the agent calls Create Service Request (Deep) passing the Customer and Service Objects graphs, which reuses the matched customer and any service objects whose External IDs already exist, and creates only what is genuinely new. Where it does not resolve, the flow stops and asks rather than creating. Once the order exists, Create Appointment schedules the visit with the technician and window, and Create Comment records the origin of the job and the CRM reference so anyone opening the order can see where it came from. The order number is written back to the CRM record, so both systems point at each other.

Completion paperwork that reaches accounting on its own

A technician finishes a job and files their report in MFR. On a schedule the agent calls List Service Requests with a $filter on the completed state and a date range covering the period since the last run, then for each order calls Create Item to book the labor and material lines where those come from an external source, and List Items to read what has been booked. It calls List Reports to pull the generated service reports and invoices for the order, archives them to Google Drive under the customer folder, and posts a summary with the order reference, the customer and the line totals to the accounting channel in Slack. List Comments is read alongside, because a technician's comment about a part that had to be replaced on site is often the only warning that an invoice is about to be larger than the quote.

A nightly reconciliation between MFR and the ERP

Two systems holding the same jobs will disagree unless something makes them agree. Each night the agent calls List Service Requests with an OData filter covering orders changed since the last run and Include Count enabled so it can page through with Top and Skip. For each order it reads the state, the customer and the appointment schedule through List Appointments, and compares that against the corresponding record in the ERP, matching on the External ID rather than on names. Differences fall into three groups: orders in MFR with no ERP counterpart, which it creates; orders whose state has moved, which it mirrors with Update Service Request or updates in the ERP depending on which side owns that field; and orders where both sides changed since the last run, which it reports rather than resolves. Get Company and Get Service Request fill in detail where a difference needs explaining, and the exception list goes to the operations lead. Because Delete Service Request, Delete Appointment and Delete Webhook are permanent and cannot be undone, this reconciliation never deletes anything on either side.

Human-in-Loop Highlight

Create Service Request (Deep) is the gate, and it is the gate precisely because it is the best action in the connector. One call creates the customer, the service objects and the contacts alongside the order, and it reuses records with a matching External ID instead of duplicating them. When the External ID resolves, that is a clean, idempotent write and the reason to use this connector at all. When it does not resolve, the same call does not fail. It creates. A missing or mistyped External ID on a customer who already exists in MFR produces a second company record, a second set of service objects for equipment that is already registered, a second contact for the same person, and a work order attached to all of them. Now look at what can be done about it. The connector exposes Delete Service Request, Delete Appointment and Delete Webhook, and those are permanent. It exposes no delete for a company, a contact or a service object. So the duplicate order can be removed and the duplicate customer and duplicate equipment records it created cannot, and the next job for that site will be dispatched against whichever one an agent happens to match. The failure is quiet in the way that matters: the technician still turns up, the job still gets done, and the service history for that boiler is now split across two objects, which is the history a maintenance contract is priced from. Compounding it, State is an open string with no published enumeration, so a deep create that also carries a state nobody else uses puts the order outside every filter the operations team runs. So the agent resolves what it can and hands over the rest. It posts to the service coordinator: "9 jobs ready to open in MFR. 6 have an External ID that List Companies resolves to exactly one company, and their service objects resolve too, so the deep create will reuse them. 3 need you. Job 2 is for Hausverwaltung Meyer GmbH with no External ID on the CRM record; List Companies finds two similar names and I cannot choose. Job 5 has a matching company but the boiler serial does not match any service object, so the deep create would register it as new equipment, and if it is the same unit under a different serial format the service history splits. Job 8 carries the state Eingegangen, which no other open order in this account uses. Confirm the 6, and tell me per job whether to match or create." The coordinator answers once. This is the human-in-the-loop moment in field service dispatch: an agent can prove that an identifier did not resolve, and only a person can say whether the customer standing behind it is new.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

27 actions

Service Requests

List Service Requests Lists service requests with a raw OData `$filter` expression, plus Top, Skip and Order By. Results arrive in the `value` array, with the total in `@odata.count` when Include Count is enabled. The scheduled read that stands in for the events this connector does not receive.
Get Service Request Returns a single service request addressed by its numeric key.
Create Service Request Creates a service request against existing records, accepting an External ID so it can be matched to a source system later.
Create Service Request (Deep) Posts to the REST endpoint `/mfr/ServiceRequest/Deep` and creates the customer, service objects and contacts alongside the order in one call, reusing records whose External ID already matches. Where an External ID does not resolve it creates rather than fails, and the company, contact and service object it creates cannot be deleted through this connector, so it runs behind an approval.
Update Service Request Updates an existing service request. State is an open string with no published enumeration, so set it to a value the rest of the account already filters on.
Delete Service Request Permanently deletes a service request. This cannot be undone.

Appointments

List Appointments Lists appointments with OData filtering, ordering and paging. The dispatch board, read from the source.
Create Appointment Creates an appointment against a service request, which is the step that puts a named technician on a site at a time. Type is a free text field rather than a dropdown.
Update Appointment Updates an existing appointment, including rescheduling and reassignment.
Delete Appointment Permanently deletes an appointment. This cannot be undone, so cancelling by update is usually the safer path.

Companies

List Companies Lists companies with OData filtering, which is how an External ID from a source system is resolved to a real MFR customer before anything is created.
Get Company Returns a single company addressed by its numeric key.
Create Company Creates a company, accepting an External ID for matching. There is no delete for a company in this connector, so a duplicate created here stays.
Update Company Updates an existing company record.

Contacts

List Contacts Lists contacts with OData filtering.
Create Contact Creates a contact, accepting an External ID for matching. As with companies, there is no delete counterpart here.
Update Contact Updates an existing contact record.

Service Objects

List Service Objects Lists the service objects, the equipment and assets that jobs are logged against. Reading these before a deep create is what keeps a machine's service history on one object.
Create Service Object Creates a service object, accepting an External ID so the same physical unit is not registered twice.

Items

List Items Lists the line items booked onto service requests, covering materials and labor.
Create Item Books a material or labor line onto a service request after the job is done.

Reports

List Reports Lists the generated service reports and invoices, for downstream archival or accounting. Read only: MFR generates these and this action retrieves them.

Comments

List Comments Reads the comments recorded against a record, which is often where the reason an invoice differs from the quote is written.
Create Comment Adds a comment, for example recording the source system and reference that opened a job.

Webhooks

List Webhooks Lists the webhook subscriptions registered in MFR. These subscribe an external endpoint of your choosing and do not create a FlowRunner trigger.
Create Webhook Registers a webhook subscription in MFR pointing at an endpoint you nominate. MFR does not publish the shape of the payloads it delivers, so this is offered as plain webhook management rather than as an event source.
Delete Webhook Removes a webhook subscription. Permanent and cannot be undone.

Frequently Asked Questions

What can FlowRunner do with MFR (Mobile Field Report)?

FlowRunner agents can run List Service Requests, Get Service Request, and Create Service Request in MFR (Mobile Field Report), plus 24 more actions.

Does connecting MFR (Mobile Field Report) to FlowRunner require OAuth?

No. MFR (Mobile Field Report) connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.

Can MFR (Mobile Field Report) trigger a FlowRunner workflow automatically?

MFR (Mobile Field Report) doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with MFR (Mobile Field Report)

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us