My Workflow worked once and then never again

Overview

If a workflow triggers successfully one time and then appears to stop, it usually means the workflow is still enabled, but something in its configuration is preventing it from firing again—most commonly Suppression, Schedule windows, or a condition that never becomes false again.

This article provides a structured checklist to diagnose and resolve the issue in Perspio.

---

Symptoms you may observe

• The workflow fired once (email/SMS received), then no further notifications.

• The workflow is visible in the workflow list but appears “quiet”.

• The condition you expect is still happening, but no new actions are being triggered.

---

Most common root causes

1. Suppression is set to “Until False” and the condition has never cleared since the first trigger.

2. The workflow is in a Recurring schedule window, and you are currently outside the allowed day/time range (or the date range ended).

3. The workflow type is Events, and the event only happened once (or the expected event is not occurring again).

4. The workflow scope no longer includes the asset(s) (asset removed from group, wrong scope selection, etc.).

5. The signal is no longer updating (telemetry stopped), so the condition is never re-evaluated as expected.

6. The action is firing, but delivery fails (recipient field is blank because the asset contact email/phone is missing).

---

Step 1 – Confirm the workflow is enabled

What to check

• In the workflow list, confirm the workflow shows as enabled/active (status indicator varies by tenant UI).

• Open the workflow and in the Action Widget confirm if it's Enabled.

Why this matters

A workflow that is disabled will not evaluate conditions or trigger actions, regardless of other settings.

---

Step 2 – Validate the workflow type matches the trigger you expect

Workflow Type determines how the workflow is initiated.

What to check

• Continuous: reacts to live updates. If signals stop updating, triggers may stop.

• Events: triggers only when the target event occurs again.

• Periodic: checks at an interval; you may need to wait until the next evaluation.

• Scheduled: triggers at set times; it may not be “due” yet.

Common “worked once” scenarios by type

• Events: the event occurred once during testing, but it isn’t happening again in production.

• Scheduled: it triggered at the scheduled time once, but the schedule/date range prevents future runs.

• Periodic: it triggered on the first cycle, but suppression prevents repeated firing.

---

Step 3 – Check Schedule configuration

Scheduling controls when Perspio monitors.

3.1 Always-On vs Recurring

• Always-On: monitoring is continuous.

• Recurring: monitoring only happens within configured windows.

If you are using Recurring, verify:

• Time Zone is correct

• Date Range is valid

• Time Range includes the current day/time

3.2 Date Range

• Confirm Start Date is in the past.

• If Indefinitely is not checked, confirm End Date has not passed.

3.3 Time Range

• Confirm the correct option is selected:

  • Everyday / Weekdays / Weekends / Custom

• If All day is unchecked, confirm Start Time and End Time are correct.

Typical cause

A workflow “worked once” during a test window, then stops because:

• The recurring window ended

• The workflow is outside business hours

• The timezone is misaligned (e.g., evaluating in a different timezone than intended)

---

Step 4 – Check Suppression (this is the #1 cause)

Suppression controls how often actions can re-trigger.

Options and their impact

Until False (most common)

• Triggers once when the condition becomes true

• Will not trigger again until the condition becomes false (resolves), then becomes true again

Typical “worked once” scenario:

• The condition became true (triggered once)

• The condition never returned to false afterwards

• Result: no further notifications

Example

• Condition: Temperature > 8°C

• If temperature stays > 8°C continuously, the workflow triggers once and remains suppressed until it drops back ≤ 8°C.

None

• No suppression; it may fire repeatedly (often too noisy)

Until Custom Timeout

• After firing, it “cools down” for a configured time

• It can fire again after the timeout (useful for “still an issue” reminders)

What to do if you need repeated alerts

If you want reminders while the condition remains true:

• Use Until Custom Timeout (e.g., every 60 minutes), or

• Create a second workflow for escalation, or

• Add a separate “still active” periodic/scheduled workflow (depending on your design)

---

Step 5 – Validate the Condition is able to become true again

Even with correct scheduling, a workflow will not re-trigger if the condition logic can’t re-enter a “true” state.

Common condition patterns that only trigger once (unless state changes)

• Is Changed operator:

  • Triggers only when a field changes again

• Conditions tied to a value that never reverts:

  • Example: “Asset Name contains X” will not re-trigger unless suppression allows repeat and the evaluation model triggers actions repeatedly (usually not recommended)

• Conditions dependent on a single “first-time” event or state:

  • Example: “First telemetry received” style patterns

What to check

• Confirm the signal is the correct one (Asset Details vs Telemetry).

• Confirm the operator matches your intent (Equal to vs Contains vs Is Changed).

• Confirm the expected state transitions are possible (true → false → true).

---

Step 6 – Confirm the asset is still in scope

A workflow can appear to “stop” if it no longer evaluates the asset you’re watching.

What to check by scope type

• Assets scope: confirm the asset is still selected in the workflow.

• Groups scope: confirm the asset is still a member of the selected group(s).

• Global scope: confirm the workflow is not restricted by a condition that excludes the asset.

• Service Flag: confirm the Service Flag Workflows is ON. More information on this article.

Typical “worked once” scenario

• You tested with an asset while it was in a group, then it was removed from the group afterward.

---

Step 7 – Confirm telemetry and data are still updating

If the workflow depends on live telemetry (common in Continuous/Periodic workflows), a lack of incoming data can stop the condition from being met again.

What to verify

• The asset is still reporting (latest telemetry timestamp is recent).

• The specific field used in the condition is present and populated.

• Values are not showing as “NA” in your inspection tools.

Recommended check

• Open Variable Inspector for a representative asset and confirm the relevant fields (telemetry/config/details) are available and current.

---

Step 8 – Confirm Actions are configured to deliver every time

Sometimes the workflow triggers, but you don’t see notifications because recipients resolve to blank or invalid values.

Common causes

• Using dynamic recipients (Contact Email/Phone) but those fields are empty on the asset.

• Email goes to spam/junk or an internal filtering rule.

• SMS recipient formatting issues (country code, invalid number).

What to check

• In Send Email / Send SMS, confirm:

  • Recipient(s) are present (either static or attribute-driven)

  • The attribute you selected maps to populated fields in Asset Details

---

Fix patterns (pick the one that matches your intent)

A) “I only want one alert per incident”

Use:

• Suppression: Until False

• Ensure the condition can resolve (false) when the incident ends

Example:

• Temperature returns to normal, then breaches again later → new alert triggers

B) “I want reminders while the issue persists”

Use:

• Suppression: Until Custom Timeout (e.g., every 60–120 minutes)

• Include asset identifiers and key telemetry values in the message body via Variable Inspector

C) “I want a separate ‘Resolved’ notification”

Create a second workflow:

• Condition: the opposite state (e.g., Temperature back within range)

• Actions: send “Resolved” notification