Manage Server Projects

Project details bring together published Workflow, Conversation, and Kanban projects. You can inspect run or preview status, manage access, publish versions, configure environment variables, expose Embed and Webhook entry points, and investigate run logs.

Common Tasks

Check whether a project can run

Inspect the latest version, entry points, run statistics, and Webhook and Embed state.

View overview →Configure members and run permission

Add members, create invitations, adjust roles, and block individual users from running a project when needed.

Manage members →Configure remote-run parameters

Set project environment variables for server runs, External API, Embed, and Webhooks.

Manage environment variables →Expose external entry points

Generate a public Embed URL or let an external system trigger a workflow through Webhook.

Configure Embed and Webhooks →

Project Overview

The overview shows project identity, current-locale name, overall latest, latest Server-runnable version, most recent publication, run entry points, and run statistics. Server-side aggregation covers status distribution, version throughput, trends, duration, source, run actor, and token use.

Use it to quickly determine whether:

• An online version with a complete compatible Server runtime exists.
• Webhook or Embed is enabled.
• A task is running or waiting for input.
• Recent success rate, failure rate, or duration looks abnormal.

Open Run Logs for complete filtering and paginated queries.

Settings

The Settings view centralizes run admission, access policy, and the project baseline:

Area	Description
Data-storage declaration	Read-only local, server, both, or missing state, plus the reason Server access is allowed or blocked.
Run admission	Controls whether new runs are accepted, the concurrency limit, queue state, and stopping all runs.
Access policy	Switches between public and private and opens member authorization.
Configuration links	Opens Members, Environment Variables, Webhooks, Versions, KV Data, Knowledge Base, and Run Logs; Embed appears after at least one version has been published.
Project baseline	Read-only workflow ID, latest version, next version, and update time.

New-run admission and concurrency save immediately. On a failed save, the page restores the last server value and reports the error.

Server Web supports server data only. A server or both declaration enables Overview, runs, members, versions, schedules, KV, Knowledge, environment variables, Embed, Webhooks, and other data views. A local or missing dataStorage.mode declaration blocks those views uniformly; Settings remains available only to explain the declaration and reason. Add the declaration from Desktop project information or project source. Server Web does not provide a control that bypasses it.

Members, Invitations, and Run Controls

A project supports four member roles:

Role	Permission summary
owner	Project owner with full project-management and source-download permission.
manager	Can manage members and configuration, publish, run, and download source.
runner	Can run the project.
viewer	Can read the project and download retained source snapshots.

The Members view combines members, invitations, run users, and the run-block list in one table. Every identity uses the same avatar, display name, email, and user-ID presentation. Administrators can create an invitation link; accepting it adds the user to the project member table.

The run-block list prevents selected users from running the project. Owners and managers cannot be added. Removing a block restores the ability allowed by that user's role.

Project Identity

Server projects use a UUID as their stable identity. Desktop generates a UUID immediately when creating or cloning a local project, writes it to package.json.id, and uses it for routing, SQLite sessions, run records, and project data. A manually imported legacy empty-ID project still receives a stable registry UUID for migration. When creating the cloud application, Desktop sends the existing package UUID or that registry UUID as the required workflowId and writes the same value to package.json.id for the legacy project.

POST /api/workflows requires the UUID from local package.json.id as workflowId, projectType: "workflow" | "conversation" | "kanban", and complete projectInfo containing dataStorage.mode. In one atomic creation request, Server stores the UUID, name, type, complete declaration, optional projectCard, and visibility instead of creating a default record and synchronizing it later. It does not accept source or a full package.json. If the same account already manages the project, retrying the same UUID, name, and type recovers the binding and refreshes the complete declaration without creating another project. The first source upload still validates the declared type: Workflow and Conversation statically analyze executor projectType; Kanban reads package.json.workflowCode.projectType and requires a configured HTML entry point. Publishing, membership, Kanban configuration, remote runs, KV, logs, and actor records all align to that UUID.

The root package.json.name is the default name, while workflowCode.projectInfo stores localized names, manual declarations, display platforms, and the enforced storage location. A bound Desktop synchronizes the complete { name, projectInfo } through PUT /api/workflows/{workflowId}/project-info. Server displays the current-locale name with the default fallback and searches default, Simplified Chinese, and English names. Ordinary declarations and macOS/Windows/Web platforms remain display-only. dataStorage.mode strictly controls whether Server can execute the project and access KV, Knowledge, and PersistentValue; it never falls back to local or another store.

