SCHEDULED RUNS · IN Binse AND Binse ENTERPRISE · V2026.9.16.3
Unattended runs, and the catch.
Scheduled runs are included in Binse and in Binse Enterprise. A schedule runs a flow you have already built, refreshes a dashboard whose numbers are a day old, or refreshes a diagram and delivers it, at a time you pick, with no window on screen and nothing to remember.
It uses the scheduler Windows already ships, under your own account. There is no service to install, no service account to ask anybody for, no password stored anywhere, and no administrator prompt. The price of all of that is printed beside this paragraph rather than discovered on day three.
THE SCREEN
One page, two lists.
The schedules at the top, the runs they have already made underneath. Each schedule row says what it runs, when Windows will next run it, and how the last run ended. The line beneath the list is the product's own wording, not ours.
01 · WHEN IT RUNS
Six triggers.
One trigger to a schedule. Four of them are clock triggers, one watches a folder,
and one is no trigger at all. Whichever is chosen, what Windows is told is a single
schtasks line with no /RU flag, which is what makes the task belong
to the person who made it and run only while that person is signed
in.
The product's own New schedule form, with its six triggers, its field limits and its refusal messages. Change anything and watch what Binse would hand to Windows. Nothing on this one is timed or counted: every character below is either something you typed or a fixed function of it, so you can check it by installing the product, making the same schedule and running schtasks /Query /TN yourself.
what Windows is told
the file it saves, beside your workflows
The task folder prints as Binse Hub, which is the old internal name for scheduled runs. That is what the product writes today, and correcting it only here would falsify the one string you are being invited to go and compare. It is on the list to fix in the product.
| Trigger | Fields it uses | What Windows is told |
|---|---|---|
| Only when I run it | none | nothing is scheduled |
| Every few hours | every | /SC HOURLY /MO 1 |
| Every day | at | /SC DAILY /ST 03:00 |
| Every week | days, at | /SC WEEKLY /D MON /ST 03:00 |
| Every month | day, at | /SC MONTHLY /D 1 /ST 03:00 |
| When a folder changes | folder, pattern, every | /SC MINUTE /MO 1 |
A time is given as HH:MM. An hourly schedule runs every one to twenty-three
hours. A monthly schedule takes a day from one to twenty-eight, so that the schedule exists
in February too: a run that silently skips a month is worse than one that runs three days
early. A schedule with no trigger keeps its name, its steps and its history, and waits for
the Run now button.
The folder trigger is a poll, not a watch
Windows starts a check on the interval you choose, the runner compares what is in the folder now with what it saw last time, and does nothing when the answer is the same. Nothing of ours sits resident on the machine, which is the promise, and the cost is that "when the file lands" means "within the interval that was chosen".
Two consequences worth knowing before relying on it. Every check is a run, so a check every few minutes writes a skipped row to the history every few minutes. And the signature a check compares includes each file's size and modification time, so a large file still being copied in looks like a change and can fire a run while it is half there. Where that matters, have the sender write to a temporary name and rename it when it is finished.
02 · WHAT IT RUNS
Three kinds of step.
A schedule is a list of steps. They run in order and stop at the first failure. That is the whole model, and it is what makes a chain sensible: if the flow that rebuilds the figures fails, the dashboard that reads them is not refreshed, and nobody is sent a file full of yesterday.
Run a flow
One of your saved flows, by name or by full path. It goes through the same engine the Run button in Data Flow calls, after the same preparation: parameter values substituted, the Interface tools' actions applied, then macros expanded. There is no second way of running a flow, which is the point, because caching, containers, macros and parameters then behave the way they do when the button is pressed by hand.
A schedule can supply a value for any parameter the flow declares. Leave one out and the flow's own default is used, and on a Date tool that default can be a moving one, worked out afresh on every run. That is why a month-end flow does not need a second copy of itself for last month. What the step records afterwards is how many tools ran, how many rows the output tools wrote, and how many tables were published to Dashboards.
Refresh a dashboard
One of your saved dashboards. Every table it uses is read again from wherever it came from, so the dashboard is current when somebody opens it rather than current as of the last time the person who built it opened it. Refreshing on its own changes nothing anybody can see until the dashboard is opened. To send it to people who do not open the app, add a delivery.
Refresh a diagram
One of your saved diagrams, and it has to be one with data behind it. The step opens the diagram, reads its data sources again, writes the rows into the shapes bound to them, runs the diagram's rules again so the drawing recolours, recomputes any chart inside it, saves it and, if the step says so, delivers it. All of that happens with no browser and no window, and a source that cannot be reached is named in one sentence in the run history rather than counted as a mysterious failure. A flow that writes a file in step one and a diagram bound to that file in step two need nothing else to make the pair work.
03 · DELIVERY
One format for a dashboard, three for a diagram.
A dashboard step can write the refreshed dashboard out as a single HTML file, to a folder or to a path. That file opens in any browser with nothing installed, keeps its filters and its cross-filtering, and contacts no third party and no host except the one the file was opened from. The person who opens it needs no licence, no account and no seat, because there is nothing in it to sign in to.
What delivery is
Give a folder and the file is named after the dashboard. Give a path ending in
.html and that exact file is written. Folders that do not exist are created.
The file is overwritten every run, on purpose: the path stays the same, so a link somebody
has bookmarked keeps working and holds this morning's numbers. A copy per day is a job for a
flow step that writes the date into a path, not something the delivery keeps for you.
Two refusals, both deliberate. A dashboard built against a design sample of a large table is not delivered, because a sample must never reach somebody with no way of knowing it is one. A dashboard that uses a table which is no longer registered fails rather than delivering a file with holes in it.
A diagram goes out in one of three
A diagram step delivers the refreshed diagram as a single web page, as SVG, or as PDF, a file per page. All three are written by the Diagrams command line with no browser anywhere near it, which is the same test the dashboard format has to pass. The picture formats, PNG and the rest, are drawn by a browser, so a schedule that asks for one is refused when it is saved, with the reason on screen, rather than failing in the middle of the night.
What delivery is not
For a dashboard, there is no PDF and no PowerPoint. In this product both of those are assembled from pictures of the dashboard pages, and the browser is what takes the pictures. A scheduled run has no window, so it has nothing to photograph. Rather than ship half of it, the format is not offered, and a schedule that asks for one is refused when it is saved. A PDF or a deck made by hand from the Export button in Dashboards is unaffected, and a single file prints from the browser with Ctrl P, which is most of what a PDF was wanted for.
There is no email delivery either. A scheduled run writes files to folders and shares, and nothing else. Sending mail is the subject of section 05.
04 · THE RUN HISTORY
A CSV you can chart yourself.
Every run writes one row, including the runs that did nothing. The log is a CSV file, and that is a decision rather than an implementation detail: it loads into Dashboards like any other file, so the answer to "is all of this still working" can be a dashboard built once, instead of an admin console somebody has to write.
run_id,job_id,job,trigger,started,finished,seconds,status,steps,rows,error
That is the header the runner writes. trigger says schedule when
Windows started the run and manual when a person did. job_id
survives the schedule being deleted, so last month's evidence does not disappear with it.
The runner is the only process that ever appends to the file, which is what makes it safe to
read while it is being written.
Three results. done means every step finished. error means a step
failed and the steps after it did not run, with the message in the words the engine used.
skipped means the run started and there was nothing to do, because the schedule
is switched off or a folder trigger found nothing changed.
And what the history does not hold
Older rows are trimmed once the log passes the length the runner keeps, and the detail file of each trimmed run goes with it. The history lives under Local AppData rather than in Documents, because it is derived: copying schedule files to a rebuilt machine brings the schedules across and starts the history again. Nothing in the app charts the log for you. It is a file, and charting it is a dashboard you make.
05 · WHEN IT FAILS
Notification is a flow of your own.
There is no alert setting here, no mail server field and no mailbox password. The flow engine already carries a Send Email tool in its Developer category, so "tell me when this breaks" is an ordinary flow, and a schedule nominates one to run when a run fails. Scheduled runs own no SMTP and no OAuth code of their own, and one implementation is better than two.
The nominated flow is handed four parameters: $Job, the name of the schedule
that failed; $Error, the same message the history holds; $Run, the
run identifier, which is also the name of that run's detail file; and
$Started, when the failed run began. Put them in the subject and the body and a
failure becomes an email. Point the flow somewhere else and the same failure becomes a row
in a log table, a webhook call, or a line appended to a spreadsheet somebody reads on a
Monday.
Three things to know before relying on it
The notifier is not itself a run in the history. It gets no row, and nothing in the app reports on it.
Its own failure is swallowed. If the notifier breaks, the failed run is still recorded correctly, because losing the record of a failure because the alarm was broken is the worse of the two outcomes.
Which together mean it has to be tested by hand. The Send Email tool ships with Do not actually send ticked, deliberately, because sending is the one thing in the palette that running a flow again cannot undo. A notifier that has never had that box unticked will report a failure perfectly and post nothing.
06 · SPECIFICATION
Claim, figure, method.
The same facts as the sections above, in the form somebody evaluating this for a team would rather read. The method column names the file the figure was read from.