# Impact Template Audit

## Outcome

`tempmailer-impact` contains 74 templates inherited from the Distro mailer.
They do not all represent Obtainly Impact / one-app workflows. The mailer now has
safe wording updates for templates that are reusable by Impact today, while
contractual and finance-product templates are deliberately left unchanged until
their owning product and legal terms are confirmed.

## Updated for Impact

- `signup`: organisation onboarding, beneficiaries, interventions, approvals,
  controlled disbursements, and team/programme setup.
- `conversation_message`: calls the related person a **Participant**, not a
  customer.
- `inflow_notification`: presents the two existing payload values as
  **Payment Recipient** and **Organisation**.
- `payment_notification`: removes pending-order instructions and frames the
  payment as an organisation operational notification.
- `report_payout_account_update`: labels the business as an **Organisation**.
- `report_transfers`: labels transfer parties as **Organisation / Recipient**.
- `request_business_document`: uses the neutral `identifier` placeholder.

These changes retain the existing parameter names (`supplier`, `customer`,
`business`, and so on), so existing core notification payloads continue to
render without backend changes. The updated templates also tolerate browser
previews without a POST `parameters` payload.

## Reusable Without Product-Copy Changes

The authentication and communication templates are product-neutral and can be
used by Impact as-is: `otp`, `new_password`, `recover_password`,
`login_notification`, `error_notification`, `mailing_list_event`, and
`missing_mailing_list`.

## Do Not Treat as Impact Templates Yet

The following families still describe distributor/retail credit, inventory, or
supplier/dealer relationships and should only be enabled for Impact if the
underlying Impact feature is intentionally shipped:

- `credit_*`, `installment_*`, `guarantor_*`, `insurance_*`, and
  `mandate_*`.
- `customer_agreement`, `affiliate_agreement`, `dealer_created`,
  `order_notification`, `customer_payment_notification`,
  `sales_contact`, and `referral_*`.

They need product-owner and legal review, not a cosmetic find-and-replace.

## Agreement Gap

Impact defaults new businesses to the `organisation` type, but
`NotificationsService.validateQueryBusinessAgreement` currently checks only
the `customer` type unless the domain is Retail or Vendor. It also derives the
template name from the business type. Therefore an Impact organisation needs an
approved `organisation_agreement` template and a corresponding core routing
change before its agreement generation can work reliably.

The existing `customer_agreement` is explicitly a distributor credit agreement;
it must not be reused as an organisation agreement. The same review is needed
for a beneficiary agreement if beneficiaries will sign platform terms.

## Local Preview

Use the template route and send POST parameters when checking dynamic fields:

```sh
curl --request POST \
  --url http://tempmailer-impact.local/template/signup \
  --form 'parameters={"identifier":"Example Organisation"}'
```