Configurations & Drawings

A buyer who submits a configuration through the public configurator can follow it in the client portal: they see what they submitted and download the drawings as soon as the worker has produced them.

This is on by default, for existing tenants too; a tenant document saved before the setting existed has no such field and falls back to the default. Switch it off per tenant under Settings → Tenant → Configurator → "Buyer portal for configuration submitters" if that tenant should not have its buyers in the portal.

It still only applies where the tenant is active and has the configurator scope.

Switching it per project

A single project can override the tenant-wide setting, under Project → Project info → Buyer portal. It is owner-only, the same people who can change project visibility.

Switching a project off is the usual case once it has been handed over and its buyers no longer need their dossier. Existing sign-in links are not revoked (they keep working until they expire) but no new links are minted and no further buyer mails go out for that project.

The project setting always wins over the tenant's. A project that cannot be found falls back to the tenant rather than blocking the buyer, so a stale project reference never silently cuts someone off.

What the buyer experiences

1. They submit a configuration in the public configurator.
2. The confirmation email arrives in the tenant's branded mail layout, with the options summary, a "Bekijk mijn configuratie" button, a "Naar mijn kopersportaal" link, and a PDF receipt attached.
3. Clicking the portal link signs them in: no password, no code to type, and lands them on their configuration.
4. When the drawings are finished, they get a second email and can download them from the portal.

PDF receipt

The attachment (configuratie-<id>.pdf) is a one-page confirmation: project, bouwnummer, configuration ID, buyer, date, the chosen options with prices and the total, plus a QR code that opens the buyer's personal configuration link, so the configuration can be pulled up from the printed page. The receipt is best-effort: if rendering fails, the confirmation email still goes out without it.

Sign-in link

The confirmation email carries a magic link with a CONFIGURATION_INVITE purpose. It differs from the link the /portal/login form sends:

The two kinds coexist: requesting a fresh login link never invalidates the link already sitting in the buyer's inbox, and vice versa.

A CONFIGURATION_INVITE link opens the client portal only. Presenting one to the application's own magic-link endpoint is rejected, and the link is not consumed by the attempt.

Because the link is long-lived, treat the confirmation email as sensitive; anyone holding it can open that buyer's portal for 30 days.

Asking for a new link

Once the mailed link expires (or if the buyer deleted the email) they get a fresh one themselves at /portal/login: they type the address the configuration was submitted with and a 15-minute sign-in link is mailed to it. The confirmation email's footer links straight there with the tenant prefilled (/portal/login?tenant=<code>), so the buyer never has to know the company code the form otherwise asks for.

They do not have to find that page themselves: an expired or already-used link lands on "This sign-in link no longer works", which asks for their email right there and mails a new one.

The form answers the same way for every address, whether or not an account exists, so it cannot be used to discover who has a portal account. Only an address that is an active portal client of that tenant is actually mailed a link.

A re-requested link is stamped with the tenant it was asked for, the same way the confirmation-email link is. That matters for someone who is a client of one tenant and staff of another: signing in selects the client membership the link belongs to, instead of leaving them in whichever tenant they were last active in, where they are not a portal client at all, and the sign-in would be refused.

Account provisioning

Submitting a configuration provisions a portal CLIENT account for the address the buyer typed, and links it to their client record. Provisioning is deliberately conservative, because anyone can type any address into a public form:

• No account yet: a verified client account is created. The buyer never picks a password.
• Existing client account: reused as-is; a pending client invite is promoted to an active client.
• Existing staff account: left untouched, and no portal link is added to the mail. A colleague's address is never converted into a portal client.
• Unverified account (a signup that was never confirmed): left untouched, and no link is added. Verifying it here would hand out an account its owner never confirmed.

Drawings-ready email

When the worker calls finishJob on a configuration, the buyer is mailed that their drawings are ready. It is sent only when all of these hold:

• the configuration came from the public configurator (source = CUSTOMER);
• the worker actually uploaded files;
• the tenant has buyer portal access enabled;
• the buyer's address could be given portal access.

Sending is best-effort; a mail failure is logged and never fails the worker's finish call.

Portal page

Mijn configuraties lists the buyer's own configurations, newest first, each with its downloadable drawings. It appears when the tenant has the configurator scope.

Each configuration card also offers:

• Bekijk in 3D: an embedded, readonly 3D preview of the submitted configuration. The models are resolved server-side from the stored choices (configurationId on the public house-blobs endpoint), so the preview shows exactly what was submitted, not the base house. Rendered with plain WebGL so it works on any buyer device.
• Verder configureren: opens the public configurator seeded with this configuration's choices, so the buyer can iterate: adjust what is still open and submit the result as a new configuration. The button is hidden once every closing phase for the house has closed.
• Favoriet: a heart toggle to mark the configuration the buyer prefers. It is the same favorite flag staff see on the configurations table.
• Wat ligt vast?: one badge per option-closing phase of the house (see Kopersbegeleiding): grey/locked when the sluitingsdatum has passed (those options are final), orange with a countdown when closing soon, green while still open. Per-bouwnummer overrides on the closing schedule are respected.

Submitting changes to options in a closed phase is rejected by the server; the configurator's submission form explains which options are locked and since when.

Configurations in FAILED or CANCELLED state are hidden: those are worker outcomes staff resolve by retrying, and the buyer cannot act on them. The configuration reappears as soon as it is picked up again.

Every read is scoped to the client record behind the signed-in user, and a drawing can only be downloaded when its blob is listed on one of that buyer's own configurations. Anything else is reported as not found rather than forbidden, so the portal never confirms that another buyer's configuration exists.

Dashboard

Signing in lands the buyer on the dashboard, so for a configurator-only tenant that page has to carry the whole story; finance and buyer-guidance tiles are hidden when those scopes are off, which used to leave it empty.

Two tiles appear with the configurator scope, both linking to Mijn configuraties:

• Mijn configuraties: how many the buyer has submitted.
• Tekeningen klaar: how many have drawings to download. Judged on the drawings actually attached, not on COMPLETED: a configuration can finish without files, and offering a download that is not there reads as a bug.

Mijn woningen lists every home the buyer can open, each with its viewer link, and says why they can reach it:

A house they both own and configured is listed once, as owned. A configured house that has since been removed from the project is skipped; the configuration survives, but there is nothing left to open.