Docs: A2P-compliant contact form consent checkboxes (CRMAAS-3088)

[haleyserrano]

JIRA

CRMAAS-3088: Make it easy to make an A2P compliant contact form

Classification

• Type: Feature behavior change (new default consent fields, rich-text checkbox content, automatic consent capture) + discoverability/UX
• Product impacted: Business App only. This is a CRM/Forms feature used by business owners to capture their own website leads — not partner, reseller, or agency facing, so Partner Center docs are unaffected.

Repo targeted

Business App repo (this PR). No Partner Center changes.

Summary of documentation updates

Existing pages were updated — no new pages were created:

• crm/forms/index.md — Added the Contact form template to "What's included," a new "Capturing leads with SMS and email consent" section, and two FAQ entries covering template discoverability and default consent behavior.
• crm/forms/form-builder.md — Added a "Consent checkboxes" section documenting: automatic inclusion when a Phone number/Email field is present, unchecked-by-default behavior, business-name auto-fill, rich-text support in labels/fine print, placeholder policy/terms links, and that consent is recorded against the created contact.
• crm/forms/supported-fields.md — Added the three consent fields (Transactional SMS, Marketing SMS, Email marketing) to the Contact fields list, with a note on automatic inclusion.
• administration/sms_configuration.md — Added a tip pointing to the Contact form template as the easy compliance path (ahead of the existing manual build-it-yourself instructions, which remain accurate for custom forms), and updated one rejection-reasons table row to mention the template.

Existing vs. new docs

Updated existing docs only. A prior PR (#943, merged) had already documented manual consent-checkbox requirements in sms_configuration.md; this change adds the template as the default, automatic path and keeps the manual instructions as the fallback for custom-built forms, avoiding duplication.

Placement reasoning

Consent-checkbox mechanics live in the Forms section (crm/forms/) next to the existing field-builder and field-reference docs, since that's where a business owner configures a form. The compliance-requirements context (why the checkboxes must look/behave a certain way) stays in the existing SMS registration guide (administration/sms_configuration.md), cross-linked both directions instead of repeating the requirements in Forms.

Acceptance criteria coverage

AC	Covered
Rich text support in checkbox contents	✅ noted in form-builder.md
Three consent fields present by default, unchecked, non-required, tied to phone/email presence	✅ noted in form-builder.md + supported-fields.md
Default text: business name, message use, required disclosure, policy/terms links (as placeholders, configurable)	✅ noted in form-builder.md (text described at a summary level, not reproduced verbatim, since the shipped UI copy wasn't provided as source material)
Consent captured against the contact	✅ noted in form-builder.md
Discoverability of the compliant template	✅ noted in forms/index.md ("What's included," new section, FAQs) and sms_configuration.md tip

Figma/images used

None were provided with this ticket. No new screenshots were added; all changes are text-only per the "fall back to text" guidance when visuals aren't available.

Skills used

pre-push-validation (manual equivalent: frontmatter, tag/callout balance, and internal link resolution checked for all 4 files). style-review scan script run for context (flagged only pre-existing issues in unrelated files already on this branch, plus one em-dash warning in new content, which was fixed).

Assumptions / limitations

• Epic status: This story's parent epic, BREW-2188 "A2P Fixes", is marked Abandoned (which maps to Jira's "Done" status category, but is not the same as shipped/complete). This story itself is individually Done, and none of the epic's other 6 sibling tickets are open or carry rollout-gating signals (feature flag, eligibility, region-restriction, or "define what makes X available" language) — they're all Done or Abandoned. Proceeding on the assumption that this specific story shipped independent of the epic's broader abandonment, per the escalation path for this situation, but flagging it explicitly since "Abandoned" is a meaningfully different signal than "Done."
• No linked GitHub PR: No GitHub PR was linked to CRMAAS-3088 (only a Confluence PBR page), so no code-author reviewer could be identified from the ticket. No reviewer was requested on this PR for that reason.
• Exact default checkbox copy (e.g. verbatim wording, exact template name/position in the picker) is described at the level of detail in the ticket's acceptance criteria rather than verified against the live UI, since no additional source material (Figma, screenshots) was attached.

---

@ahnikakuse @haleyserrano @maryam6samadi

---

Generated by Claude Code