Thresholds in OpCon look similar to Resources on the surface, but they serve a fundamentally different purpose. While resources control how many jobs run concurrently, thresholds are condition flags. They let you build OpCon automations that respond to dynamic states: "Run this job when that number reaches a certain value." Once you understand thresholds, you'll find uses for them in several places.
What Is a Threshold?
A threshold is a named object with a numeric value. Unlike resources, thresholds are not automatically managed by OpCon. Their value stays exactly where you set it until something explicitly updates it. That update typically comes from an OpCon event, an API call, or an external system interaction.
Thresholds are found in the same place as resources: Administration > Library. Create one with a name and starting value (often 0).
Threshold Dependencies: Flexible Condition Logic
When you add a threshold dependency to a job, you're telling OpCon: "Only run this job when the threshold meets a specific condition." The condition can use a variety of operators:
- Equal to (=)
- Greater than (>)
- Greater than or equal to (>=)
- Less than (<)
- Not equal to (<>)
This flexibility means you can trigger jobs at a specific count, after a count is exceeded, or even when something drops below a threshold. Whatever your process logic requires, there's an operator for it.
Updating Thresholds with Events
Jobs update thresholds using the Threshold Set event. You can either set the threshold to a specific hard-coded value or increment/decrement it. For example, configuring an event to add +1 to a threshold every time a job runs lets you track how many times that job has executed and trigger downstream jobs at specific counts.
Real-World Use Case: Triggering on a Repeating Job’s First Run
Here's a scenario that thresholds solve: you have a job that runs multiple times throughout the day (configured to restart and repeat). You need a second job to kick off after the first job runs for the first time, but you don't want to wait until all restarts are complete.
A standard job dependency won't work here. Job dependencies wait until the dependent job reaches a final completed state, and if that job is configured to restart, the final state doesn't happen until end of day. By using a threshold instead, the first job increments a counter each time it runs, and the downstream job is set to trigger when the threshold equals 1 (or exceeds 0). The first run triggers it, and subsequent runs don't re-trigger it because the condition is already met and the job has already run.
Important: Thresholds Must Be Reset
Unlike resource units, which OpCon releases automatically, threshold values persist indefinitely. If your process runs tomorrow and the threshold from today's run is still sitting at 10, your downstream jobs may fire immediately or never, depending on their conditions. Build threshold resets into your workflow, typically at the end of the process or at the beginning of the next run. The reset value depends on your use case (0, 1, etc.).
Summary
Thresholds are one of OpCon's most versatile tools for building condition-aware automation. Whether you're coordinating repeating jobs, counting file arrivals, or linking process milestones, thresholds let you express complex "run when this is true" logic without tangled dependency chains. Just remember that they don't reset themselves, so build that into your design from the start.