Docs

Workflows

Standing automations your agent builds in chat: schedule, webhook, and manual triggers, safe test runs, credentials, per-run pricing, and plan limits.

A workflow is a standing automation that runs on plori without you or your agent in the loop. "Every morning, fetch the new issues, have a model triage them, and post the result to my webhook" becomes a small pipeline that fires on its own schedule, while your agent sleeps.

You don't assemble it by hand. You describe the automation in chat and your agent builds it step by step from a curated catalog of steps, each one validated as it's added. You review the draft in the visual editor, test it safely, and turn it on.

Workflows vs scheduled runs

A scheduled run wakes your agent later with a prompt: one deferred agent turn, with everything an agent turn costs and can do. A workflow is a fixed pipeline that runs without an agent turn at all: cheaper, repeatable, and exactly the same steps every time. Use a scheduled run for "think about this tomorrow"; use a workflow for "do this same thing every day".

Triggers

A workflow fires one of three ways:

  • On a schedule. Every N minutes, hourly, daily, weekly, monthly, or a cron expression you set.
  • On a webhook. The workflow gets its own URL under https://api.plori.ai/v1/hooks/... with an unguessable key. POST to it from any service and the delivery is accepted, buffered, and replayed into the workflow, with retries for up to an hour, so a brief platform restart between accept and run can't lose it. The URL only fires while the workflow is active.
  • Manually. Run it on demand from chat, from the CLI, or over MCP.

Watch-style automations ("new items in this feed") are built as a schedule plus a durable seen-before check that lives in plori's database, so each item is delivered once even though the machinery behind a workflow is recycled between runs.

What steps can do

The v1 catalog covers:

  • HTTP requests to any API.
  • Transforms: JSON, CSV, text helpers, and a field-to-field data mapper.
  • An AI step that prompts a hosted model and returns its answer into the pipeline.
  • Custom code steps in TypeScript, for logic the catalog doesn't cover.
  • A small key-value store for state between runs (cursors, counters).
  • A webhook response, for workflows that answer the caller.

A v1 workflow is a straight line: trigger, then steps in order, no branching yet.

Credentials

Steps that call authenticated APIs use named connections. In v1 a connection is a token, an API key, or a URL (for example a webhook URL that embeds its secret); OAuth "sign in with" connections aren't supported yet, so a service that only offers OAuth can't be connected in v1.

You fill a connection once, from the Connect card in chat or the connections rail in the editor. The value is sealed the moment it's saved: the model and the conversation transcript never see it, and it's decrypted only when the workflow actually fires, directly into the machinery that runs it.

Testing safely

A test run is the default way to fire a draft, and it's built so a test can't act on the world by accident:

  • The run stops before the first step that would write anywhere outside the workflow (an HTTP POST, for example). Read-only requests like GET run for real, against the real API, so you see real data flowing through your steps.
  • Custom code steps run with their network access blocked during a test, whatever the code inside them tries to do.
  • When you're ready to exercise the side effects too, you can explicitly ask for a full run, which executes everything.

What workflows cost

Prices render live from the billing system on the pricing page; in short:

  • Building and editing are free.
  • A run that actually happened (it succeeded, failed, or was stopped at your plan's max run length) costs 1 credit flat, any number of steps, with the first 90 seconds of runtime included, then 1 credit per extra started minute. Fires the platform skips or loses are never billed.
  • An AI step bills its model usage on top at the model's own rate, like any model call, so the flat fee alone is not the total for workflows that call a model. With your own provider key that model usage costs 0 credits.
  • Test runs from chat: the first 50 each calendar month are free on registered accounts, then 1 credit per run. Anonymous trials pay 1 credit from the trial balance.

Every workflow also has its own monthly spend cap, so a runaway schedule can't quietly drain your balance. When the cap is hit, or your balance is empty, fires are skipped and recorded rather than billed, and under the default notification setting you get a chat notice. To raise or remove a cap today, use the workflow API with your API key: PUT /v1/workflows/{id} with {"spend_cap_month": <credits>, "base_version": <current version>}, where 0 removes the cap. A spend cap control in the editor is tracked.

Limits by plan

Plan Active workflows Runs at once Max run length
Free 1 1 5 minutes
Pro 5 2 15 minutes
Power 20 5 30 minutes

Drafts don't count against the active limit; upgrading raises it. A run that reaches the max length is stopped where it stands. Anonymous trials can draft and test a workflow but must sign up to activate one.

Notifications

Each workflow has a notification preference: off, failures (the default: a message in your agent's chat when a run doesn't succeed), all (a message on every run), or summary (the agent reads the result and posts a short summary, which is a billed agent turn).

From your own tools

The MCP server exposes list_workflows, create_workflow, run_workflow, and get_workflow_execution, and the CLI mirrors them as plori workflows list | create | run | execution. Building the steps themselves stays with your agent in chat.