Hi,

I have a couple of time exclusions set up, and one job with a condition set up. What I'm wondering is, is there a way to flag a condition or exclusion as "global" vs "job"? The condition I have set up is only relevant to the job in which it's set up, yet all other jobs are able to see it (though it's not enabled in the other jobs). The problem is that I don't want any other jobs to be able to see it, because enabling it for the other jobs would literally be completely useless since the condition refers to a variable in the job it's configured for. The condition checks the result of an SQL query and only runs the rest of the job if there's at least one row in the result; enabling this condition in a different job would likely cause the different job to fail (or run successfully, but produce no results), because there would be no rows in the results, because the job it refers to isn't running. I honestly can't think of any situation in which I'd want a condition from one job to be visible by another job, but I suppose other businesses might have those types of scenarios.

As for time exclusions, I was quite pleased to see that they're visible to all jobs. I've set up two exclusions ("do not run during our nightly maintenance window from 1:45am to 5:45am" and "do not run on Sundays"), which would apply to pretty much every job I'd create, so not having to reconfigure them separately for each job is a huge bonus. But I suppose there might be situations where I'd want an exclusion just for a particular job, in which case I'd have the same situation as described above with the conditions.


Thanks.

As far as I know, conditions are truly global and there is nothing you can do about it. I use those for generic conditions, eg check output of PrevTask and if nothing stop/continue.

For private type of conditions, try the flow tab. You can check output from a task or a variable and then decide what to do.

Thanks, that looks like it might do what I want. I haven't tested it, but it seems like I could set up a flow like this:



Where the variable is the number of rows returned by my SQL query, and I'd put that in the Flows section of that query task.

Seems about right to me. If possible, you should use ActiveTask or PrevTask instead of a particular TaskId whenever possible. It makes it more generic and easier to read, and if you have to move jobs from say prod to test, there is fewer things that can go wrong.