Guidewheel is a machine-monitoring platform. Its sensors clamp onto a machine's power cord to detect when the machine is running, idle, or down. When a machine stops, Guidewheel opens a downtime issue with a start time and one or more cause tags, such as “Mechanical Breakdown” or “No Operator.”
The Guidewheel integration connects Guidewheel to Limble so machine downtime automatically becomes a Limble work order. When a technician completes that work order, the Guidewheel issue is closed.
For setup instructions, read the Guidewheel Integration: User Setup Guide.
How the integration works
Guidewheel downtime creates a Limble work order. The integration checks Guidewheel for open issues every 5 minutes by default. Each open issue creates one work order if its tags match your tag settings and its device is mapped to a Limble asset. The work order includes the machine name, the cause, the downtime start time in your plant's local time, and a link back to the Guidewheel issue.
Completing the work order closes the Guidewheel issue. When a technician completes the work order in Limble, the integration immediately closes the linked Guidewheel issue. It sets the issue's end time, marks the status as closed, and adds a comment with the Limble work order number and the technician's completion notes. If a completion is missed, a backup check closes the issue within about 30 minutes.
What data syncs in each direction?
Guidewheel → Limble
Data | Details |
Downtime issue | Creates a work order if the issue is still open when the integration checks. Issues that are already resolved are skipped. |
Machine name | Taken from the mapped Limble asset name. |
Cause | Taken from the Guidewheel issue's tags. |
Downtime start time | Set as the work order's Scheduled Start and Due date shown in the work order description in your plant's local time zone. |
Link to the Guidewheel issue | Opens the issue in Guidewheel in a new tab. Requires the Guidewheel Web Address to be set in the integration's setup. |
| Added to every work order the integration creates. |
Limble → Guidewheel
Limble event | What happens in Guidewheel |
Work order completed | The issue's |
Work order completed | A comment is added with a link to the Limble work order and the technician's completion notes. |
What the integration doesn’t do
Short stoppages don't create work orders. If a machine goes down and comes back up in less than about 5 minutes (between two checks), no work order is created because work orders are for sending a technician to fix something. Guidewheel keeps the record of brief stoppages.
Unmapped devices are skipped. If a Guidewheel device isn't in the Device Asset Map, its issues don't create work orders, and no error appears.
Work orders don't close when a machine recovers on its own. If Guidewheel closes an issue without a technician completing the work order, the Limble work order stays open until someone closes it.
Runtime hours aren't sent to Limble. You can't use Guidewheel runtime data to update Limble meters or trigger usage-based preventive maintenance.
Each integration covers one Limble location. To cover more than one plant, set up a separate integration for each location.
Comments don't sync. Comments added in Limble or Guidewheel after a work order is created aren't copied to the other system. The only comment sent is the one added to Guidewheel when the work order is completed.
FAQs
How often does the integration check Guidewheel?
How often does the integration check Guidewheel?
Every 5 minutes by default. This is also the minimum. Guidewheel limits API use to 1,000 calls per day, so if you set a shorter schedule, the integration still waits 5 minutes between checks.
The time zone on the Poll Schedule controls how the downtime start time appears on work orders. Set it to your plant's local time zone.
Why didn't a short stoppage create a work order?
Why didn't a short stoppage create a work order?
Before creating a work order, the integration checks whether the Guidewheel issue is already resolved. If the issue is at stoppedAt or is closed, it's skipped. This keeps technicians from getting work orders for machines that are already back up.
Because of this, a stoppage shorter than about 5 minutes usually doesn't create a work order. This is expected.
How do tags decide which issues create work orders?
How do tags decide which issues create work orders?
Each Guidewheel issue has one or more issue_details tags, such as “Mechanical Breakdown,” “Electrical Fault,” or “No Operator.” You choose how tags are used in the Tags step of the setup wizard:
Sync All Issue Tags (on by default): every tagged issue creates a work order, no matter which tags it has. This works for most accounts.
Approved Tags (when Sync All Issue Tags is off): only issues with at least one checked tag create a work order. All other issues are skipped. The Tags step of the configuration wizard presents all
issue_detailstags as a checklist.
An issue with no issue_details tags never creates a work order.
How are guidewheel devices matched to Limble assets?
How are guidewheel devices matched to Limble assets?
You match devices to assets in the Device Asset Map on the Assets step of the setup wizard. Each row pairs one Guidewheel device with one Limble asset. The asset also decides which Limble location the work order is created in.
The wizard fills in the table for you by matching Guidewheel device nicknames to Limble asset names. A device is only matched when its nickname is the same as exactly one asset name (not case-sensitive). If more than one asset has that name, the row is left blank for you to choose. Review the matches, correct any that are wrong, and add rows for devices that weren't matched.
A device that isn't mapped is skipped without an error. The description above the table shows how many devices are mapped and lists the ones that aren't.
What does a work order created by the integration look like?
What does a work order created by the integration look like?
The title is Guidewheel: followed by the cause tags, for example, Guidewheel: Mechanical Breakdown.
The description looks like this:
[Machine name] is down — [cause]. Guidewheel detected this automatically and opened this work order. Completing this work order marks the downtime resolved in Guidewheel.
Downtime started: Jul 30, 2026, 3:01 PM CDT
Guidewheel issue: [issue UUID — links to the Guidewheel issue]
The link opens the Guidewheel issue in a new tab. It's built from the Guidewheel Web Address in the integration's setup. If that address is blank or incorrect, the link won't work and the issue ID appears as plain text.
Will the integration create duplicate work orders?
Will the integration create duplicate work orders?
No. Each time the integration checks Guidewheel, it looks at the open work orders it has already created. If a work order already exists for an issue, it updates that work order instead of creating a new one.
To keep this working:
Don't remove the
@Guidewheeltag from work orders the integration creates.Don't change the Guidewheel Source Tag setting after work orders have been created.
Don't clear or overwrite the
meta1field on these work orders. Learn more in the next question.
What is the meta1 field?
What is the meta1 field?
Every work order the integration creates stores the Guidewheel issue UUID in a field called meta1. This is how the integration links the work order to the Guidewheel issue, both to avoid duplicates and to close the issue when the work order is completed.
The meta1 field isn't shown in Limble, so it can only be changed through the Limble API. If you use the API or another integration to update work orders, do not clear or overwrite meta1 on work orders created by the Guidewheel integration. If it's removed, completing the work order won't close the Guidewheel issue, and the integration may create a duplicate work order.
Completed work orders aren't closing Guidewheel issues right away. What should I do?
Completed work orders aren't closing Guidewheel issues right away. What should I do?
If Limble can't reach the integration after repeated delivery failures, it turns off the real-time connection between Limble and Guidewheel (retry schedule: 10 min → 30 min → 2 hr → 4 hr → auto-disable). Completed work orders still close their Guidewheel issues through the backup check, but within about 30 minutes instead of right away.
To restore the real-time connection, redeploy the instance. The deploy lifecycle flow checks for a disabled webhook and re-enables it, or creates a fresh one if absent. Investigate the root cause of the delivery failures. Common causes include expired Limble connection credentials or the instance being paused.
If it keeps happening, contact our support team.
Need help?
If you have questions about the Guidewheel integration, contact our support team and reference this article.