Both file storage and database storage return un-migrated source as an explicit error. A Workflow or Conversation without executor type, a Kanban package without project type or configured HTML entry, an unknown type, legacy conversation.enabled, or legacy workflowCode.projectCard.kind never silently disappears from the list or falls back to Workflow. Correct the source, then upload or read it again.

Clients with project-management permission can upload a cropped WebP image through POST /api/workflows/{workflowName}/project-card-image. The endpoint accepts only image/webp up to 1 MB. Server stores it by content hash and returns a publicly readable, long-cacheable immutable URL. Save visual metadata through PUT /api/workflows/{workflowName}/project-card, which accepts only an icon, image URL, icon color, and background color; it cannot change project type. Historical content-hash images remain available so URLs in old project metadata or published versions do not break.

GET /project-card-images/{workflowId}/{hash}.webp requires no login so project lists, public Embed, and other display surfaces can load the image. Upload and card-update endpoints still require login and project-management permission. Existing external http(s) URLs in projectCard.iconUrl remain readable for compatibility, but the Desktop no longer provides a manual entry field.

User and Sub2API Binding

Once the Sub2API management connection is configured, the global user-management table shows Sub2API binding state for each Workflow user. By default, the table checks only users on the current page and uses a 10-second process-local cache to coalesce repeated checks for the same user. Selecting Unbound Sub2API first evaluates users matching the account and search filters, then filters and paginates unbound entries. A temporary Sub2API outage shows a check failure without blocking the Workflow user list.

The user-table action opens one user-management dialog with user profile, role permission, Sub2API, and account-status sections. Sub2API email and user name are fixed text. For a bound user, you can bypass the list cache to validate the binding live. Administrators with users.manage can bind an unbound user or, after confirmation, unbind an existing one. Server uses the Workflow user ID as the Sub2API user name and creates a normal Sub2API user with <userId>@workflow-code.local and a random password. Creation uses the deterministic email for idempotency, so retries do not create another user. Unbinding deletes the corresponding normal Sub2API user; Sub2API handles associated resources such as that user's API keys according to its deletion semantics. The Workflow user remains unchanged, and repeating unbind leaves the user unbound. A successful bind or unbind immediately invalidates related user-state cache. The random password never reaches the browser. If Sub2API uses Backend mode, a newly created normal user still cannot sign in directly.

Sub2API API-Key Groups

System administrators can expand Sub2API in the console navigation and use Subscription configuration to manage Sub2API API-key groups available to Workflow Server users. These are API-key groups from the Sub2API management API, not Workflow user groups.

Administrators do not declare model capabilities in subscription configuration. Sub2API remains the source of truth for groups and available models. Server uses a versioned model-capability catalog only to enrich the live model list with display name and vision, web-search, reasoning, and tool-call information. A model unknown to the catalog can still be used normally, but does not gain undeclared capabilities.

The page has three actions:

• Refresh configuration refetches current groups and the Server's saved enabled selection.
• Sync from Sub2API bypasses the short-lived cache, refetches groups, and records an administrator synchronization audit event.
• Save configuration persists enabled group IDs. All subscriptions can be disabled.

Sub2API is authoritative for a group's name, description, platform, billing type, enabled state, usage limit, and ordering. Server uses a 60-second process-local cache by default to reduce repeated reads and coalesces concurrent identical upstream requests. Workflow Server stores only administrator-enabled group IDs and package prices; it does not copy descriptions, billing type, state, routing, model capabilities, or account counts. The UI presents standard as balance billing and subscription as subscription billing. A configuration action in the final table column opens a dialog where an administrator decides whether to expose the group; a subscription-billed group also requires a 30-day price in CNY. On save, Server bypasses cache and rereads Sub2API to validate group IDs. The page and management API require system.admin.

The group table separates Sub2API description, billing type, and subscription price. Subscription-billed groups show their CNY price and fixed 30-day period; balance-billed groups show Not applicable. Filter by name, description, ID, platform, billing type, upstream state, and exposure state. The upstream active and inactive states appear as Enabled and Disabled. Enablement, disablement, and price all use the final-column configuration dialog, not leading checkboxes. More than 20 groups use console pagination. On narrow screens, filters wrap to available width and the group table scrolls horizontally within its own region without shifting the whole console.

Sub2API Subscriptions and Refunds

