Public Sessions

A public session is a time-bounded interaction issued by your workspace to a specific external party, delivered through a session link, so they can complete a defined set of tasks without holding a workspace account. The party receives the link, clicks through, completes the tasks, and the workspace records the outcome.

Public sessions are how the work of parties happens for parties who don’t (and shouldn’t) sign into your workspace. A prospective vendor filling intake. A buyer completing KYC. A counterparty acknowledging a notice. A signatory signing a document. Each is a public session.

This page is the party-governance deep dive on public sessions. For the simpler workspace-admin perspective (what tabs to use, what defaults look like), see Public Access. This page is for designing the session flows themselves.

When you would reach for this

You design public sessions when:

A party needs to provide input that the workspace shouldn’t manually enter.
A party needs to acknowledge a document, attestation, or notice with audit-grade record.
A party needs to upload files (executed contracts, certificates, evidence) into the workspace.
A counterparty interaction should be governed end-to-end without giving them workspace access.

You don’t reach for this for member work (members sign in directly) or for interactions that happen entirely outside the workspace (email exchange that’s later attached to a record).

What lives in public sessions

Two record types:

Session template defines a reusable public session. It carries:

A name and a stable key.
A trigger context (typically a lifecycle transition or a manual issuance).
A set of tasks the party walks through: forms to complete, documents to acknowledge, files to upload.
A time bound (typical: 14 days from issuance; configurable per template).
A scope (which party, which lifecycle, which subject this template applies to).
A status (draft, published, retired).

Session instance is one issued session: this template, to this specific party, with this session link, valid from now until the time bound.

A session template might be issued many times over its life (every new vendor intake gets the same template instantiated for them). Each issuance creates a new session instance.

Session task types

Common task types a session can include:

Form completion: the party fills in one of your Forms.
Document acknowledgment: the party reads and acknowledges a document.
File upload: the party uploads files into a defined upload scope.
Signature: the party signs a document (when document-signing actioner is wired).
Confirmation: the party confirms a stated fact (e.g., that they’ve read terms).

Tasks within a session can be ordered (must be done in sequence) or unordered. Each task captures its own completion record with timestamp.

A worked example: the procurement marketplace’s onboarding sessions

Felipe’s marketplace issues different public sessions at different stages.

Session template vendor-intake is issued when a vendor party is created. Tasks:

Complete the vendor profile form (company info, contacts).
Complete the categories-and-services form (what they sell).
Upload basic certifications (insurance, business registration).
Acknowledge the marketplace’s terms-of-use document.

Time bound: 14 days. On expiry, the session closes; the vendor must request a re-issue to continue.

Session template vendor-due-diligence is issued when the vendor transitions to due-diligence. Tasks:

Complete the financial disclosure form.
Upload financial standing documents.
Acknowledge the vendor code of conduct.
Complete the regulatory-categories declaration.

Time bound: 21 days.

Session template buyer-intake is issued when a buyer party is created. Tasks:

Complete the buyer profile form (industry, purchasing patterns).
Complete the KYC information form.
Upload identity verification documents.
Acknowledge the buyer agreement.

Time bound: 14 days.

Session template annual-vendor-refresh is issued annually to active vendors. Tasks:

Confirm contact information (a refresh form, prefilled).
Re-upload current certifications.
Confirm code-of-conduct re-acknowledgment.

Time bound: 30 days.

Each session is issued through the workspace and lands as an email to the party with the session link. The party clicks, walks the tasks, and the workspace records each completion. Completed sessions feed lifecycle transitions; expired sessions close without effect (the party can be re-issued).

What you’ll see in the product

Public Sessions lives under Governance → Party → Public Sessions in the workspace, with the public-facing surface at the workspace’s public URL (see Access URLs).

The Templates list shows every defined template with its status, recent issuance count, completion rate.

The Instances list shows every issued session with its party, status, completion progress, expiry.

Inside a template, you see the task list, time bound, trigger context, recent instance outcomes.

Inside an instance, you see the party, the link issued, completion record per task, the audit trail.

Every change is captured in the workspace Audit Log.

Security and privacy

Public sessions are deliberate about security:

The session link is single-use until activated; activation requires the party to verify their identity (typically via email + optional OTP).
After activation, the session is bound to a browser session.
All data captured is encrypted at rest under the workspace’s keyring.
Sessions expire automatically at the time bound.
An admin can revoke a session in flight; the party loses access immediately.

The party never sees workspace internals beyond the tasks. There’s no general workspace browsing; the public session is a focused, bounded interaction surface.

Common workflows

Designing a session template

Public Sessions → Templates → New. Pick name, key, trigger context.
Add tasks: forms, document acknowledgments, file uploads.
Set time bound.
Test by issuing to a test party.
Publish.

Issuing a session

From the relevant party or lifecycle transition, the template is issued.
The system generates the session link and sends to the party’s contact email.
The session instance appears in the Instances list.

Investigating an expired session

From the Instances list, filter by status expired.
Each expired session can be reissued (a new instance is generated) with rationale captured.

Revoking a session

From the instance, revoke with rationale.
The party’s link stops working immediately.
The audit trail captures the revocation.

Overview - the full party governance story.
Forms - sessions use forms as a primary task type.
Public Access - the workspace-admin view of public sessions.
Access URLs - the public URL parties land on.
Lifecycles - session issuance is typically tied to lifecycle transitions.