Confirmed portal self-registration

Context

The cited product decision settled self-registration and the automatic Portal Member role. The design includes the implemented repair path rather than claiming the confirmation trigger is the only writer.

The separate administrator invitation capability remains real. Neither the approved self-registration decision nor its trigger guarantees uniform response statuses across every identity route.

Decision

Allow self-registration in active portal pools, provision confirmed members with the Portal Member assignment through the confirmation trigger or password-sign-in repair, and keep console registration invitation-only.

Alternatives Considered

Require staff invitation for every portal member. The recorded product decision requires visitors to join a portal without staff action; administrator invitation remains a separate supported path.

Create the active membership before mailbox confirmation. An unconfirmed address does not establish mailbox possession, so active self-registration waits for that evidence.

Consequences

Address-sensitive identity responses use neutral wording where implemented; availability and missing-pool differences remain findings.

Successful password sign-in repairs confirmed accounts whose provisioning trigger failed.

Contact matching occurs after identity membership and supplies a separate CRM link.