Limble CMMS

Connect AI agents to Limble CMMS, maintenance management software. Agents create and update maintenance tasks, track assets and parts across locations, and assign work to the right people.

3 triggers 25 actions Basic auth available

Limble CMMS website ↗ Platform Documentation ↗

On Task Event fires when a work order is created, completed, reopened or reassigned

List Tasks pulls the full record, because the webhook payload carries only the ID, status and acting user

List Task Parts and List Parts read what the job needs against what is actually in the bin

Each proposed draw is checked against the part's reorder threshold, where `-1` means disabled rather than low

Add Task Comment records the technician's parts list against the job while it is still a proposal

The maintenance lead is shown the job, the parts, the quantities and the stock position at that location

A person confirms the parts before Attach Part To Task consumes inventory that nothing here can put back

What This Integration Enables

Limble CMMS is a maintenance system, and maintenance is unusual among back office functions in that its data is generated by people holding tools. The gap this connector closes is not reporting, it is the distance between something happening on a plant floor and the system knowing about it. Agents create work orders, preventive maintenance and work requests through Create Task, optionally starting from a template task so a recurring job carries its standard instructions rather than a free text description somebody types twice. Update Task changes name, description, due date, assignment, priority, schedule, meta fields and open or closed state, which is how a job moves through its life. List Tasks filters work orders, PMs and work requests by location, asset, type, assignee, custom tag, completion state and date ranges, and the filter set is good enough that most reporting is a single call. Around the task sit the things that make it auditable: List Task Comments and Add Task Comment for the thread, with the option to hide a comment from external users, List Task Labor for time logged including billable time and rate, List Task Parts for what is attached, and Apply Task Tags for grouping. Assets are a hierarchy, not a list: List Assets reads it with runtime hours and work request portal URLs, Create Asset nests an asset under a parent and places it on a map, Move Asset relocates one with the option to transfer its parts along with it, and Create Asset Log records an observation or a reading against equipment. Locations carry timezone, currency, operating hours and a portal URL, and parts carry stock levels, pricing, bin location and thresholds.

Unlike most connectors in this category, this one has real triggers, and they are worth designing around. On Task Event fires when a task is created, completed, reopened, reassigned, renamed, commented on, retagged or has time logged against it. On Asset Event fires on asset created, deleted or renamed. On Part Event fires on part created, deleted, renamed, repriced, restocked or drawn down. Each offers an Any Event option to receive every change in its category. One thing to build for: Limble webhook payloads carry only the record ID, the event status and the acting user, so a trigger is a signal to go and read, not a delivery of the record. Follow every trigger with the matching list action. Two operational details shape reliability. Limble requires at least one active API key on the account for webhooks to fire at all, and it automatically disables a webhook endpoint after repeated delivery failures, retrying at 10 minutes, 1 hour, 2 hours and 4 hours. Separately, Limble signs each delivery with an HMAC-SHA256 digest keyed by the SHA-256 hex digest of the account's oldest API key, which is not necessarily the key configured here, so the Webhook Signing Key is a separate config item. Leave it empty and verification is skipped with a warning logged rather than dropping legitimate deliveries. Set it, and verification is enforced. If a flow is going to act on an event, set it.

A few conventions decide whether numbers come out right. Timestamps throughout the API are Unix epoch seconds. Name filters use SQL style wildcards, so search text is wrapped in percent signs, %pump%. A task's status reflects completion, 0 incomplete and 1 complete, while statusID holds the account's own custom status, and those are different fields that are easy to conflate. Reorder and stale thresholds use -1 to mean the feature is disabled, and an asset's hoursPerWeek of -1 means it inherits the location's operating hours, so -1 is a state rather than a small number.

Without FlowRunner

Work orders arrive by whatever channel is nearest A fault is reported in a corridor, a text message and a shared inbox, and only some of it reaches the CMMS

Parts consumption is recorded later, or approximately Somebody notes down what they took and enters it at the end of the week, and the bin count drifts

Reorder thresholds are only useful if someone looks A part crosses its threshold and stays there until the next stock check finds it

With FlowRunner

Requests become tasks at the point they are made Create Task opens the work order from the source system, optionally starting from a template task

Consumption is booked against the job it belongs to Attach Part To Task records the draw on the task, and List Parts Usage shows what was consumed where and at what cost

