Reuse a contact during portal registration

Purpose

Portal registration can suggest an existing contact and preserve declined matches for staff review.

How It Works

Platform asks CRM for contacts that resemble the registration details. The candidate functions operate within the selected workspace. Suggestions require shared e-mail or phone information and enough evidence to meet the medium confidence floor. Contacts already linked to a portal account are excluded. The best three suggestions are ordered with an e-mail match first. Platform handles the member-facing masking. A member who declines the suggestions can receive a newly created contact. That create uses ordinary contact conventions and records the best declined suggestion as a review pair. A short retry window avoids duplicate creates from repeated submissions. These CRM functions provide backend evidence; a complete portal experience remains outside this examination.

Relationships

Platform owns registration and login identity. CRM supplies candidate selection and contact creation, while duplicate review handles the pair left by a declined suggestion.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Registration can offer an existing contact to a returning member.Declined suggestions remain available for later staff review.
Surfaces: portaljob
Constraints: The pinned development environment provides no customer-facing portal registration flow.

Controls

16 controls apply, from the corpus control catalogue.

TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-IAM-006 TC-LOG-005 TC-PI-001 TC-PI-005 TC-PRV-001 TC-PRV-002 TC-TEN-001 TC-TEN-002 TC-TEN-003

Business Rules

11 rules, 10 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Portal candidate selection returns no more than three contacts scoring at least 50, ordered by shared e-mail first, then score and contact number. no proof recorded yet	calculation	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#answers the three best contacts above the floor, the e-mail match first and a tie in contact-number order, with what Platform masks
`02`must prove Proposed	Candidates exclude contacts linked to a workspace portal user, deleted contacts and contacts belonging to another workspace. no proof recorded yet	policy	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#never offers a contact a portal user of the tenant already links
`03`must prove Proposed	Only shared e-mail or phone information can reach portal candidate selection; a registration sharing neither returns no suggestions. no proof recorded yet	calculation	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#offers nothing for a sign-up that shares no e-mail address and no number with any contact
`04`must prove Proposed	Portal candidates use the same contact scores and evidence as the staff-side scorer. no proof recorded yet	invariant	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#scores every contact of the neighbourhood with the score and the reasons the TypeScript scorer gives it
`05`must prove Proposed	When suggestions are declined, contact creation applies ordinary conventions, makes the registration e-mail primary and its phone the preferred mobile, and attributes the write to portal registration. no proof recorded yet	lifecycle	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#writes the contact with a UUIDv7 id, the next number, the names trimmed and computed and the stamps of portal-sign-up
`06`must prove Proposed	Creation stores an open portal-sign-up pair with the best declined contact, retaining at least low confidence and an explanation of the rejection. no proof recorded yet	lifecycle	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#records the declined pair, open, with origin portal_sign_up and the score and reasons the scorer gives it
`07`must prove Proposed	Detection may refresh and group portal-sign-up pairs but preserves their origin and does not retire them. no proof recorded yet	lifecycle	service	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#keeps the declined pair through detection pass over the new contact, which groups it
`08`must prove Proposed	A repeated registration within one minute returns its existing contact without another write. no proof recorded yet	invariant	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#answers the same contact for the same sign-up retried within a minute, and writes nothing more
`09`must prove Proposed	Creation rejects an e-mail already reserved as an active contact's primary address and rejects registration without either first or last name. no proof recorded yet	validation	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#refuses an address that is already the primary address of a contact it did not just create
`10`must prove Proposed	Only Platform registration may call the workspace candidate and create functions; the CRM application role is denied that access. no proof recorded yet	permission	database	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#refuses CRM's own application role, which is not granted it
`11` Proposed	A declined contact that has been absorbed by a merge resolves to its survivor.	policy	database	documented services-crm:docs/merging/duplicate-detection.md#15. Portal sign-up (the `portal_sign_up` origin)

Scenarios

Id	Given	When	Then	Provenance
`01`	A member provides a new e-mail address and a mobile already held by a contact.	Platform requests registration suggestions.	The existing contact appears among at most three candidates, with member-facing masking supplied by Platform.	test services-crm:modules/duplicates/tests/integration/db/portal-sign-up-contacts.integration.spec.js#ranks the neighbourhood as the scores say: 70 for the nickname with the address and the mobile, 50 for the name and the number, 38 for an initial
`02`	A member rejects the offered contacts.	Registration creates their contact.	The new record and best rejected candidate form an open review pair.	unknown FND-CRM-DQ-031

Planning

Reuse a contact during portal registration ​

Purpose ​

How It Works ​

Relationships ​