Minimum-necessary masking of lead custom-form answers (§164.502(b))

FeatureSecurityService
Shipped
August 4, 2026 at 4:17 AM UTC
Author
Kamo
Commit
1594aca

The platform's only field mask was **************** applied by LeadController.getLeadById to a caller who is neither god nor the assignee and lacks VIEW_LEAD_CONTACT_INFO_OTHERS (161). It covers e-mail, phones, date of birth and the street parts of the mailing/property addresses — and nothing else. customFormData rode straight through it, which is the one place on the platform a healthcare tenant will actually put intake and symptom questions. LeadFieldMask now owns the decision and the projection: - any org: custom-form answers ride with the contact mask. If you may not see the lead's e-mail you may not see what it answered. - handlesPhi tenants: answers are withheld from anyone the lead is not assigned to even WITH right 161. That right is scoped, by its own name, to contact information; a symptom answer is not contact information. The form title goes too — "Diabetes Intake Questionnaire" discloses the condition on its own. The form entry survives masking carrying only its id, so the UI can say "restricted" rather than draw a blank questionnaire. An org that will not load is treated as PHI-handling, matching PhiTenantStatus's UNKNOWN-denies posture. PUT /leads/{id} gains the symmetric write gate. The form editor PUTs the whole fieldValues map, so without it a member shown a blank questionnaire who pressed Save would have replaced the real answers with {} — the read mask would have become a silent delete. Static utility, no stereotype and no repository: the decision is pure and the caller already holds the org.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing