Please note that VisualCron support is not actively monitoring this community forum. Please use our contact page for contacting the VisualCron support directly.

We want to pass a parameter to a task, but this parameter is different when a task is started manually.

For example:

When the task is started by a trigger we want to pass the Trigger name to the task, this works by putting {TRIGGER(Active|LastTrigger|Desc)} in the "Arguments".

When the task is started manually we want to pass the string "Manually" to the task.

Is there any way to achieve this?

Thanks in advance,
Forum information
No, not in an easy way right now. I move this topic to "Feature requests" and we'll see what we can do.
Please like  VisualCron on facebook!
John Vaden
It looks like this topic was last updated about 13 years ago. Has anything changed since then? Is there a way to determine if a job or task was started manually or via a trigger?
There's a {JOB(...|StartReason)} now, but I haven't tried to determine what its results can be, and without poking at it I don't know whether it's guaranteed to return the start reason of the current execution if the job is able to run more than once concurrently, particularly since it doesn't have the hint "Only available at runtime" when viewed in the Variables window. Might be worth experimenting with.
IT Support
From what I can see in testing the "StartReason" variable is not available until after the job has completed, it instead grabs it from the last time the job run.

This would be a great feature we have a signoff task on each job that we only want to run if the job was triggered by the system, we want it to skip that task if the job is manually run.
I just remembered I have a job where I wanted to do something at least vaguely related to this. It isn't perfect and doesn't scale well if the job has multiple triggers, but for my purpose it was adequate.

The trick is that, at least to a certain degree of precision (for my purposes the minute was good enough), the LastRun value of the job will be equal to the LastRun of the trigger that started it. Obviously this falls down if the job is run manually within that precision of when it was scheduled; also, I didn't check this case for whether the job's LastRun can update during execution if it is run again in parallel, because if that happens with this job it isn't really a big deal.

Just an idea, in case that's good enough for your use case as well.
Scroll to Top