Plexara
What you will take away from this lesson
A script runs when nobody is watching. That is the point of it, and it is also the reason the question of what a run may do has to be answered before the first schedule fires. The answer on Plexara is short: a run may do exactly what its author could do at the keyboard on the day the version was saved, and every step it takes is written down.
This lesson is the governance half of the series. It covers the authority a run carries, the things a save refuses before anything is stored, why the language itself cannot reach outside the platform, the lifecycle of a script, who sees what, and the view an administrator gets of all of it.
Learning Objectives
- 01State the authority rule: a run presents the roles its author held at the save, every call is authorized at that moment, and narrowing the persona takes effect on the next run.
- 02Know what a save refuses: a credential-shaped literal, source that does not parse, and a destination Plexara does not have.
- 03Explain why a script cannot reach out: no network, no filesystem, no clock, and every action a platform call audited under the script’s own identity.
- 04Read the lifecycle, active through disabled, deprecated, and superseded, and what each state does to runs and schedules.
- 05Know who sees what: a script is its owner’s, its output is the team’s.
- 06Understand an administrator’s transfer of ownership and what it changes, and find the administrator’s view of every script and every run.
Where this lesson sits
Lessons 602 through 604 built a script, gave it outputs, and put it on a schedule. This lesson steps back and asks what that schedule is allowed to do while nobody is watching, and what it leaves behind so that somebody can check later.
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 create to save, 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.
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.
What a save refuses
Some mistakes are caught before a version exists at all. A save is the version that runs, so the checks that protect a run happen at the keyboard, where the author can fix the problem, rather than at the next fire.
Three things a save refuses
A credential-shaped literal
At validate, before the save.
A private key header, a cloud access key id, a well-known token format, or a URL with a password in it blocks the save. A variable merely named like a secret is a warning, so the paste is caught and the false alarm is not fatal. Scripts name connections; Plexara holds the credentials.
Source that does not parse
At the keyboard, on the portal editor or the agent’s save.
Code that cannot run is refused rather than stored, so the failure surfaces while somebody is looking at it instead of at the next fire. A script that does not parse is not a draft.
A destination Plexara does not have
At validate, named in the words the run would use.
An output addressed to a bucket drop that has not been set up for your deployment is reported by validate, so it fails while the author is iterating rather than after a real run has already spent its queries.
Why the language cannot reach out
The dialect a script is written in is deliberately small, and the absences are the security model. A script has no way to open a connection, read a disk, tell the time, or pull in code, so the only outside world it has is the platform, and the platform records everything it is asked to do.
Why the language cannot reach out
No network
A script opens no socket and supplies no endpoint. An external API is reached only through a connection Plexara already holds, with platform.call, so what a script can reach is what its author can reach.
No filesystem
A file is read through the registered table or a platform call, and written as an output. Nothing lands anywhere the platform does not record.
No clock, no randomness
The fire time is pinned on the run, so the same version with the same parameters asks the same question. A run nobody can reproduce is not a governed run.
No imports
json and date are the whole module surface. There is no way to pull code in from outside, so the source on the version is the whole program.
Everything a script does is therefore a platform call, over the same governed path an agent’s call takes, and every one of them is audited under script:<name>. A run’s reach can be read from its source before it runs, which is what validate reports, and its record is complete after.
The lifecycle
A script is in one of four states, and the state is the only thing that decides whether a run is admitted. There is no approval queue between a save and a run; the trade for that is a lifecycle that can take a script out of service in one action and says so wherever the script is shown.
The lifecycle of a script
- 1
Active
The saved version runs: from any session, from the Run button, and on its schedule.
- 2
Disabled
Nothing executes it. The run gate refuses in its own words on every surface, and a cadence set on a disabled script saves and stays inert, which the tool and the page both say plainly.
- 3
Deprecated
Taken out of service and marked as such. The record stays; runs are refused.
- 4
Superseded
Retired in favor of a named replacement. The reference to the old script still resolves, and says which script replaced it.
There is no approval step and no state in which a script exists but nothing may run it. A saved script runs; taking it out of service is the only gate, and a schedule is never deleted, only disabled, so the row that explains past runs stays.
Who sees what
A script is personal. Its owner and administrators see everything about it; anyone else who can see it sees what it says about itself. That is not a limitation to work around: the thing a team shares is the output a script produces, and outputs have the sharing model of every other asset.
Who sees what
Anyone who can see the script
Its details: what it is, what parameters it takes, whether a run would be admitted, and its schedule. The same facts an agent gets when it resolves a reference to it.
Its owner and administrators
The source, the run history, the schedule controls, and the version history with each version’s author and the roles a run of it presents.
Whoever asked for one run
That run: its parameters, outputs, and log, in addition to the owner and administrators.
The team
The output. A script is one person’s; there is no team library of scripts. The dashboard it publishes, the feed it writes, and the shares on them are what everyone else works from.
A prompt that references a script resolves it for the script’s owner and tells anyone else that part of its automation was unavailable. The way a whole team benefits from one person’s script is the way 606 shows: the review it produces is shared; the code stays where it was written.
Ownership and transfer
Because a script is personal, someone leaving the team or changing roles is a real event for the automations they own. An administrator can move a script to another person, and the move changes more than a name on a listing.
Ownership, and an administrator’s transfer
Only an administrator moves a script
From the script’s page, choosing the new owner from the people who have signed in to your deployment at least once. An owner cannot give a script away.
The whole script moves at once
What the owner sees, edits, runs, and schedules, and the history: the new owner reads the run records and dry-run accounts the previous owner produced.
The move is a version, authored by the administrator
From then on a run presents that administrator’s roles. Moving a script to an administrator is how it comes to run with an administrator’s reach.
A name clash is refused
If the receiving owner already keeps a script of the same name, the transfer does not happen.
It is audited
Like every other administrative write, the transfer is recorded in the audit log.
The transfer control
The transfer is done on the script’s own page, the same page the owner reads it on. It is the one thing that page offers an administrator and not an owner.
The record a run leaves
Every run writes a row: the version that executed, what triggered it, how long it took, the outputs it wrote and the asset versions they became, and the log the script printed. Every call the run made is also in the audit log under the script’s own principal. The trace below is the last successful run of the margin script from 604, read back.
One run, and the record it leaves
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","mode":"refresh"}
→ status succeeded version 6 trigger tool duration 8,231 ms
outputs
supplier-margin-by-category csv asset 871da875-cd99-44f9-b6d9-55732b4e9086 version 3
supplier-margin-feed json asset 589855b4-cfe1-4355-af26-ae68cbc5770f version 3
supplier-margin-dashboard refresh asset bab7c8e7-67e6-4561-834a-32524f203fc8 version 2
audited as script:acme-supplier-margin, presenting the roles captured at the save of version 6The run row names the version that executed, what triggered it, how long it took, every output it wrote with the asset version it produced, and the log it printed. The audit log records each call the run made under the script’s own principal. Between the two, a reader six months later can say exactly what happened and under whose authority.
Versions and the dry-run account
The version history is the other half of the record. Each version names who saved it and the roles a run of it presents, and each version carries the account of the dry run that preceded it, if there was one. A version nobody dry-ran is called out as code that first executed unattended.
What a dry-run account holds
- Who ran it, and when
- The author’s own identity, under their own persona.
- How it ended
- Succeeded, or the failure and the line it failed on.
- What it printed
- The bounded log, head kept, tail dropped with a marker when it overflows.
- The shape of its outputs
- Each export’s format, row count, and size, measured without being written.
- Which source it executed
- The account is keyed to the exact source, so it attaches to whichever version later carries that code. A version with no account is code that first executed unattended, and the version detail says so.
The administrator’s view
An administrator sees every script and every run on the deployment, on the same pages owners use, with an owner column and two panels the owner view does not need: the busiest scripts and the fires that were missed.
Every run, across every script
The Runs tab is where a missed fire becomes visible, because a fire that did not produce a run has no row anywhere else. Run history is kept for a year, and older history is still reachable one script at a time.
What is settled
Unattended never means unaccountable. A run does what its author could do, is refused what its author could not, cannot reach anything the platform does not mediate, and leaves a record that names the version, the trigger, the outputs, and every call.
Key terms
Five terms cover the authority and the record of an unattended run.
Key Terms
- Script principalscript:<name>
- The identity a run authenticates as. Audit records it, and the run’s outputs belong to it. It carries the author’s address so the run can act on what the author owns.
- Captured roles
- The roles the author held when the executing version was saved, stored on that version and presented by every run of it. They cannot be set any other way.
- Run gate
- The check that admits or refuses a run. It refuses only a script taken out of service (disabled, deprecated, or superseded), in its own words on every surface.
- Dry-run account
- The record a dry run leaves of itself: who, when, how it ended, the bounded log, and the shape of the outputs, keyed to the exact source that executed.
- Ownership transfer
- An administrator’s move of a script to another person, recorded as a version the administrator authored, after which runs present that administrator’s roles.