Ignition Alarm Pipeline, dynamic / scripted jump

is it possible to have inside an alarm pipeline a scripted / dynamic Jump block?
I have a pipeline which already extrapolates the site of the alarm and I would like to jump to an ad-hoc pipeline named as the site.

currently we have several sites and need to create a single jump for each site and add a jump block each time a new site is setup.
At the moment it seems the jump block allows only to select already created pipelines from a dropdown.


Thank you

1 Like

No, this isn’t possible. You could switch on the property, and have a series of manually added jumps; how often are you going to be adding new sites?

In the old Vision platform we already have a big switch with 50+ sites which makes navigation in the Pipeline difficult, in the new Perspective platform we will reach that number very soon so I hoped we could make things tidier this time with a dynamic jump and a separate pipeline for each site.

Ouch. Yeah, it’s not currently possible; I’d suggest filing a feature request on ideas.inductiveautomation.com, but that won’t help you out much in the short term.
What’s different between these 50+ sites? Do they all actually need separate pipelines? Maybe some could be consolidated and use dynamic rosters/calculated rosters?

We could probably consolidate some pipelines, but it would then be more work to realize each time which pipeline does what and then merge/split pipelines accordingly, in the end it’s easier for us to copy a standard pipeline each time a new site is added and specialize it when needed.

Thank you I’ll post in the feature request, I just wanted to make sure it is currently not feasible.

1 Like

I wanted to bring this topic back to life because there is a specific case why a scripted jump might be necessary. When you have only 1 general/global pipeline that uses dynamic/calculated rosters for different sites, I have seen the case where an alarm from Site A gets queued for calculated Roster A. Then shortly after an alarm from Site B occurs (within the consolidation timeframe) and queues calculated Roster B. Alarm A clears and drops out, but Alarm B persists past the consolidation timeframe and notifies Roster B but it contains alarm B information as well as alarm A information. I think this is because even though the first alarm dropped out, the notification pipeline is still active from the second alarm...and because it is still just 1 global pipeline it doesn't disassociate one notification from another. Creating an individual Notification Block for each site and using a Switch block...or creating a new pipeline for each site can prove inefficient when the number of sites grows (and looks messy). Especially if you want to make a change to the pipeline logic.

If perhaps there was a way to instantiate an array/list of notifications on the fly....or create new pipelines based off of a template...that might help.

If there is anyone that has implemented this in a different fashion, I'm sure there are others that would like to know how it was done.