From a dashboard

A dashboard can run an automation, show how the run is going, and show what it produced. An app can do the same and collect the files it reads.

The opt-in

An automation is reachable from a dashboard only when it carries the From the app trigger. That node is the whole of the permission: without it, every automation in a space would be one request away from any dashboard the space ever published, which is not something anybody agreed to.

Add it alongside whatever else starts the automation. A schedule and a button together is one automation, not two. See Triggers.

An automation that runs only on its own clock can still appear on a dashboard, through the table it writes. What it cannot have is a run button.

Building the page

Ask for it while you build the dashboard, or afterwards in the assistant. Say what the control should do and the page is written with:

• The run button, disabled and working from the moment it is pressed.
• Each step as it happens, with its name and status, so a run of several minutes does not look like a page that froze.
• The elapsed time, the error if there is one, and a way to try again.
• The table the run fills, re-read when the run finishes.

That last point is the one worth stating, because it is where a page most often looks broken when it is not: an automation writes on the server, so a finished run does not refresh what is on screen by itself. The page has to re-read the table, and one built for you does.

Files people drop on it

An app can collect the documents an automation reads. Somebody attaches files to the page, they are listed before the run starts, and the run reads exactly those.

• Attach what there is, then run once. Uploading three files and pressing run three times pays for three passes at one job.
• The attached list is shown before the button, and each can be removed. It is the only way to tell that the right file is attached, and correcting rows afterwards costs a run.
• Up to 100MB a file. PDF, CSV, XLSX, XLS, DOCX, DOC, TXT, PNG, JPG and JPEG.

Files uploaded for a run belong to that run. A folder of documents is different: each is taken once, by whichever run reaches it first, and remembered afterwards. See Steps.

A published dashboard

Publishing a dashboard that runs an automation does not, by itself, let its readers run it. A run spends credits and cannot be undone, so it is gated twice over:

• Somebody has to be named. A signed-in reader is. An anonymous visitor is not, and is asked to sign in.
• Or you allow anyone to. Turn that on in the dashboard's publishing settings, and then anyone who can open the page can start a run. It is off until you do.

Either way, runs are rate limited per caller, and the automation's owner is who the run is billed to. See Publishing.

Copies

Duplicating a dashboard, app or report copies its automations too. The copy is genuinely its own: changing it does not change the original.

What a copy deliberately does not carry:

• Where it was up to. A copy starts fresh rather than already caught up, or it would read nothing on its first run.
• The table the original made. A copy writes its own, rather than into the original's.
• The schedule. A copy does not start firing alongside the automation it came from.
• A webhook's secret. Type a new one on the copy.

Copy an artifact into another space and any table its automations read that did not come with it is left blank for you to point at, rather than pointing across a boundary.