Public Access

Public Access lets you send a link to someone outside your organization, have them complete a task (fill in a form, upload a document, acknowledge a notice), and capture their response — all without them having a Novantra account.

The external participant lands on your organization’s public URL (the second of the two URLs explained in Access URLs). Their session is short-lived, scoped to the one task you sent them, and fully isolated from your internal workspace.

Configuration lives under Settings → Governance → Public Sessions and requires the public-sessions manage permission.

What you can ask an external participant to do

The product supports a small, deliberate set of public-session tasks:

• Fill in a form built with the Form Builder.
• Upload a document you specify (for example, a signed PDF).
• Download a document you’re sharing with them.
• Acknowledge or attest to something — a notice, a policy, a status.

A single public session can bundle several of these tasks. The participant works through them in order and the session completes when all are done.

Sessions vs templates

Two concepts to keep straight:

• A public-session template is the recipe: what tasks the participant should complete, what form (if any) to attach, any pre-filled data, expiry rules, OTP requirements. You create templates once and reuse them.
• A public session is one instance of that template, issued for one named recipient. Each session has its own URL with a unique token, its own state (issued, in progress, completed, expired), and its own evidence trail.

Most administrator effort goes into templates. Day-to-day issuance of sessions is usually a few clicks per recipient.

Creating a template

1. Open Settings → Governance → Public Sessions → Templates.
2. Click New template.
3. Name it (for example, “New supplier onboarding”).
4. Add the tasks the participant must complete — pick a form, attach documents, define acknowledgments.
5. Decide how the participant authenticates (see below).
6. Set an expiry — how long after a session is issued the link remains usable.
7. Save.

How participants authenticate

Two modes are supported when you issue a session:

You pick the mode per template. OTP requires that the public-access app can reach mail (and/or SMS, when that lands).

Issuing a session

Issuing creates a real, unique URL bound to one named participant:

1. From the template page, click Issue session.
2. Enter the recipient’s email (and a display name).
3. Provide any pre-fill values the form needs (for example, the supplier ID you’re onboarding).
4. Confirm.

The participant gets an email with the link. The session appears in the Sessions list under the template.

Tracking sessions

Each session shows you:

• The recipient.
• Whether the link has been opened.
• Whether OTP was successfully verified (if required).
• Which tasks are complete.
• Submitted data (when the session is finished).
• Evidence artifacts (uploaded documents, signed acknowledgments).

You can:

• Revoke a session — the link stops working immediately.
• Resend the email if the participant lost it.
• Reissue under a different email if you sent the original to the wrong address.

Sessions expire automatically at the template’s expiry. Expired sessions cannot be resumed; you reissue.

What participants see and don’t see

The public surface is deliberately minimal:

• Your organization’s branding (logo, name).
• The tasks for their session — nothing else.
• No member list, no other sessions, no workspace navigation, no admin features.

The participant has no path from the public surface into your internal workspace. A leaked or guessed token doesn’t grant anything beyond that one session, and even then only if OTP succeeds (when configured).

Evidence and audit

Public-session activity flows into a separate evidence trail from the workspace audit log. The two are intentionally split because the actors are different — workspace audit captures actions by your members, while public-session evidence captures actions by external participants.

For each session you’ll see:

• When the link was opened.
• OTP attempts (successes and failures).
• Each task transition (started, submitted, completed).
• Submitted artifacts and form responses.
• Final completion timestamp and signature.

The chain-hash protection that covers the workspace audit log (see Audit Log) covers public-session evidence too.

What’s not supported

Some scope deliberately not in v1:

• Long-lived public portals. Each session is bound to one recipient and one purpose. Anonymous “anyone with the link forever” landing pages are not what this is for.
• Two-way conversations. The participant completes their tasks; they don’t get a back-channel to message your team.
• Self-service signup from the public URL into your workspace. That’s a different flow (managed under Members & Invitations).
• Per-task per-participant routing. A session is one bundle of tasks issued to one person. Splitting tasks across multiple people in a single workflow is on the roadmap.

Sovereign vs Cloud differences

Related

• Access URLs — the public URL that external participants reach.
• Mail Configuration — needed for delivering session links and OTPs.
• Audit Log — your members’ actions land here; participants’ actions land in the public-session evidence trail.