remberg

Connect AI agents to remberg, a German asset and service management XRM for equipment manufacturers and operators. Agents create assets and parts, open tickets and work orders, approve work requests, and read the forms a technician completed.

61 actions API key available

Platform Documentation ↗

A monitoring platform reports a fault on a machine, or a scheduled poll of List Asset Status Signals surfaces one

Get Asset returns the machine, its organization and its criticality, resolved from the internal ID rather than the asset number

Create Asset Status Signal records the downtime event against the asset with a failure type from List Failure Types

Create Work Request opens the request, sent as multipart form data with the fault photo attached

List Part Inventories confirms whether the spare the fix needs is actually on the shelf

The service planner receives the request, the asset's signal history and the parts position

A person decides before Approve Work Request converts the request into a dispatched work order

What This Integration Enables

remberg is a German asset and service management XRM, and the word that matters in that sentence is asset. Most service platforms are organised around the ticket. remberg is organised around the machine, which is the right shape for a manufacturer whose product is still working, or not working, at a customer site fifteen years after it shipped. Everything hangs off the asset: its status signals, the tickets raised about it, the work orders performed on it, the parts consumed doing so, and the forms the technician filled in while standing next to it. This connector opens that model to agents so a fault detected by a monitoring system becomes a service event with an asset behind it rather than an email with a serial number in the subject line.

Assets are fully writable through List Assets, Get Asset, Create Asset, Update Asset and Delete Asset, with Create Asset Status Signal, List Asset Status Signals and Resolve Asset Status Signals carrying machine state and downtime, and List Failure Types resolving the failure taxonomy the account uses. Failure type labels can be a plain string or a multi language object, and this connector resolves either shape rather than assuming German or English. The service path runs from work requests into work orders: Create Work Request opens a request and is sent as multipart form data with one optional file attachment, then Approve Work Request converts it into a work order, either linking an existing work order or prefilling a new one, and Decline Work Request closes the other door. Work orders carry the detail through Add Work Order Checklist Items, Add Work Order Procedure and Create Work Order Stock Change, which is how consumed spares leave inventory as part of the job rather than as a separate exercise nobody does. Tickets, contacts, organizations, parts and part inventories, files and folders, and user onboarding through Create User, Invite User and Suspend User complete the surface.

Forms are read only here, and that is the correct description rather than a limitation to apologise for. List Forms and Get Form pull back the finalized service forms a technician completed, so the checklist, the readings and the signature can be written into an ERP, attached to a customer record or archived. This connector does not author forms and does not submit them, because the form is the technician's evidence and it belongs to the person who signed it. Two mechanics shape any flow built here. remberg mixes API versions on one host, with assets, tickets, parts and work orders on v2 and contacts, organizations, files, forms, procedures, users and work requests on v1, and this connector targets the correct version per endpoint so you never set one. And every Get, Update and Delete uses the resource's internal ID, an opaque identifier that is not the human facing asset number or work order number, which is why a flow resolves records through the dictionaries rather than by the number printed on the machine. Update actions are partial, so only the fields you provide change. Rate limits are enforced as two sliding windows together, a burst limit and a base limit, and requests that receive a rate limit response still count against it, so a retry storm makes the problem worse rather than better.

On events, this connector ships no triggers. remberg publishes no webhook subscription API and no payload shape, so there is nothing to register and nothing here creates a FlowRunner trigger. Change detection is a scheduled poll, and the platform is well set up for it: List Asset Status Signals, List Work Requests, List Tickets and List Work Orders all accept created and updated date range filters that make clean polling cursors.

Without FlowRunner

Downtime is reported in a message A machine stops and the fault reaches service as a phone call with no asset attached

Approval and parts are separate conversations A job is approved, then someone discovers the spare is not in stock

Completed forms stay in the field app The checklist the technician signed never reaches the ERP or the customer file

With FlowRunner

Downtime is a signal on the asset Create Asset Status Signal puts the event on the machine, where the service history already lives

Approval happens with the parts position in view The planner sees the request, the asset's signal history and stock before converting anything

Forms are pulled back where they are needed List Forms and Get Form read the finalized service form out into the systems that consume it

Use Case Scenarios

A fault signal that becomes a request with an asset behind it

