Plexara
What you will take away from this lesson
A saved script runs. There is no approval step and no state in which a script exists but nothing may execute it: the version you saved is the version that runs, whichever of three triggers asks for it. This lesson covers the three, what each one records, and the guarantees a schedule makes about the runs it produces.
The runs in the two previous lessons were all asked for from a session. Here the same script gets a Monday morning cadence on the demo tenant, and the answer the platform gave when it was set is the shape of everything a schedule promises.
Learning Objectives
- 01Run a script from any session with one call, follow a long run’s progress, stop it, and read its result later by its run id.
- 02Run it from the script’s page, where Run and Dry run sit above the editor and one form built from the parameter contract serves both, and grant its runs to a persona, a role, or an API key.
- 03Set a cadence in the portal’s builder or with the agent, in a timezone, and read it back in words.
- 04Use ${fire_date} and explain why the script has no clock of its own.
- 05State what a schedule guarantees: one schedule per script, one fire is one run, an overlapping fire is recorded as skipped, a gap produces one run for the latest fire, a failed scheduled run emails its owner with its cause, and the platform never re-runs a failed run on its own.
- 06Read the Automations page with its Schedules and Runs tabs and a script’s run history, and know why a script’s schedule lives in Plexara while a prompt’s schedule lives in the agent.
Where this lesson sits
The series script writes the outputs from 603. This lesson is about what makes it run: the three triggers, the cadence that turns a script into an automation, and the record every run leaves. The next lesson covers the authority each of those runs carries.
600 Series: Automations
- 601Do not spend AI on what a script can doThe automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.
- 602The agent writes the first scriptThe loop from a recorded draft through tests to the save, what a save requires, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.
- 603Outputs: feeds, reports, and dashboards that refresh themselvesOutput identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.
- 604Running it: by hand, from the portal, and on a scheduleThree triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.
- 605What a run may do, and the record it leavesThe authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.
- 606Scripts as skills: the weekly review the agent runs on your businessThree scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.
- 607Events in: a webhook source, its table, and an automation that reads itCreating a source, how a sender proves itself and what it is told, the table that serves events from acknowledgement, compaction and retention, the Webhooks page, and an automation that reads only what is new.
- 608Results out: notification channels and signed delivery to other systemsChannel kinds and who may send to them, sending from a session and from an automation, the delivery history and the retry rule, the JSON envelope a system routes on, signed requests, and delivery to another deployment.
The 600 series picks up the registered table from the 500 series and the prompt mechanics from the 400 series. It is the last numbered series in the curriculum.
Three triggers, one run
A run is asked for in one of three ways, and the run itself does not care which. The platform executes the latest saved version, as the script’s own principal, and records which trigger asked.
Three triggers, one run
From any session
trigger: toolThe owner, an administrator, or anyone the owner granted runs to, through the agent
You ask for it in plain language and the agent calls run_script with the script’s name and its parameters. The values are checked against the contract before anything is queued, and the call waits for the result.
From the script’s page
trigger: portalThe script’s owner, or an administrator
Press Run on the script’s page. The form is built from the parameter contract, so a date gets a date picker, an enum gets a choice, a list of choices gets checkboxes, a date range gets two dates, and a connection gets the set the script may reach.
On a schedule
trigger: scheduleNobody; the cadence fires it
A cadence, a timezone, and the values every fire binds. When it is due, Plexara runs the latest saved version with those values, whether or not anyone is connected.
The three execute identically. Every run executes the latest saved version as the script’s own principal, presenting the roles its author held at the save, and the only difference in the record is the label saying which trigger asked. A script taken out of service, disabled, deprecated, or superseded, is refused by all three in the same words.
An owner can grant a script’s runs to a persona, a role, or an API key from the Access card on its page. A grant decides who may ask for a run, never what the run may reach. Events other systems send reach a script a fourth way: they land in a webhook source’s table as they arrive, and a scheduled script reads that table like any other. 607 covers that path.
Running one from a session
The common case is a person who wants the output now. You say so to the agent, the agent calls the script by name with the values it needs, and the answer comes back with the run’s record: the version that ran, how long it took, the outputs it wrote, and the log. The trace below is the first real run of the series script, acme-supplier-margin.
One run from a session, with the real answer
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
run_script
name acme-supplier-margin
args {"month": "2025-12-01", "conn": "acme"}
wait_seconds 120
-> status succeeded
trigger tool
version 3
duration_ms 8542
run_id dpx_88dfb063…
outputs supplier-margin-by-category asset 871da875… version 1 (csv, 50 rows, 3,404 bytes)
supplier-margin-feed asset 589855b4… version 1 (json, 1 row, 27,660 bytes)
log supplier margin review for 2025-12-01 to 2026-01-01
categories quoted: 50, weighted cost change 2.57%
largest increase: Flowers & Plants 14.800%
at-risk SKUs under 20% projected margin: 25
coverage: 400 of 450 quotedThe call waits up to two minutes by default and at most five. A run that outlives its window keeps going: the answer carries the run id with a pending status, and the agent reads the result when it finishes with manage_script get_run. Asking for a run that should not wait at all queues it and returns at once. Either way the run executes on Plexara, so a long report does not hold the agent’s session open and a run in progress survives a platform upgrade.
Running one from the script’s page
The owner of a script runs it from the script’s own page, without an agent in the loop. Everything the run needs is already on that page: the saved code, a form built from the parameter contract, and the history the run will appear in.
Running from the script’s page
- 1
Run and Dry run sit above the editor
Run executes the saved version. Dry run executes what is on screen, as you, with tighter limits and nothing persisted. Both are on the page the owner already reads the script on.
- 2
One form serves both
The parameter form below the editor is built from the script’s contract: a date picker for a date, a choice for an enum, the set of reachable connections for a connection parameter. It supplies the values for a run and for a dry run alike.
- 3
The history re-reads itself
The run appears in the history under the code and updates as it progresses, with the script’s latest progress report and the log printed so far. A queued run can be canceled and a running one stopped, keeping what it already wrote. A value the script handed back shows as its Result.
A run asked for here and a run asked for by the agent are the same run in every respect except the trigger label. The page cannot widen anything: the run is authorized at every call against the roles captured at the script’s last save. And it cannot run what the platform would refuse, so a disabled or retired script says so instead of offering a button that cannot work.
The cadence
A schedule is what turns a script into an automation: a cadence, a timezone, and the parameter values every fire binds. It is set on the script’s page, in a builder that asks for the cadence the way a person has it in mind, or by the agent in one sentence. Both produce the same row, and the Automations page states it in words either way.
Setting a cadence: the builder, or a sentence to the agent
- Hourly, daily, on weekdays, on chosen days of the week, or on a day of the month
- A time, and the timezone the time is read in
- The values every fire binds, checked against the parameter contract when the schedule is saved
- A Custom field for an expression the builder cannot express; an expression the agent wrote opens there as itself
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
manage_script command=schedule_set
name acme-supplier-margin
cron 0 7 * * 1
timezone America/Los_Angeles
args {"month": "2025-12-01", "conn": "acme", "mode": "refresh"}
-> enabled true
cron 0 7 * * 1
timezone America/Los_Angeles
next_run_at 2026-08-31T14:00:00Z
missed_fires 0
message "The platform will run the latest saved version on this cadence,
with these parameters, as the script's own principal presenting
your captured roles."The portal asks for a cadence in the terms a person has it in and derives the expression, showing it rather than asking for it; the Automations page then states it in words, as “Every Monday at 7:00 AM, America/Los_Angeles”. The agent sets the same thing with a cron expression or a descriptor such as @daily, and the answer above is what came back on the demo tenant. A cadence is read in its timezone, so a report stays on its wall clock across a daylight-saving change. A script has at most one schedule; setting it again replaces the cadence in place. Pausing and resuming are their own actions, and a schedule is never deleted, only disabled, so the runs it produced keep the row that explains them.
The date of the fire
A scheduled report almost always needs to know what day it is. The dialect deliberately gives a script no way to ask, and the schedule supplies the answer instead.
Pausing and resuming
A schedule is paused and resumed from the header of the Schedule section on the script’s page, or by the agent. Pausing is its own action rather than a field of the cadence, so resuming does not re-base the fire it resumes on, and nothing is ever deleted.
What a schedule guarantees
Eight rules govern the runs a schedule produces. They are what let you trust a number that arrived on a Monday morning nobody was watching.
What a schedule guarantees
- 01
One schedule per script
Setting it again replaces the cadence in place and keeps the run history that points at it. A second cadence over the same code is a second script.
- 02
One fire is one run
A fire produces exactly one run, however the platform is scaled underneath. Nothing about a fire is duplicated.
- 03
An overlapping fire is recorded as skipped
A fire arriving while the previous run is still going does not queue behind it. It is recorded as a skipped run, so the skip appears in the history rather than as silence.
- 04
One run at a time, when it is set
Runs started by hand have no schedule and may overlap one another or a scheduled run. A script whose runs send data somewhere or move a cursor is set to run one at a time: while a run is open, Run is refused naming that run and a fire is recorded as skipped.
- 05
After a gap, one run for the latest fire
When fires could not be materialized for a while, one run is produced for the most recent fire that has come due, and the fires before it are counted as missed on the schedule. A catch-up burst of stale reports would be worse than a visible gap; a backfill somebody wants is a run by hand with the parameters they want.
- 06
A paused schedule resumes on the fire it was parked on
While it is paused it reports no next run. The fire it resumes on collapses to one run under the same rule as a gap.
- 07
A failed scheduled run emails its owner
The mail carries the run id, the failure, the tail of what the script printed, and whether the next run is expected to pass. When three or more runs in a row have failed on the same error, it says the script needs correcting. The owner’s agent is also told about failing automations at the start of the next session. A run asked for by hand is not mailed, because its failure is already in the answer its caller is reading.
- 08
A failure is classified, and never re-run on its own
Every failed run carries its cause: the script, a service it called, memory, or the platform. A service that was briefly unavailable is recorded as that service’s failure, not the script’s, and the next fire is expected to pass. A temporary warehouse read failure is tried again inside the run, a few times, before it counts. The platform never re-executes a failed run, because a run that already wrote must not be repeated on a guess. A run that could not start because of a platform fault is put back on the queue.
The record a run leaves
Every run, whichever trigger asked for it, records the same things, and the portal shows them at three levels: the Automations page for the state of everything, its Runs tab for every run newest first, and a run’s own page for one run in full.
What one run records
- Trigger
- tool, portal, or schedule: which of the three asked for the run, and who requested it.
- Version
- The saved version that executed, which is the version that was latest when the run was queued.
- Duration and outcome
- When it started, how long it took, and whether it succeeded, failed, was canceled, or was skipped as an overlap. A failure carries the error, the line it failed on, its cause, and whether running it again is expected to help.
- Progress and result
- A running run shows the script’s latest progress report. A value the script handed back is kept on the run as its result.
- Outputs
- Each output by name, linking to the asset version it produced. An output delivered to a drop names where it was written instead.
- The log
- What the script printed, kept to 64 KB with the head preserved.
A year of run history is kept. A script’s page shows its most recent runs with a rollup in the header: the share that succeeded, how many failed, were skipped, or were canceled, and the median duration. The Automations page has three tabs: the automations, a Schedules tab that draws when every scheduled script fires, and a Runs tab with every run newest first and the reason a run failed in the row rather than behind it. Anyone signed in sees how each run went; what a run was given, printed, and wrote stays with the owner, administrators, and whoever requested that run. The agent reads the same records with manage_script command=runs and get_run.
Why a prompt’s schedule lives in the agent and a script’s lives in Plexara
Lesson 404 said that scheduling a prompt is not a Plexara feature at all. This lesson has just described Plexara scheduling a script. Both statements are true, and the difference between them is the difference between the two kinds of saved work.
Scheduling a prompt, scheduling a script
- Who keeps the clock
- Your agent: an in-session loop, headless plus cron, a desktop task, a cloud routine.
- Plexara. The cadence is a row on the script, fired by the platform.
- What a fire needs
- A model. A fresh session starts, connects to Plexara, and runs the prompt by name.
- Nothing. No model, no session, no tokens; the platform executes the saved version.
- What varies between fires
- The model’s reading of the instruction, which is the point of a prompt.
- Only the data. The script contributes no variation of its own.
- Where the record lives
- In the asset the prompt saved, and the agent’s own session log.
- On the run: trigger, version, duration, outputs, log, kept for a year.
Lesson 404 explained why a prompt’s schedule lives in the agent: a prompt is an instruction, and running one needs a model to read it. A script needs none, which is why its schedule lives in Plexara and why the 606 capstone puts the two together: a schedule keeps the scripts’ outputs fresh, and a prompt tells the agent what to make of them.
From a run to its authority
Three triggers, one schedule, one record. The script on the demo tenant now fires every Monday at seven, refreshes its dashboard, and writes a run record nobody has to be awake for.
Key terms
Five terms cover how a script comes to run and what it leaves behind.
Key Terms
- Trigger
- Which of the three producers asked for a run: tool for run_script from a session, portal for the Run button on the script’s page, schedule for a fire. Recorded on the run; the three execute identically.
- Cadenceschedule
- A cron expression or a descriptor, a timezone, and the values every fire binds. One per script; set in the portal’s builder or by the agent; paused and resumed rather than deleted.
- Fire
- The moment a cadence comes due. One fire is one run. A fire arriving while the previous run is still going, or while any run of a one-at-a-time script is open, is recorded as skipped; after a gap, one run is produced for the latest fire.
- ${fire_date}
- The one token a schedule’s bound values may carry. It expands to the date of the fire in the schedule’s timezone and is recorded on the run, which is why the script needs no clock.
- Run record
- Trigger, version, duration, outcome and its cause, outputs linking to the asset versions they wrote, any result, and the log. Read on the script’s page, on the Runs tab, and by the agent; kept for a year.