Threshold crossings reach purchasing On Part Event fires on a drawdown and the alert goes out with the part, the location and the current level

Use Case Scenarios

Inbound requests that become real work orders

Fault reports arrive by email, by form and in a chat channel, and the ones that reach the CMMS are the ones somebody had time to enter. The agent reads inbound requests from Gmail and from a shared channel in Slack, extracts the asset reference and the described fault, and calls List Assets with a wildcard name filter to resolve the reference to a real asset in the hierarchy rather than a string. It calls List Tasks filtered on that asset and an incomplete completion state to check whether the same fault is already open, because the second report of a leaking pump should be a comment and not a second work order. For genuinely new faults it calls Create Task as a work request or an unplanned work order, starting from a template task where one exists for that fault type, and applies grouping through Apply Task Tags. For repeats it calls Add Task Comment on the existing task instead, and replies to the reporter with the task it was attached to.

Completion that closes the loop everywhere else

On Task Event fires when a work order is completed. Because the payload carries only the record ID, the status and the acting user, the agent immediately calls List Tasks to read the full record, then List Task Labor for the time logged including billable time and rate, and List Task Parts for what was consumed. It assembles a completion summary with the asset, the downtime window, the labor cost and the parts cost, posts it to the maintenance channel in Slack, and appends the row to a cost tracker in Google Sheets so the monthly maintenance cost report is built continuously rather than reconstructed. Where the work order was raised against a customer job, the same summary is pushed into the billing system. Because the delivery is only verified when the Webhook Signing Key is configured, this flow is designed as a read and a report rather than a write, which is the right shape for an event that arrives unauthenticated.

An asset hierarchy that stays in step with reality

New equipment is commissioned, old equipment is relocated between sites, and the CMMS hierarchy is usually the last thing updated. The agent reads the commissioning list from Google Sheets, calls List Locations to resolve each site to a real location with its timezone and operating hours, and Create Asset for each new unit nested under the correct parent and placed on the site map, with runtime hours and in-service date set. For equipment being relocated it calls Move Asset, deciding explicitly whether the asset's parts move with it, because that single option determines whether the spares for that machine are counted at the old site or the new one afterwards. Create Asset Log records the commissioning reading against each asset so the runtime baseline starts from a real number. On Asset Event fires on each create and rename, and the agent mirrors the change into the fixed asset register so maintenance and finance stop describing different equipment.

Human-in-Loop Highlight

Attach Part To Task is the gate here, and the reason is a gap in the action list rather than anything in the action itself. Attaching a part to a task consumes inventory against that task: the stock number goes down, the cost lands on the job, and List Parts Usage will report it as consumed. Now look at what this connector can do about it afterwards. Parts support List Parts, Create Part and List Parts Usage. There is no update, no delete, and no detach. So a part booked onto the wrong task, or booked at the wrong quantity, cannot be put back through this integration at all. The correction is a person in Limble, and until they make it the bin count in the system disagrees with the bin count on the shelf, which is the specific failure that makes maintenance teams stop trusting a CMMS. It compounds in two directions. Reorder thresholds fire off the level this action moves, and a threshold of -1 means the feature is disabled rather than set to a very low number, so an over-booking on one part can raise a purchase and an under-booking on another can raise nothing at all. And the event that usually starts this flow, On Part Event or On Task Event, is only signature verified when the Webhook Signing Key is set, so an unverified payload should never be the sole authority for a stock movement. So the agent does everything up to the draw and then stops. It posts to the maintenance lead: "Work order 4471, pump rebuild at Line 2, closed by J. Okafor. The technician's notes list 4 parts. I matched 3 against the parts list at that location: mechanical seal, 1, 6 in stock; bearing 6205, 2, 3 in stock, reorder threshold 4, so this draw takes it below; gasket set, 1, 11 in stock. The fourth, shaft sleeve 40mm, matches two parts at this location with different prices and I cannot tell which was used. Booking these consumes the stock and there is no way for me to reverse it. Confirm the three quantities and pick the right shaft sleeve, and I will attach them and alert purchasing on the bearing." A person answers once, in the language of their own store room, and the agent runs Attach Part To Task on a confirmed list. This is the human-in-the-loop moment in maintenance: an agent can read what a technician wrote and what the shelf says, and only a person can commit a stock movement that nothing in the flow can take back.

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

