I'm parked on you

Pick an option on each card and press Done; your answer goes straight back to the session. The raiser's pick is marked. "I'm not sure" and "Take it to the engineering bridge" are real answers.

1

In plain terms. When AppFolio itself links a walk-in guest card to the same renter's application, should we trust that link and save the card's extra phone or email on the renter even if the two names are typed differently?

The full question, as raised

identity_contact_match_refused: for a guest card whose own inquiry is PMS-linked to the Person (card+application on one AppFolio inquiry), should claimSecondaryContactValue skip the name gate (claim non-primary, no alert) or keep refusing but record a person-page review item instead of paging? Contact-only matches keep today's guard either way. Design: PR #21530.

Trust the link, save itthe raiser's pick Keep refusing, no page I'm not sure — go find out Take it to the engineering bridge

2 other sessions waiting on this same answer.

Why, and what was tried

The session raising this recommends: Trust the link, save it
AppFolio already tied the card to this renter; six name-comparator patches have not held and each weakens the shared-phone guard
Tried first, unsuccessfully: Read the prod rows and sync log for ALR-65a76959: the person was created by the application 6s before its own card was refused. Reviewed all six prior fixes (each widened the name check for one shape). Checked b90219772, which required matching names for a bridge join — this asks whether that condition applies when AppFolio's own link, not a phone match, put the card on the person.

31e8ead6 (adopted from ebdc0568) is parked on this. 2 other sessions waiting on this same answer.

Asked by more than one session. Your answer above goes back to all of them.

ebdc0568 asked it this way:
identity_contact_match_refused design doc (docs/planning/alerts/identity_contact_match_refused.md, PR #21530) step 3: for reachedBy='pms_link' guest-card claims (card's own INQUIRY row carries af.guestCardId), choose A) claim value non-primary with no name check and no alert, or B) keep refusing but record a person-page review item instead of a page. contact_match path stays unchanged either way. Latest firing ALR-65a76959: pers_f9d90af7 INQUIRY row carries guestCardId 8937, matchedKeys [] — reached by PMS link, not contact.

31e8ead6 asked it this way:
identity_contact_match_refused (guest-card.contact-restamp, Situs, card 8558 → pers_09d0a8fc, same Person its own rental application minted 10-20) re-fires on the name gate although the card reached the Person by AppFolio's card→inquiry→application link, not by a contact match. Design doc docs/planning/alerts/identity_contact_match_refused.md (on main, #21530/#23663): pass reachedBy ('pms_link'|'contact_match') into claimSecondaryContactValue/contactGuardNamesAgree; contact_match keeps today's guard+alert unchanged. For pms_link: A = claim the value as non-primary, no name check, no alert (PMS link is the identity evidence, like the sameContactAsOwner precedent); B = keep refusing but record a review item on the person page, no page. Six comparator-widening PRs (#17663,#17669,#17682,#17698,#19720,#20283) did not hold.

Pick an option above, then press Done.