System administrators can open Sub2API > User subscriptions to page through all Sub2API user subscriptions. Sub2API is authoritative for subscription state, plan, start and end time, and daily, weekly, and monthly usage. Server uses a default 10-second process-local cache and coalesces concurrent identical requests, but never persists these subscription records into the Workflow Server database. A record matching a Workflow account shows the account name, email, and avatar; unmatched historical records continue to show the Sub2API user ID. Filter by subscription state, plan, and platform, including canceled subscription history.

Refunds apply to the existing mock-payment flow. Only an active subscription with a completed Workflow subscription order is refundable. Its maximum refund is the total paid amount linked to that Sub2API subscription. A subscription allocated directly in Sub2API with no Workflow payment record cannot be refunded. After an administrator enters and confirms a CNY amount, Server bypasses the list cache to reread the subscription live, creates a retryable refund record, and cancels the real Sub2API subscription. A refund becomes complete only after cancellation succeeds, and subscription-list cache is invalidated immediately. On failure, the page retains failed state and a retry action; on success, the subscription is shown as canceled. Refund requires system.admin and writes an audit event.

Personal AI Configuration and Orders

Personal Settings divides AI configuration into account balance, subscription plans, and balance-billed groups. Groups with the same billing type use equal-height cards with consistent title, benefits, status, and actions. Active subscription and balance-billed groups show key-configuration state in the card header. Every subscription or balance-billed group has a Supported models action. If the group has a custom model list, it is authoritative; otherwise Server pages through active accounts' current model lists in that group and merges them. Sub2API model additions and removals appear after cache refresh. Server uses a 60-second process-local cache for repeated reads and never synchronizes models into the Workflow Server database. An unsubscribed plan shows one Not subscribed state instead of redundant missing-key, empty-time, and empty-quota labels. After subscription, it shows payment time, expiration, and daily, weekly, and monthly quotas. Each period uses a progress bar for used, total, and remaining quota; an upstream period with no limit shows Unlimited. Sub2API is authoritative for quotas. Server uses a default 10-second process-local cache and does not persist them. Clicking subscribe or renew opens a mock-payment dialog. After confirmation, Server bypasses cache, checks the existing subscription, allocates or renews a real 30-day Sub2API subscription, and creates an API key bound to that group. A successful write immediately invalidates subscription and key cache.

Usage preference stores the full priority order of administrator-enabled groups for the current account. Move groups up or down, then save explicitly. Unsubscribed, disabled, or temporarily invalid groups retain their position. When Server builds an LLM credential catalog, it skips unavailable entries and chooses the next valid configuration. Desktop and Web share the same server-side preference; save in either and refresh the other to synchronize. An unsaved preference falls back to ascending group ID, appending newly enabled groups missing from the existing order. This fallback never replays an already-started model request.

Sub2API balance belongs to the user account and is shared by all balance-billed groups, so the page shows balance and its top-up action only once in the account-balance area. Sub2API is authoritative and Server uses the default 10-second process-local cache without copying balance to the Workflow Server database. A top-up order does not belong to a group. After a user enters and confirms a CNY amount in mock payment, Server increases the Sub2API account balance by the same numeric amount and immediately invalidates balance cache. Each balance-billed card independently shows today's usage, usage for the last 30 calendar days including today, and cumulative usage, all in the Asia/Shanghai time zone using Sub2API actual deduction amounts and the default 10-second cache. The first time a balance-billed group is enabled, Server creates its group key but never tops up again. Disabling changes the existing Sub2API key to inactive rather than deleting it; re-enabling restores the same key to active rather than creating a duplicate. A successful key-state write invalidates related cache immediately. External create calls use stable idempotency keys so a retry does not create duplicate same-group keys.

AI usage in Personal Settings pages through Sub2API request records for the current account over the last 7 days, last 30 days, or all time. The page summarizes request count, total tokens, actual cost, and average duration. It shows model and configuration, request entry point, input/output/cache tokens, list and actual cost, total duration, time to first token, and billing method per record. Every page has 20 records. Changing the filter or page rereads the matching Sub2API page. Server uses the default 10-second process-local cache for identical concurrent queries and may serve the last successful result inside a default five-minute stale window only for temporary network, timeout, rate-limit, or 5xx failures. Usage details are not written into the Workflow Server database, and browser responses never expose a real Sub2API key, user profile, IP, User-Agent, upstream request ID, or internal account identifier.