A monitoring platform or an IoT gateway reports that a machine has stopped. The agent resolves the asset from its serial or ERP reference, calls Get Asset for the organization and criticality, and reads List Failure Types so the failure is categorised with a value this account actually uses. Create Asset Status Signal records the downtime on the asset itself, which means the next person to open that machine's record sees the event in the same place as every previous one. Create Work Request then opens the service request as multipart form data with the fault photo attached. Nothing is dispatched yet. The planner gets the request, the asset's prior signals from List Asset Status Signals, and the parts position from List Part Inventories, and decides whether this is a visit or a phone call.

Spare parts that stay in step with the ERP

The parts catalog lives in weclapp or another ERP and the service side needs it accurate, because a work order that consumes a part the system does not know about produces a stock figure nobody trusts. On a schedule the agent reads the ERP article master, compares it to List Parts, and calls Create Part for new items and Update Part for changed ones. Update Part Inventory Stock reconciles the on hand figures per inventory location. On the return leg, work orders that have run Create Work Order Stock Change are read back so the consumption recorded by the technician reaches the ERP rather than sitting in the service system. Discrepancies above a threshold are named and sent to the stores manager instead of being written in either direction.

Finalized service forms that reach the customer file

A technician completes a maintenance visit and fills in the service form on site. On a schedule the agent calls List Forms over the previous day, reads each with Get Form, and pulls the readings, the checklist results and the completion state. Those values are written onto the customer's record and, where the visit was chargeable, become the line detail on the service invoice raised in Xero. Download File retrieves the attached photographs and reports into FlowRunner file storage so the archived copy is the original. Where a form shows a failed check or a reading outside tolerance, the agent does not close anything. It calls Create Ticket against the same asset so the exception stays attached to the machine, and posts the reading and the tolerance to the service channel in Slack.

Human-in-Loop Highlight

Approve Work Request is the gate, because it is the door between a request and a dispatch. Approve Work Request converts the request into a work order, which means a technician, a van, a day and a spare part are all committed to a specific machine at a specific site. Decline Work Request is the other door and it is just as consequential in the opposite direction: on a critical asset, a declined request is a machine that stays down. Neither is a state an agent should walk through on its own, and the reason is specific to this platform rather than general caution. The signal an agent acts on here is Create Asset Status Signal data, which is often machine telemetry, and telemetry reports a symptom rather than a cause. A pressure reading out of range can be a failing pump or a failing sensor, and the two have completely different answers. remberg gives the agent everything needed to tell the difference and nothing that lets it be sure. So the agent gathers and stops. It posts to the service planner: "Asset A-4471, filling line 3 at Kesselmann Getranke, criticality Critical, reported a status signal at 04:12 with failure type Druckabfall. This asset has raised the same failure type four times since March and three of those were resolved without a part being consumed. The spare that the last real fix used, part 22-0918, shows 0 on hand at the Hannover inventory and 2 at Dortmund. Approving this work request dispatches a technician tomorrow and the nearest spare is a day away. Approve and I will prefill the work order with the Dortmund part, decline and I will raise a ticket for a remote diagnostic first, or tell me to hold it for the morning call?" The planner answers once, and the agent runs Approve Work Request with the prefill values, or Decline Work Request and Create Ticket instead. This is the human-in-the-loop moment on a platform where the agent can read every prior failure on the machine and still cannot tell a broken pump from a broken sensor, which is exactly the judgement a service planner is paid for.

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

61 actions

Assets

List Assets Returns assets with created and updated date range filters, which makes it a clean polling cursor as well as a search.
Get Asset Returns a single asset by its internal ID, including its organization and criticality.
Create Asset Registers a machine for ongoing service management, typically at the point it is installed or handed over.
Update Asset Patches an asset. Updates are partial, so only the fields you provide change.
Delete Asset Permanently removes an asset and cannot be undone.
Create Asset Status Signal Records a machine status or downtime event against the asset, which is how telemetry from a monitoring platform lands where the service history already is.
List Asset Status Signals Returns status signals with date range filters. This is the polling read that replaces the events this connector does not receive.
Resolve Asset Status Signals Marks status signals as resolved once the underlying condition has been dealt with.
List Failure Types Returns the failure taxonomy configured on the account. Labels can be a plain string or a multi language object, and both shapes resolve.

