Was this helpful?
Was this helpful?
In this Article
  • Created

Article Low-Stock Alert Not Triggering at Correct Threshold

Hi there — Daniel here from Professional Services. I've worked through this particular issue with a number of teams who are tracking fractional inventory quantities, and I wanted to share what I've learned about why low-stock alerts can appear to "miss" their thresholds.

Summary

Low-stock alerts fire inconsistently when threshold values use decimal quantities.

Symptoms

What you'll typically see is that you've configured a low-stock alert at, say, 2.5 units or 0.75 cases, but the alert either never fires or fires unexpectedly when your actual quantity is still well above that threshold. In my experience, this most commonly affects:

  • Items measured in fractional units (pipe lengths, wire spools, fuel, etc.)
  • Teams who recently switched from whole-number tracking to decimal quantities
  • Alerts that were created before the threshold precision was updated

Affected Versions

FieldPulse 3.1 and earlier; resolved in 3.2 with improved decimal handling. If you're on 3.2+ and still seeing this, the cause is typically configuration-related rather than a bug.

Root Cause

In versions prior to 3.2, the alert evaluation engine compared quantities using integer rounding internally. This meant that a threshold of 2.5 was stored and evaluated as 2, causing the alert to fire at the wrong inventory level or not at all. What I typically recommend is understanding that the alert system evaluates thresholds during the sync cycle, not in real-time — so there's also a timing component that can mask the underlying precision issue.

Additionally, if your alert was created before you enabled decimal quantities for that item category, the threshold value may have been rounded at creation time and never updated.

Resolution

Here's what I recommend, based on what's worked for the teams I've implemented:

  1. Verify your FieldPulse version. Navigate to Settings > Account > About. If you're below 3.2, update via your standard update channel — this resolves the core precision issue.
  2. Check your item's unit precision setting. Go to Inventory > Items > [your item] > Edit. Confirm that Allow Decimal Quantities is enabled. If you recently enabled this, proceed to step 3.
  3. Recreate the alert threshold. This is the step that's most often missed. The threshold value needs to be re-entered after decimal precision is enabled for that item. Delete your existing low-stock alert and create a new one at Inventory > Alerts > Low Stock > Create Alert. Enter your exact decimal threshold.
  4. Verify the evaluation timing. Alerts evaluate every 15 minutes during business hours, or on the next sync for mobile inventory updates. If you just adjusted stock levels, wait for the next evaluation cycle or manually trigger a sync from Inventory > Sync Now.

Workaround (if you cannot update immediately)

For teams still on 3.1 or with legacy inventory structures, what I typically recommend is setting your threshold one whole unit below your actual desired trigger point. If you want to be alerted at 2.5 units, set the threshold to 1.5 (which rounds to 2) or simply 2 and accept that you'll be notified slightly earlier than ideal. This isn't perfect — you'll get some alerts when you still have sufficient stock — but it prevents the more serious problem of stock-outs without warning.

Prevention

When setting up new decimal-tracked items, I always advise enabling decimal precision before configuring any alerts. The order of operations matters here because threshold values are validated and potentially rounded at the moment of alert creation.

If you're still seeing inconsistent alert behavior after following these steps, feel free to reach out — I'm happy to review your specific item configuration and alert setup. In my experience, there's almost always a precision or timing factor that explains the behavior once we dig in.

  • in reply to Mike Dolan

    Hi Mike — happy to help dig into this. A couple of quick questions:

    1. Was this alert created after you upgraded to 3.2, or was it an existing alert from before?
    2. Can you check if the item has any reserved quantity tied to open work orders? The alert evaluates against available quantity (on-hand minus reserved), not total on-hand.

    We've seen cases where reserved inventory makes the math look off at first glance. If you can share the specific item and alert IDs, I can also check if there's a rounding edge case in 3.2.1 that engineering should be aware of.

  • We're on 3.2.1 and still seeing this. Threshold at 1.5, alert fired when we hit 2.3. There's still something wrong here.

  • Confirmed this fixed it for us — we had the exact scenario where decimal quantities were enabled after the alerts were already set up. Deleting and recreating the alert was the key step we missed initially. Thanks Daniel!

    Pro tip for anyone else hitting this: we now document our alert thresholds in a shared sheet before making any inventory setting changes, so we can quickly recreate them if needed. It's also worth noting that if you have many alerts affected, you can export your alert config from Settings > Data Export before making changes, which gives you a reference for bulk recreation.