Orders in Personal Settings shows subscription and balance-top-up order ID, product, amount, state, payment time, completion time, and creation time. An order starts pending payment, becomes processing after confirmation, completes after Sub2API synchronization, and becomes failed when synchronization fails while retaining a background retry path. Subscription orders retain their group link; balance-top-up orders do not. A plain Sub2API key appears only briefly in server memory during its create call and is immediately discarded. Workflow Server stores only necessary external user, subscription, and key IDs; user APIs and pages never return those IDs, a key prefix, or a key value.

Run Queue

Every workflow has its own run-admission configuration:

• acceptsNewRuns: whether new runs are accepted.
• concurrency: the concurrency allowed by the current server instance.

Runs above the concurrency limit enter waiting state and continue when a slot becomes available. Settings shows running and waiting tasks and lets you stop one or stop all.

In a multi-server deployment, concurrency is a per-instance limit. Stop all affects only the instance that receives the request.

Scheduled Tasks

The Workflow Scheduled tasks view lists each plan's enabled state, IANA time zone, trigger rule, exact version, entry point, next run, most recent result, and skip reason. You can create, edit, enable, disable, or delete a plan, trigger it immediately, and inspect fire history. Conversation and Kanban do not show this view.

Server schedules accept only exact published versions, never latest or draft. On save, Server validates that the version is online, the entry point exists, and parameters meet that entry point's static definition, then returns the next five trigger times. Project-declared workflowCode.schedulePresets appear as inactive suggestions and create a schedule only after the user confirms one.

Managing a schedule requires schedule.manage and project access. Running it immediately also requires runs.create and project run permission. Ordinary edits do not replace the schedule creator. Every fire rechecks that the creator is active, still authorized, and targeting an executable version and entry point; run quota belongs to that creator.

When the prior run for a schedule has not ended, the next fire records skipped_overlap and never enters the waiting queue or retry path. waiting_for_input is also unfinished. Server does not replay fires missed while it was offline; after recovery it records one skipped_missed and advances to the first future time. Multiple instances claim and recover fires through database leases. A unique record for each schedule and scheduled time prevents duplicate runs. See Workflow schedules for complete rules.

Version Details

The Versions view shows version number, uploader, release notes, publish time, lifecycle state, latest marker, and Server-runnable, local-only, or static-Web status. The version API returns both version-pinned sourceMode and executionTargets.

Source upload first creates a persistent preparation job. Desktop or CLI selects files with project-root .workflowignore and submits the archive; .gitignore is ignored. The request waits only until Server stores the archive and returns jobId. When executionTargets.server is enabled, Workflow/Conversation unpacks, installs dependencies, and bundles or minifies. With Server disabled, preparation only unpacks, validates, copies, and hashes source: it neither installs dependencies nor bundles or creates a runtime artifact. Kanban never enters the Server executor; it validates artifactDir, the HTML entry, and optional kanban.json, then stores static artifacts unchanged. The job and draft persist the same release policy. Publish inherits an omitted policy from the draft and returns 409 for an explicit mismatch.

Release targets are immutable version metadata:

Target	Behavior
server: true	Produces a Server runtime for Run, Debug, Embed, Webhooks, External API, and schedules.
desktop: ["macos"] / ["windows"]	Allows the matching Desktop download and requires source mode.
Server plus Desktop	Keeps both a Server runtime and downloadable source.
Empty Kanban targets	Continues Server-hosted static Web delivery without entering the Server executor or enabling a Desktop release.

Workflow and Conversation require at least one target; Kanban forces server: false. The first Workflow/Conversation publication defaults to Server only, and later uploads inherit the previous exact version's policy. Legacy source versions map to Server plus macOS and Windows; legacy bundled versions remain Server-only.

Source mode is pinned to the published version:

Mode	Version contents
bundled	Workflow and Conversation retain runnable bundled or minified output; Kanban retains complete static-site resources.
source	Workflow and Conversation retain original source snapshots alongside runtime output; Kanban likewise retains complete static-site resources for permission-controlled download.

Both Workflow and Conversation modes retain a README when it was present in the upload list, but a README is not required. Kanban requires only package.json and the configured HTML entry point, not a README. The host no longer silently excludes .env*, node_modules, dist, Git metadata, cache, or temporary files; a project must declare exclusions explicitly in .workflowignore. The ignore file itself is always retained. Upload fails and identifies the matching rule when it excludes a required entry point.

