Plexara
Automations
From conversation to automation
Solved logic should not need a conversation to run again
Working a report out is a conversation: which tables, which joins, which baseline, how to treat returns. Running it again is not. Once the logic is settled, re-deriving it through a model every week costs tokens, takes minutes instead of seconds, and can come back slightly different each time.
A Plexara automation is that settled logic, saved. Your assistant writes it as a small script, checks it, and saves it to the platform. From then on Plexara executes it, exactly as written, every time: the queries run in the warehouse, the output lands in the portal as a new version of the same report, and the run is recorded down to the statements it issued.
Ask for it by name in any session, press Run on its portal page, or put it on a schedule. The same run happens all three ways; the only difference is the label recording who asked.
Zero tokens per run
Plexara executes the script itself; no model, no context window, no subscription usage
A dialect of Python
Your assistant already writes it, and your team can read every line in the portal
Up to once a minute
Schedules run in your timezone, as a cadence stated in words, not a cron expression
Every run recorded
Trigger, duration, queries, outputs, and the printed log, kept for a year
How it works
Solve it once, run it forever
The expensive part of any recurring report is the thinking, and the thinking is already done by the time the report is right. Automations split the two: the conversation stays interactive, the repetition moves to the platform.
- 1
Work it out with your assistant
The interactive session is where judgment happens: finding the right tables, agreeing on definitions, correcting the first draft. This part is worth the tokens, and it happens once.
- 2
The assistant saves it as a script
It validates the code, dry-runs it against real data with nothing persisted, and saves. The saved version is what runs, under the access its author held at the save, never more.
- 3
Plexara runs it
On demand from any session, from the Run button on its portal page, or on a schedule in your timezone. Runs execute on the platform, so nothing depends on an agent being connected.
- 4
The output keeps its identity
Each run writes a new version of the same report or data feed rather than a new file every morning. A year of runs is one asset with a year of history, shares intact.
Dashboards
Data pushed in, not access handed out
A live dashboard usually means giving a BI tool a standing connection into your database. Plexara inverts that. The dashboard is a document your assistant builds once, with one marked data region; a scheduled script queries the warehouse and pushes fresh numbers into that region. The presentation never touches a database, and the schedule decides how fresh the numbers are.
Aspect
Dashboard with live database access
Dashboard fed by a Plexara script
Database access
Live database access
The dashboard holds a live connection, so its credentials, its host, and everyone it is shared with become part of your attack surface.
Fed by a script
The dashboard holds none. A script pushes fresh numbers into it on a schedule; the page itself can query nothing.
Load on the warehouse
Live database access
Every viewer is a query. A dashboard on a wall refreshing for an audience multiplies load at exactly the busy hours.
Fed by a script
One run per refresh, however many people look. The queries ran once, on the platform, when the script fired.
Freshness
Live database access
As fresh as the last time someone accepted the query cost.
Fed by a script
As fresh as the schedule, down to a run every minute where the numbers warrant it.
What an old view shows
Live database access
Whatever the query returns today; the dashboard as it stood last quarter is gone.
Fed by a script
Every refresh is a version of the asset. The dashboard as it stood on any past run is still there, showing exactly the data it showed.
Editing the presentation
Live database access
A BI-tool skill, in a BI-tool license.
Fed by a script
The dashboard is a document in the portal. Change a heading or a chart color like any other edit; the schedule keeps refreshing only the numbers.
Control
Nobody has to code, and the code is right there
Your assistant writes the script; the portal is where you hold it. Its page shows the schedule in words, what the script says about itself as a rendered document, the source with Python-dialect highlighting, and the run history directly under the code, so an error in the history is answered by the text above it.
The schedule asks for a cadence the way you have it in your head: weekdays, a time, a timezone. It shows the expression it derives rather than asking you to write one, and a report keeps its wall clock across a daylight-saving change. Pausing is its own control, and a paused schedule says so instead of showing a next fire that will not happen.
Anyone who does want the code can edit it in place. A save that does not parse is refused at the keyboard, naming what to fix, and every version keeps its author, so the history says who changed the report and when. Validate and Dry run sit beside the editor: one reports what the code would reach, the other executes it as you, with tighter limits and nothing persisted.
Governance
Unattended work under the same rules as attended work
Automation is where most platforms quietly loosen their governance: a service account here, an embedded credential there. Plexara runs scripts through the same authorization, the same personas, and the same audit log as every interactive call. Four rules make that concrete.
01
A script never exceeds its author
A run presents the roles its author held when the version was saved, and every call it makes is authorized at that moment, exactly as if the author had typed it. Unattended never means unaccountable.
02
No credentials in the source
Scripts name connections; Plexara holds the credentials and authorizes each call. A pasted key or token blocks the save before anything is stored.
03
The language cannot reach out
The scripting dialect has no network, no filesystem, and no clock of its own. Everything a script does is a governed platform call, audited under the script’s own identity, so its reach is readable before it runs and its record is complete after.
04
Failures are loud, never repeated
A failed scheduled run emails its owner with the reason and the log. The same inputs fail the same way, so failed runs are never blindly retried; a fire that arrives while the last run is still going is recorded as skipped rather than silently dropped.
Where the output lands
Portal Tour
Reports, dashboards, and run histories live in the portal your team already works in. Walk through it section by section.