Generally with a third party scheduler or with inbuilt scheduler in wf we can configure when and how a wf can be run, i think it also gives us the flexibility on the number of runs. You need to mention the start and end times and no.of runs.
Even if you trigger the job from a shell script we can write the code accordingly to run it as many times as possible or limit the runs.
Not out of the box, but you could implement something like this:
Create a new first session (named, for example, "s_m_checkDailyExecutions") which queries some audit table for how often this workflow already has been running "today". If this number exceeds a certain threshold (let's say 10, but this limit could be indicated by some other DB table as well), no output record is produced; if this number is still below the threshold, create a dummy output record (e.g. write it to /dev/null on Unix/Linux or to $PMTargetFileDir\NUL on Windows).
Now set up a link condition from this first session to the first "real" working session in your workflow; the workflow link has a condition similar to this example:
$s_m_checkDailyExecutions.Status = SUCCEEDED AND
$s_m_checkDailyExecutions.TgtSuccessRows > 0
Then the following session(s) will be executed only if the first mapping has produced some output (meaning the total number of executions of this particular workflow run "today" was low enough).