GET /api/workflows/{workflowName}/source-files reads only published source-mode versions, never a draft, and requires platform=macos|windows to match the version's Desktop target. The caller needs project-read permission plus global projects.download_source, or project membership as owner, manager, or viewer; runner cannot download source. Project-group download checks only the root version's release target for the whole group; included dependencies still follow exact dependency locks and source permission.

Related Projects and Source Delivery

The project detail's Related projects workspace manages workflowCode.projectInfo.relatedProjects consistently for Workflow, Conversation, and Kanban. A relation contains an alias, target-project UUID, and the KV grant that allows the other project to access the current project. It is Confirmed only when both projects' current declarations point to each other; a one-sided declaration is Pending confirmation. When the caller can manage both projects, Server writes or removes both declarations in one transaction. Otherwise it saves only the current declaration and grants no KV access.

A new reciprocal relation explicitly defaults both grants to read: all and write: none. Read and write rules each support none, all, and prefixes with a non-empty prefix list. Project A uses its alias to locate B, but access reads B's current grant to A. getValue checks read, setValue checks write, and compare-and-set checks both. Every operation rereads both projects' current declarations, so editing or removing a relation or grant takes effect immediately. Related-project KV resolves direct relations only and never follows B's relations recursively.

Kanban project-group source delivery derives from mutually confirmed general relations in the root project's exact version. A publisher can select a related project as included or leave it external. Server records a dependency lock for every exact root version: included projects pin the related project's exact published version and source hash, while external entries retain only alias and project UUID. A pending relation can remain in a draft or published version but never joins the included set.

Project-group publication runs in this order:

1. Validate publisher management permission on the root and every included project, then reserve versions.
2. Validate the project-group v1 archive, every project type, source hashes, and build output.
3. Publish included projects in source mode.
4. Write the complete dependency lock, then publish and activate the Kanban root version.

An interrupted preparing upload can submit the full project-group package again; an interrupted publishing operation can resume idempotently. A dependency already published with the same hash never creates another version. Any failure keeps the root version offline. Project-group archives, Server upload, and downloads reject KV, PersistentValue, schedules, run history, environment variables, SQLite data, CLI credentials, and other host-user configuration.

Source permission and relation KV permission are independent:

• Downloading an included dependency requires related-project read and source-download permission. When missing, the remaining projects download and return a short-lived application URL. A signed-in user submits a reason, then a related-project owner or manager can approve, reject, or revoke project-level download_source capability.
• A user who can read or run consumer project A can access B KV through A's alias once the A-B relation is confirmed and B's grant permits the operation; membership in B is unnecessary. Opening or managing B directly, or bypassing A, still follows B's own project permissions.
• A prefixes rule limits matching KV keys only; it grants no source download, execution, or management. Pending relations and none rules grant no access. Revocation immediately invalidates revision streams and later requests.
• Related writes from a Server Web preview additionally require management permission on the consumer project. Public Kanban still requires sign-in and a valid Embed token; a project relation never enables anonymous access.

The Related projects view shows both aliases, confirmation state, each side's read/write rules, and a Kanban exact version's included/external delivery mode, source permission, and Server data state. Add or edit selects a target from projects the current account can manage; UUID remains a persistent identifier rather than manual input. Empty Server KV shows Project deployed; Server data has not been initialized. A developer must run an applicable Workflow entry point, configure a schedule, call the Server Run API, or use a business interface to initialize it. The platform never copies Desktop-local KV automatically.

Version lifecycle:

State	Description
preparing	Version preparation is in progress.
online	The version is published and obtainable; Server execution is not implied.
offline	The version is taken offline but retained.
latest	The newest online release, which may be local-only.

For Server execution, latest independently resolves to the newest online Server-runnable version. macOS and Windows downloads each resolve latest to their newest compatible online version. Explicit Server execution of a local-only version returns a localizable 409. Normal and streaming runs, Debug, parameter resolution, Embed, Webhooks, External API, and schedules share one runtime gate requiring server: true, online state, a complete runtime artifact, and Core compatibility. Overall latest still points to the newest online release, so a newer local-only release does not interrupt existing cloud entry points. Older online versions can be brought online again or taken offline manually; the overall latest version cannot be taken offline directly.

KV Database

The KV workspace read-only displays server project and conversation scope data for a current project declared as server or both. It never mixes another project or Desktop-local KV. For local or undeclared projects, both API and page block before reading data. KV and PersistentValue are mandatory separate storage domains, and this page queries only KV. The paged list shows key, scope, conversation, value type, size, summary, update time, and last write source.