Tickets

List Tickets Returns service tickets with created and updated date range filters.
Get Ticket Returns a single ticket by its internal ID.
Create Ticket Opens a service ticket. Status accepts New, Open, Pending Internal, Pending External, Solved, Closed and Moved.
Update Ticket Patches a ticket. The status set accepted on update is narrower than on create and excludes New and Moved.
Delete Ticket Permanently removes a ticket and cannot be undone.
Get Ticket Conversations Returns the conversation thread on a ticket, which is where the context of a support exchange lives.
List Ticket Categories Returns the ticket categories configured on the account.

Work Orders

List Work Orders Returns work orders with created and updated date range filters.
Get Work Order Returns a single work order by its internal ID.
Create Work Order Creates a work order directly, for planned maintenance that does not start life as a request.
Update Work Order Patches a work order. Updates are partial.
Delete Work Order Permanently removes a work order and cannot be undone.
Add Work Order Checklist Items Adds checklist items to a work order, so the steps a technician must complete are on the job before it is dispatched.
Create Work Order Stock Change Records the spare parts consumed on a job, which is how a stock figure stays true to what actually happened in the field.
Add Work Order Procedure Attaches a procedure to a work order.

Work Requests

List Work Requests Returns work requests with date range filters, the queue a planner works from.
Get Work Request Returns a single work request in full.
Create Work Request Opens a work request. It is sent as multipart form data and accepts one optional file attachment, so the fault photo travels with the request.
Update Work Request Patches a work request before it is decided.
Approve Work Request Converts the request into a work order, either linking an existing work order or providing prefill values for a new one. This is the dispatch decision and it runs behind a person.
Decline Work Request Declines the request. On a critical asset this leaves a machine down, which is why it is treated as a decision rather than a cleanup.
Delete Work Request Permanently removes a work request and cannot be undone.

Parts

List Parts Returns the spare parts catalog.
Get Part Returns a single part by its internal ID.
Create Part Adds a part to the catalog, typically to mirror an ERP article master.
Update Part Patches a part.
List Part Inventories Returns stock positions per inventory location, which is the read that turns an approval decision into a realistic one.
Update Part Inventory Stock Reconciles the on hand quantity at an inventory location.

Contacts and Organizations

List Contacts Returns contacts across the account.
Get Contact Returns a single contact by its internal ID.
Create Contact Creates a contact.
Update Contact Patches a contact.
Delete Contact Permanently removes a contact and cannot be undone.
List Organizations Returns customer and supplier organizations.
Get Organization Returns a single organization by its internal ID.
Create Organization Creates an organization.
Update Organization Patches an organization.
Delete Organization Permanently removes an organization and cannot be undone.
List Organization Contacts Returns the contacts belonging to an organization.

Files

List Files Returns files stored in remberg.
Upload File Streams a FlowRunner file into remberg as multipart form data. The documented maximum upload size is 10 MB.
Download File Saves a remberg file into FlowRunner file storage and returns the stored file URL, with the storage scope set through the file settings option.
Create Folder Creates a folder, used to archive a job's photographs and reports somewhere a person can find them.
Delete File Permanently removes a file and cannot be undone.

Forms

List Forms Returns the digital service forms in the account. Forms are read only through this connector.
Get Form Returns a finalized form with the readings, checklist results and completion state the technician recorded, so the evidence from the visit can reach the ERP or the customer file.

Users

List Users Returns the users on the account.
Get User Returns a single user by internal ID.
Create User Creates a user as part of onboarding a team member.
Update User Patches a user record.
Invite User Sends an activation invite to a created user.
Suspend User Suspends a user's access, which is the offboarding half of the same workflow.

Frequently Asked Questions

What can FlowRunner do with remberg?

FlowRunner agents can run List Assets, Get Asset, and Create Asset in remberg, plus 58 more actions.

Does connecting remberg to FlowRunner require OAuth?

No. remberg connects to FlowRunner with an API key, no OAuth flow required.

Can remberg trigger a FlowRunner workflow automatically?

remberg doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with remberg

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

Start Building Free Talk to us