25 actions

Tasks

List Tasks Filters work orders, preventive maintenance and work requests by location, asset, type, assignee, custom tag, completion state and date ranges. The read that follows every trigger, because webhook payloads carry only an ID.
Create Task Creates a work order, PM or work request, optionally from a template task so a recurring job carries its standard instructions. Cycle counts, min part thresholds and materials requests are system generated and can only be filtered on when listing.
Update Task Changes name, description, due date, assignment, priority, schedule, meta fields and open or closed state. Note that `status` reflects completion, 0 or 1, while `statusID` holds the account's custom status.
Delete Task Permanently removes a task, along with the record of the work it described.
List Task Comments Reads the comment thread on a task, which is usually where the real diagnosis is written.
Add Task Comment Posts a comment, optionally hidden from external users. The right place to record a duplicate report rather than opening a second work order.
List Task Labor Reads time logged against tasks, including billable time and rate. The labor half of a job cost.
List Task Parts Reads the parts attached to a task. The materials half of a job cost.
Attach Part To Task Consumes inventory against a task, drawing the part's stock down and putting its cost on the job. Nothing in this connector detaches, updates or deletes a part afterwards, so this runs behind an approval.
Apply Task Tags Applies custom tags for grouping and filtering, which is what makes a fault type reportable later.

Assets

List Assets Reads the asset hierarchy with runtime hours and work request portal URLs. Note that `hoursPerWeek` of `-1` means the asset inherits the location's operating hours.
Create Asset Adds an asset, optionally nested under a parent and placed on a map, so the hierarchy reflects the plant rather than a flat list.
Update Asset Changes name, parent, runtime hours, in-service date and map position.
Delete Asset Permanently removes an asset and the history hanging from it.
Move Asset Relocates an asset, optionally transferring its parts. That option decides whether the spares for that machine are counted at the old site or the new one, so set it deliberately.
List Asset Logs Reads the manual log entries recorded against equipment, which is where readings and observations live.
Create Asset Log Records an observation or a reading against an asset, for example the commissioning runtime baseline.

Locations

List Locations Reads sites with timezone, currency, operating hours and portal URL. Resolves a site name to a real location before anything is created against it.
Create Location Adds a site with timezone, phone, address, region and currency.

Parts

List Parts Reads inventory with stock levels, pricing, bin location and thresholds. Reorder and stale thresholds use `-1` to mean disabled rather than a very low value.
Create Part Adds a part with stock, price, supplier, category and reorder thresholds.
List Parts Usage Reads which parts were consumed on which tasks, and at what cost. The report that proves a stock movement happened and where the cost landed.

People

List Users Reads users with wage, workday hours, team memberships and active state. Resolves an assignee before a task is assigned to one.
List Vendors Reads suppliers and contractors.

Account

Get Account Info A lightweight connection check for the configured credentials and region. Worth running first, because Limble hosts separate regional API endpoints and calling the wrong host rejects otherwise valid credentials.

Triggers

3 triggers

Event Triggers

On Task Event Fires when a task is created, completed, reopened, reassigned, renamed, commented on, retagged, or has time logged against it. Offers an Any Event option to receive every change in the category. The payload carries only the record ID, the event status and the acting user, so follow it with List Tasks to read the record.
On Asset Event Fires when an asset is created, deleted or renamed. Used to mirror hierarchy changes into a fixed asset register or a downstream system. Follow it with List Assets for the full record.
On Part Event Fires when a part is created, deleted, renamed, repriced, restocked or drawn down. The drawdown event is the one purchasing cares about. Follow it with List Parts to read the current level against the part's reorder threshold.

Frequently Asked Questions

What can FlowRunner do with Limble CMMS?

FlowRunner agents can run List Tasks, Create Task, and Update Task in Limble CMMS, plus 22 more actions.

Does connecting Limble CMMS to FlowRunner require OAuth?

No. Limble CMMS connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.

Can Limble CMMS trigger a FlowRunner workflow automatically?

Yes. Limble CMMS supports 3 triggers that can start a FlowRunner workflow automatically.

Start building with Limble CMMS

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

Start Building Free Talk to us