Filter by key, conversation ID, run ID, scope, value type, and log-link state. Selecting a row reads its complete value. The list returns summaries by default so a large JSON value cannot block the browser.

Values written through a Kanban JavaScript bridge use the current project's project scope and appear in the same workspace. Current-project writes from the Server Web preview bridge are available only to users with project-management permission. A request cannot name another project, scope, database path, or workflow name. A related-project request submits only an alias from the current Kanban declaration plus a key. Server resolves the relation from the page's fixed resolvedTarget, rereads both current declarations, and checks the target project's read/write grant to the Kanban; the caller cannot supply a target UUID.

A successful related-project KV transaction increments the target project's revision in the same transaction. After commit, authenticated SSE notifies relevant open Kanban pages. A rollback sends no change. Server Web previews and Embeds receive a full revision snapshot on connection or reconnect, then only an alias and opaque revision. On permission revocation or an invalid relation, Server returns one related-project-unavailable state and closes the stream without exposing a target project, KV key, or database detail.

Knowledge Base

The Knowledge Base workspace manages Markdown documents for a current server project declared as server or both. For a local or undeclared project, both API and page block before PersistentValue access. The left side shows document lists and search results; the right side shows preview or editor. Document body is always stored as Markdown in server-database PersistentValue storage.

Common actions include:

• Create, edit, and delete a document.
• Search full text and inspect surrounding lines.
• Page through large document lists.
• View title, summary, creation time, and update time.

This view never reads or changes the Desktop-local knowledge base. Selecting Server data source in Desktop accesses this same server-project data; selecting Local accesses storage isolated to the current device. They do not synchronize automatically.

Kanban's JavaScript bridge uses this same knowledge base. Create, edit, delete, search, and line reads share the same PostgreSQL project data and input limits.

Environment Variables

The Environment Variables view saves project configuration for server runtime. Server runs, External API, Embed, and Webhooks all read these values. Secrets are never displayed in plain text on public surfaces, and save and delete require explicit confirmation.

Desktop-local environment and Server environment are separate: a local run reads Desktop-local values, while a remote run after publication reads Server values.

Embed Workflow Entry Point

Embed is available only after a project has at least one published version. A project that has only been registered does not show Embed in its table row, detail navigation, or Settings page; opening its Embed management URL directly returns to Project Overview. These entries appear automatically after the first publication.

Embed and Desktop use the same composer parameter protocol. A normal Workflow shows a flat Swagger-style list of entry points in target-version declaration order. Its compact header shows title, ID, and default marker on the left and one optional description line on the right; the header has no Run action. The default entry point starts expanded. Expand another entry point before running it from its content; filling parameters, selecting a date, or resolving parameters elsewhere does not reopen a manually collapsed entry point. Run creates a run only for the selected entry point and never runs the default first. One live run is focused at a time, other entry points disable while it is active, and the result belongs to the actual entry point. Conversation retains one session interface with no entry-point list or selection.

panel: "quick" parameters appear beside Advanced. Conversation quick choices are saved in the browser by workflow, access identity, and session. Workflow drafts are isolated by workflow, exact target, and entry point. When the selected entry point, or the Conversation executor, defines resolveParams, the browser sends current arguments and entry-point ID to a token- and login-protected resolution API at initialization and whenever a Form parameter changes in main, Advanced, or Quick. Dynamic hiding updates Advanced count and Quick controls together. Main input participates only when the parameter declares resolveOnInput: true. Resolution returns only parameter-state patches and never creates a run. Run or Send is unavailable while resolving or after a resolution failure. visible: false does not implicitly clear a value; mutually exclusive fields must also return value: null so a hidden value is not submitted.

Server Web and public Embed directly use the shared date parameter control rather than a host copy. control: "date" | "time" | "datetime" | "date-range" stores YYYY-MM-DD, HH:mm:ss, local YYYY-MM-DDTHH:mm:ss, and a closed YYYY-MM-DD/YYYY-MM-DD range. It is available in main forms, Advanced, and user-input nodes, not Quick. The calendar is rendered through a portal so composer or Advanced cannot clip it. It supports Escape, outside click, and focus return after close. Select its heading for dual year and month wheels. Done applies the selection; Cancel preserves the original month. A wide date-range picker reopens with selected start and end months, or the next month on the right when both are the same. Navigation on one side never moves the other. Narrow layouts use one calendar. A Workflow entry point shows required and format errors only after the first Run attempt; correcting the value enables it again.

