Portals

The portal is the external-facing surface of BNDRY — the place customers and other end users go to complete forms, upload documents, and finish the work attached to a workspace. It is a separate web application from the internal BNDRY app, branded for the organisation that owns the data collection, and accessed via a time-bound magic link rather than a permanent account.

Why the portal exists

Almost every regulated workflow eventually needs information from someone outside the organisation — a customer, a beneficial owner, a third party. Without a dedicated external surface, that handoff happens by email, by phone, or by sending PDFs back and forth. None of those produce a clean audit trail, none of them scale, and none of them give the end user a usable experience.

The portal exists so the external step looks and feels like a deliberate part of the process rather than a bolt-on. It carries the organisation's branding, presents forms in a state the user can actually complete, and writes everything back to the same workspace and audit trail that internal reviewers see. The same surface also handles embedded contexts — the portal can be opened inside another product when the organisation wants the experience to feel native to its own app.

Key properties

The portal is shaped by a few things rather than configured field by field:

• Access — entry is typically by magic link, generated for a specific email address with an expiry between one day and sixty days. A link can grant access to a whole workspace or to a chosen subset of its forms. Magic links replace the need for the end user to hold a permanent account.
• Scope — what the end user sees in the portal is the workspace (or the subset of forms) the link was issued for. The portal does not expose anything outside that scope.
• Appearance — branding, logos, colours, and typography are controlled centrally in the BNDRY settings and apply to both the internal app and the external portal. Appearance does not change business outcomes, but it affects trust, completion rates, and the volume of support questions that come back when a workspace is shared externally.
• Embedded versus standalone — the portal can be presented as a standalone site or embedded inside another product. The two contexts share the same forms and the same backend; appearance should be tested in both, because what looks right standalone can read differently inside a host page.
• Dark mode — the portal supports dark mode, and forms render against both palettes. Appearance changes should be reviewed in the same theme the user is likely to see.

How the portal relates

The portal is the external counterpart to the internal BNDRY app — same data, same workspaces, same forms, but a different audience with a different access model. Anything an end user does in the portal lands back in the workspace that internal reviewers work from.

A portal session is almost always anchored to a workspace. The workspace defines the scope of the session; the magic link defines its duration and the email it was issued to.

The work the end user does in the portal is, almost entirely, completing forms. The portal renders each form from its FormKit schema, captures responses, and accepts file uploads against the form. When a form is submitted, its state updates and any configured automations pick up the responses to drive downstream work.