Plexara
Forms and Endpoints
From a sentence to a form
The agent builds it, an admin publishes it
There is no form designer to learn. The agent writes the form from a conversation, and the person who asked for it reviews what it does in plain language, the same way every automation is approved.
- 1
You describe the form
Who fills it in, what it asks, what counts as a valid answer, and what should happen to each submission. A store incident report, a supplier onboarding form, a request for a quote.
- 2
The agent builds it and tests it
The form is an automation like any other: the agent writes it, runs it against real data, and saves it with tests. Choices that should match your data, such as the list of open stores, are read from the warehouse each time the form opens, so they never go stale.
- 3
An admin publishes it
Only an admin can give a form its address, choose who may submit it, and turn it on or off. That keeps every public-facing form a deliberate decision.
- 4
Submissions arrive as rows
Each accepted submission is one row in the form’s own table. The agent can query it and join it to the warehouse, and the owner can read it in the portal and export it.
- 5
Each submission starts its own run
An automation that names the form as its source runs once per submission, seconds after it is stored: a post to the right channel, a record in the CRM, a row in the warehouse.
An example on the ACME demo data
A store incident report, built in one conversation
Ask for a form store managers can use to report an incident, and the agent reads the list of open stores from the warehouse for the store picker, takes photos as files, marks the employee number as sensitive, and refuses a date in the future. An admin then publishes it with a bot check on submission.
Writing the form, then publishing it
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 create
name store-incident-report
form_spec(req)
stores = platform.query("SELECT store_id, store_name FROM warehouse.public.stores
WHERE is_active ORDER BY store_name")
fields store single_choice required choices from stores
reported_by email required
occurred_on date required
category single_choice required Injury | Theft | Equipment | Other
details long_text required
photos file up to 5, images only
staff_id text sensitive
form_submit(req, values)
refuse occurred_on later than today -> "The date cannot be in the future"
-> saved, version 1, tests passed
manage_script endpoint_set (an administrator)
endpoint store-incident
methods GET, POST
auth_mode bot_check check forms checked_methods POST
-> /forms/store-incident answeringWhat a submission goes through
Checked, stored, then confirmed
A form builder collects answers and leaves the checking to whoever reads them later. Here the checks run before anything is kept, the person sees exactly which field to fix, and the confirmation they see means the submission is already in your data.
Where people fill it in
- Its own hosted page
- Inside a report or dashboard
- Embedded on a site you allow
Plexara checks, before your automation sees it
- 1The form is the one Plexara issued, unaltered and less than a day old
- 2The hidden decoy field is empty
- 3It was not submitted faster than a person can fill it in
- 4The bot check passed, when the form has one
- 5Every value is a field the form declared, of its type, within its limits
Refused
The person sees the error beside the field it concerns. Nothing is stored and the automation never runs.
Automation
Your rules, against live data
The automation behind the form reads the submission and can refuse it field by field: an order number that does not exist, a store that closed last month.
Stored
A row in the form’s table
The submission is written before the person sees anything. Sensitive fields are encrypted first, and attached files are saved to the library as searchable files.
Confirmed
Only then the thank-you
A submission that could not be stored is never confirmed. The person is told to try again instead of being told it worked.
One automation run per submission
Seconds after the row is stored, an automation that names the form as its source runs once for that submission and does what comes next.
- Post to a Slack or Mattermost channel
- Write to the CRM through its API
- Load a warehouse table
- Refresh a dashboard
What a form can be
The parts of a form
Forms cover operational intake: requests, reports, applications, onboarding. They are single-page forms without branching questions, payments, or survey analytics; those stay with a survey or payments tool.
Part
What it does
Field types
Short text, long text, email, number, date, single choice, multiple choice, checkbox, hidden, and file. Up to 100 fields, each with its own label, help text, required flag, and limits.
Choices from live data
A choice list can be read from any connected system when the form opens: open stores, active products, a customer’s own contracts.
Files
A file field takes up to 20 files, with a size limit and the file types it accepts. Types are judged from the file’s contents, not its name. Files are saved to the library, where they are searchable and linked from the submission.
Personal links
A form can be sent as a signed link for one recipient or one record, so a survey link or a pre-approved application cannot be altered or reused.
Where it appears
On its own page, which works in light and dark and at phone width; inside any report or dashboard in the portal, including shared ones; and embedded on a website your admin allows.
Spam protection
Every form is signed when it opens, carries a hidden decoy field, and cannot be submitted faster than a person could fill it in. Every published form has rate limits, and the admin can require a bot check on submission.
Submissions and sensitive fields
Intake that is governed from the first field
A form is often the first place personal data enters a company. It lands under the same access rules and audit record as the rest of your data, not in a separate tool with its own logins.
01
Submissions, in the portal
The form’s owner and your admins see the newest submissions on the automation’s page, with each file linked, and export them to CSV or Excel.
02
Sensitive fields are encrypted before they are stored
A field marked sensitive, such as an employee number or a tax ID, is encrypted on its own before the submission is written. The table, every query against it, and every export of the raw table hold the encrypted value.
03
Only named readers see them in clear
Sensitive values are readable in clear in three places: the owner’s Submissions view, your admins, and automations running for the groups the admin names. Every one of those readings is recorded with the fields read.
04
A failed submission never leaves the value behind
When a submission fails, the record of the failure replaces each sensitive value with a placeholder, so an error message cannot carry it into a log.
Endpoints
Automations that answer requests
A form is one kind of endpoint. Any saved automation can be published at an address of its own and answer another system directly: an order-status lookup a partner’s portal calls, a nightly feed a vendor pulls with an API key, a stock check for a store’s point-of-sale screen.
Each address has exactly one access mode, chosen by an admin when it is published.
Access mode
Who it answers
Suits
Authenticated
People signed in to your portal, and API keys. The admin lists who: everyone signed in, named groups, or named keys.
A partner system pulling a feed with its key; an internal request form.
Bot check
Anyone who passes the bot check the admin picks: Plexara’s own proof-of-work challenge, which calls no third party, or Cloudflare Turnstile or hCaptcha.
A form on your public website; a public lookup that should not be scraped.
Public
Anyone, with no check. It is marked as open to anyone everywhere it is listed.
Data you would publish anyway, such as store hours.
Every endpoint
What it does
Limits
A request limit for the address and for each caller, a largest request size, a time limit on each request, and the websites allowed to call it from a browser.
Identity
Each request runs as the automation, with the access its author approved, and each one is a row in the audit record naming the caller.
What callers see
An answer or a plain status. A caller is never shown the automation’s error. The owner sees every failed request with its reason for seven days.
What it answers with
Data, usually JSON, or a document that cannot run code. An endpoint is a lookup or a feed another system calls. Pages people use are forms and reports.
Admin > Automations > Endpoints
Every published endpoint and form is listed on one page with its automation, owner, access mode, and whether it is on. Over the last day or week it shows requests, failures, response times, and requests refused before they ran, broken down by reason: a failed bot check, a rate limit, a caller who is not on the list, a website that is not allowed. Any endpoint can be turned off from there without touching the automation.
Where it fits
The tools around your data, one workload at a time
Your CRM, ERP, and warehouse stay where they are. The small tools a company collects around them, each with its own logins and its own copy of the data, are where forms and endpoints earn their place, usually one form or one integration at a time as a renewal comes up.
Category
What Plexara covers
What stays with a dedicated tool
Form builders used for intake (Typeform, Jotform, Formstack)
Operational forms whose answers belong in your data: choices from live systems, checks against the warehouse, encrypted fields, files, and a run per submission.
Branching questions, multi-page flows, payments, e-signature, survey analytics, and designed marketing surveys.
The catch hook in a workflow tool (Zapier, Make, n8n)
A form submission, a webhook delivery, or an approved email starting an automation that queries and writes your data.
The long tail of prebuilt app actions those tools offer.
Small backends (internal app builders, serverless functions)
Lookups and feeds other systems call, with access modes, limits, and an audit record, written and tested by the agent.
Interactive internal apps with editable screens, and hosting websites.
Submissions and webhook events share one path into your data. See Webhooks for the other sources an automation can run from.
Common questions
Forms and endpoints FAQ
For operational intake, often. Requests, incident reports, applications, and supplier or partner onboarding fit well, because the answers belong in your data: choices come from live systems, each submission is checked against your warehouse, sensitive fields are encrypted, files are kept, and every submission starts the automation that handles it. Forms are single-page and have no branching questions, payments, e-signature, or survey analytics, so marketing surveys and checkout forms stay with the tools built for them.
Your agent builds it from a conversation and tests it like any automation, and the person who asked approves what it does in plain language. Only an admin can publish it at an address, choose who may submit it, require a bot check, and turn it on or off.
Each accepted submission is one row in the form’s own table, written before the person sees the confirmation. Your agent can query it and join it to anything else, the owner reads the newest submissions in the portal and exports them to CSV or Excel, and an automation can run once for each submission seconds after it is stored.
Yes. An admin lists the sites allowed to embed the form, and the embed snippet sizes itself to the page. For anything open to the public, the admin requires a bot check: Plexara’s own proof-of-work challenge, which calls no third party, or Cloudflare Turnstile or hCaptcha. Every endpoint also has request limits overall and per caller.
No. An endpoint answers with data, usually JSON, or with a document that cannot run code, so it suits lookups and feeds other systems call. Pages people use are forms and reports, which the portal renders.
What handles each submission
Automations
Your agent writes the automation, you approve what it does in plain language, and Plexara runs it on demand, on a schedule, once per event, or once per request.