Components
The SDK provides these Web Components. Each renders inside Shadow DOM, isolated from your host page styles. The form components have their own page: Forms.
<hyphen-task-sidebar>
A sidebar panel showing pending human-in-the-loop tasks from your workflows: approvals, forms a case is waiting on, and agent reviews. Each task displays the workflow name, step context, urgency level, and the controls for its kind: approve and reject, or Fill it in.
<hyphen-task-sidebar
auto-refresh
refresh-interval="10000"
show-urgency>
</hyphen-task-sidebar>
Attributes
| Attribute | Type | Default | Description |
|---|---|---|---|
auto-refresh |
flag | off | Automatically poll for new tasks |
refresh-interval |
ms | 15000 |
Polling interval when auto-refresh is on |
show-urgency |
flag | off | Display urgency badges on tasks |
Events
| Event | Data | When |
|---|---|---|
task:decided |
{ runId, stepId, approved, comment, kind } |
User approves or rejects a task |
form:submitted |
{ runId, stepId, payload } |
User fills in a form task inline |
How It Works
The sidebar fetches pending tasks scoped to your publishable key. Each task carries a kind: approval, form, or agent_review. When a user clicks approve or reject, the SDK sends the decision to the gateway. An approval resumes the workflow with @__approved and @__comment in context. A rejection ends the workflow run and remains in its record. A form task renders <hyphen-form> inline; submitting it settles the paused step and the case continues.
Connected to workflows. The tasks shown are real PbotApproval and PbotForm steps paused in your workflows, and agent runs waiting for a person. Deciding or filling in a task in the sidebar resumes the run: no additional API call required.
<hyphen-data-grid>
A sortable, paginated data table connected to Hyphen custom tables. Supports inline editing for operations teams.
<hyphen-data-grid
table="invoices"
page-size="25"
editable
highlight-agent>
</hyphen-data-grid>
Attributes
| Attribute | Type | Default | Description |
|---|---|---|---|
table |
string | required | The custom table name to display |
page-size |
number | 20 |
Rows per page |
editable |
flag | off | Allow inline row editing (double-click a cell to edit) |
highlight-agent |
flag | off | Highlight rows last modified by an AI agent |
Events
| Event | Data | When |
|---|---|---|
table:updated |
{ table, rowId, changes } |
A row is created or modified |
Inline Editing
When editable is set, users can double-click any cell to edit its value:
- Enter saves the change
- Escape cancels the edit
- Blur (clicking away) saves automatically
Edits are sent as PATCH requests to the gateway, which updates the custom table and logs the change in the audit trail. The authenticated user's identity is attached to every edit.
Status Pill Detection
The data grid automatically detects status columns (by column name or known value patterns) and renders values as colored pills:
| Status | Color |
|---|---|
paid, completed, approved |
Green |
pending, processing, in_progress |
Amber |
overdue, failed, rejected |
Red |
<hyphen-doc-feed>
A document management surface with upload capabilities. Shows existing documents for the configured workflow, their processing status, and provides a compact upload bar for new files.
<hyphen-doc-feed
workflow-id="wf_invoice_processing"
accept=".pdf,.csv,.xlsx"
max-size="52428800"
multiple>
</hyphen-doc-feed>
Attributes
| Attribute | Type | Default | Description |
|---|---|---|---|
workflow-id |
string | No | Workflow to trigger on upload |
accept |
string | * |
Accepted file types (MIME or extensions) |
max-size |
bytes | 52428800 |
Max file size (default 50 MB) |
multiple |
flag | on | Allow multiple files |
Events
| Event | Data | When |
|---|---|---|
run:status |
{ runId, status, documentId } |
A triggered workflow run changes status |
How It Works
- User uploads a file via the upload bar
- The SDK sends the file to the document storage API
- If
workflow-idis set, the SDK triggers the workflow with the document reference as input - The feed shows the document's processing status in real time (queued, processing, completed, failed)
Documents display with file type icons (PDF, CSV, XLSX) and their trigger status. Each document links to its associated workflow run.
<hyphen-auth-modal>
An OTP-based login modal for approved team members. Handles the full email + 8-digit code verification flow.
<script>
// Show the login modal
sdk.login();
</script>
The auth modal is not placed in HTML directly: it's triggered programmatically via sdk.login(). The modal renders as a fullscreen overlay with three steps:
- Email entry: user enters their registered email address
- OTP verification: user enters the 8-digit code sent to their email
- Success confirmation: brief confirmation before the modal auto-closes
Events
| Event | Data | When |
|---|---|---|
authenticated |
{ email, sessionId } |
OTP verification succeeds (bubbles, composed) |
Session Upgrade
On successful authentication, the SDK upgrades the session from anonymous to authenticated. All components automatically reflect user-level permissions: the task sidebar may show additional tasks, and the data grid may enable editing that was previously restricted.
Users must be added in advance. The SDK does not support self-registration. An org admin must add users to the access list for the publishable key before they can authenticate.
<hyphen-agent-console>
A full agent launch, monitoring, and results console. Lets operations teams run ReAct agents by writing an objective, selecting tools, and watching the reasoning trace in real time.
<hyphen-agent-console
max-iterations="15"
show-trace
poll-interval="3000">
</hyphen-agent-console>
Attributes
| Attribute | Type | Default | Description |
|---|---|---|---|
max-iterations |
number | 10 |
Default maximum iterations for the agent |
show-trace |
flag | on | Show the reasoning trace timeline |
poll-interval |
ms | 3000 |
Status polling interval during monitoring |
available-tools |
JSON | No | Pre-select tools by ID (JSON array of strings) |
accept |
string | .pdf,.csv,.json,.xlsx,.txt |
Accepted file types for attachments |
max-file-size |
number | 50 |
Max attachment size in MB |
previous-run-id |
string | No | Reference a prior agent run to inject its context into the new run |
Events
| Event | Data | When |
|---|---|---|
agent-launched |
{ agentRunId, objective, tools } |
Agent execution starts |
agent-completed |
{ agentRunId, finalAnswer, confidence } |
Agent finishes successfully |
agent-failed |
{ agentRunId, error } |
Agent fails or is cancelled |
Three Modes
Launch: The user writes an objective, optionally attaches files (PDF, CSV, etc.), selects tools from registered actions and workflows, and configures max iterations. Clicking "Launch Agent" uploads any files and executes the agent asynchronously.
Monitor: A vertical animated timeline shows each reasoning step as it happens:
- Completed steps display with a checkmark and the action name
- The active step shows an animated spinner
- Click any step to expand the full thought and observation
The monitor also handles paused agents: when the agent requests human input, a resume section appears with approve/reject controls.
Result: Shows the final answer, confidence score, any triggered workflow runs, and the recorded agent trace. If the run used previous-run-id, the result view displays the linked prior run. A "New Agent" button resets back to launch mode.
Cross-Run Context
Agents can reference a prior run's outcome. Set previous-run-id to a completed agent run ID, and the new agent receives the prior run's objective, final answer, status, and a condensed reasoning trace as context in its system prompt.
This enables multi-stage workflows where one agent's conclusion feeds into the next: without re-executing the prior work. The engine validates org ownership of the referenced run, so cross-org references are rejected.
<hyphen-agent-console
previous-run-id="agent-abc123"
show-trace>
</hyphen-agent-console>
Or via the API:
{
"objective": "Review the findings from the prior audit and recommend next steps",
"tools": ["act_reviewer"],
"previous_run_id": "agent-abc123"
}
How It Works
The agent console uses the same scoped authentication as all SDK components. The tools visible in the picker are limited by the permissions attached to the publishable key, and the gateway validates access before proxying requests to the execution engine.
Scoped to permissions. The tools shown in the picker and the agents a user can launch are governed by the publishable key scope. Users only see and can use tools they're authorized for.
<hyphen-process-studio-v5>
The Process Studio catalog and case screens, embedded in your product: pick a case, make it yours, run it or hand it off, read the record, and describe your own. The same experience as the hosted page at https://<gateway>/process-studio/v5.html.
<hyphen-process-studio-v5 target-org-id="org_…"></hyphen-process-studio-v5>
Attributes
| Attribute | Type | Default | Description |
|---|---|---|---|
target-org-id |
string | the key's organization | The organization that owns the copies and runs |
case |
string | Open one case by its key on load | |
hide-header |
flag | off | Hide the wordmark header when your product has its own |
The element follows the host page's data-theme attribute (light or dark), and the OS preference otherwise.
Events
DOM events, bubbling and composed, prefixed hyphen-process-studio-v5:.
| Event | Data | When |
|---|---|---|
case-opened |
{ key, code } |
A case screen opens |
prepared |
{ processId, bundleId, workflowIds } |
Use it finished preparing the organization's copy |
run-started |
{ runId, executionType, processId, sample } |
A run or a sample run started |
run-finished |
{ runId, executionType, phase, formPause } |
The run reached finished, paused, or failed |
review-requested |
{ runId, processId } |
The person pressed Review it on a paused run |
form-requested |
{ runId, formPause, open } |
The person pressed Fill it in |
request-sent |
{ requestId, title, attempt } |
A described case was sent, or sent again |
request-settled |
{ requestId, status, packageId, key } |
A described request listed, returned, or was held for the admin |
error |
{ stage, message } |
Something failed; stage names where |
How It Works
The element calls the same gateway routes the catalog uses: the playbook library to list and open cases, apply and publish to prepare a copy, execute to run, and the run status and evidence routes to follow a run. Approvals it raises land in <hyphen-task-sidebar> like any other task. Nothing compiles in the browser.
A signed-in session is needed to describe a case. Reading the catalog and running a case work under an anonymous session; sending a described request, deciding one as an admin, and changing the organization's policy need a person signed in through the auth modal.
Combining Components
Components work together through the SDK's event system. When a document is uploaded via <hyphen-doc-feed>, the triggered workflow may create approval tasks that appear in <hyphen-task-sidebar>. Approved tasks may update rows in <hyphen-data-grid>.
<div style="display: flex; height: 100vh;">
<hyphen-task-sidebar auto-refresh show-urgency
style="width: 360px;">
</hyphen-task-sidebar>
<div style="flex: 1; padding: 24px;">
<hyphen-data-grid table="invoices" editable>
</hyphen-data-grid>
<hyphen-doc-feed workflow-id="wf_invoice_processing"
accept=".csv,.pdf" style="margin-top: 24px;">
</hyphen-doc-feed>
</div>
</div>
All components share the same SDK instance and session. Events from one component are visible to others via sdk.on().