Embed produces a project page that can be embedded or opened directly. Enabling it returns a public URL and a separate token controls access.

Field	Description
enabled	Enables the public entry point.
title / description	Entry-point metadata.
target	latest or a specified online version.
token	Public entry-point token. Resetting it invalidates old links.

A normal workflow shows Form or Raw input, Output, run state, and Cancel under the actual entry point. A Conversation workflow shows its conversation list, message history, and composer. Files, images, tool permission, user-input nodes, and token use follow the selected entry point or Conversation executor. A tool call waiting for manual approval shows its name and the actual JSON arguments. No call parameters provided appears only when the request carries no arguments. A Conversation tool-permission override belongs only to that session. When permission changes before the first send, the browser first creates the draft session and saves the override. New or unconfigured sessions retain the workflow-registered default. Normal Workflow tool policy is isolated by workflow, exact target, entry point, Embed token, and current access identity, and keeps the same policy after an approval resumes execution.

Kanban Embed does not show a composer, run history, Output, Diagram, or Logs. It loads the configured HTML entry and offline static assets from a fixed version's artifactDir and uses the same named-configuration interface as Desktop; without parameters it shows only the full canvas. Both source and bundled Kanban releases use the same static project structure for Embed site information and preview. Visitors must be signed in and have a valid Embed token. On first open, Server creates a default configuration for that user; later named configurations are isolated by signed-in user and never shared across users. The page bridge uses current-project KV and Knowledge; all visitors meeting those conditions share and may change or delete this data. Related-project KV is available only through a confirmed direct relationship and the target project's none/all/prefixes read/write grant to this Kanban; visitors need not be target-project members. Configuration changes notify the iframe live and create no run history. Revisions from readable related projects notify the iframe so it can debounce and reread current values; revoking the relationship or read grant closes the subscription immediately. Kanban does not support Run, Webhook, external run, or debug node.

Public Embed history is isolated by effective actor: an authenticated visitor uses account ID, and an unauthenticated visitor uses a browser-generated anonymous ID. An administrator opening a deep link from run logs can view the target session within authorized scope.

Webhooks

Webhooks let an external system trigger a workflow. The configuration page includes the signature entry point, body mappings, filter rules, and delivery logs.

Configuration includes:

• Whether it is enabled.
• The target version.
• A Workflow entry point. Conversation does not show this option.
• X-Workflow-Webhook-Secret signature header.
• Body-to-workflow-input mappings.
• Request-body filters.

The trigger path is:

POST /webhooks/{workflowName}/trigger

Filter rules use body-path syntax, with $ for the full JSON body. Conditions support equals, not_equals, contains, starts_with, ends_with, matches, in, exists, and missing.

{
  "enabled": true,
  "target": "latest",
  "entrypointId": "validate",
  "mapping": [{ "bodyPath": "$", "inputName": "payload" }],
  "filters": [
    {
      "conditions": [
        { "bodyPath": "object_kind", "operator": "equals", "value": "push" }
      ]
    }
  ]
}

When the target version changes, the configuration page reloads its entry-point catalog and distinguishes loading, no-entry-point, and invalid-saved-entry states. Body mapping validates only against the current entry point. A legacy Webhook configuration with an empty entry point reads the target version's default entry point and pins it as an explicit ID the next time it is saved.

Server validates the entry point against the target version when saving a Webhook. If configuration uses latest and a future latest version no longer contains the saved entry point, a trigger returns 409 without creating a run and never falls back to the default. Without filters, every request that passes signature and entry-point validation creates a run; with filters, only a matching request does.

Audit Logs

Audit logs cover sensitive actions including accounts, permissions, API keys, device flow, project upload, publishing, taking versions online or offline, runs, cancellation, user-input resume, environment variables, Embed, and Webhooks.

Reading audit logs requires audit.read. Audit details redact credential fields such as token, secret, password, Authorization, cookie, session, and environment-variable values, retaining only the context needed for investigation.

Mobile and Dark Mode

Project details, KV, Embed, Webhooks, logs, Sub2API subscription configuration, and dialogs support mobile layouts. Wide tables scroll horizontally inside their own region and filters reflow to available width. Dark mode uses the same neutral and semantic colors so state, warning, error, and actions remain distinguishable.