BuiltEmail workspace

Insurance order received

Source: App\Mail\InsuranceOrderCreated, app/Mail/InsuranceOrderCreated.php; resources/views/emails/insurance/order_created.blade.php using mail::message. Static references are usage evidence, not production delivery proof.

Native subject: sprintf('Purchase of %s%s by %s', order.serviceProvider.name, order.product.name, order.user.first_name). Preserve the missing separator between provider/product rather than silently fixing a header through HTML. Suggested preheader: Your order for {{provider_name}} {{product_name}} was received.

Portable values

TokenExisting sourceHandling
{{first_name}}View $user->first_name ?? ''Optional escaped greeting. The Mailable passes only order; user is not explicitly bound. Default mapping is empty unless a real shared/native binding is established or an explicit integration change is authorized. Do not silently substitute order.user.first_name.
{{provider_name}}order.serviceProvider.nameRequired original provider identity.
{{product_name}}order.product.nameRequired original product identity.
{{order_amount}}order.currency . number_format(order.amount, 2)Required complete two-decimal formatted display, preserving prefix, sign and zero. Do not copy provider-purchase's raw amount formatting.
{{app_name}}config('app.name')Original Thanks sign-off.
{{preheader}}Source provider/product summary aboveEscaped text; not payment, coverage or approval.

Header-only subject_first_name maps order.user.first_name independently of the optional view greeting. Native subject requires that relationship; do not invent a missing-user fallback. The ready HTML/text mark an optional greeting: remove the whole Hello block when mapped first_name is null/empty, preserving nonempty text including 0. This improves the empty salutation without silently repairing the API binding. A supplied-greeting fixture illustrates an explicit adapter choice, not an established original binding.

The default Built logo/optional {{logo_url}} and shared PNG/CID/HTTPS requirements follow [shared-footer](../shared-footer.md). Required missing provider/product/order/header data needs an explicit target-project decision rather than invented values. No workflow URL, legacy duplicate link, policy ID, order ID, approval state or business attachment/PDF is supplied by the source body.

Trigger, audience and native delivery

InsuranceOrderController::store (:62–145) validates life/personal/beneficiary input, uploads identity files, creates InsuranceOrder with status pending plus NewInsuranceActivity in a transaction, then queues this email to user.email with internal BCC at :123 and queues the same body separately to a fixed internal To/BCC at :126. InsuranceOrderController::motorInsurance (:305–375) validates motor data, creates the same pending order/activity and queues the same two recipient copies at :354/:357. Routes: POST products/{id}/orders and products/{id}/motor-insurance-orders under the insurance group (routes/api.php:1456/:1457).

Preserve validation, record/upload ordering, user/internal recipient distinction, native BCCs, exact subject, queue() and configured From/Reply-To. No Mailable sender or Reply-To override exists. Internal copies intentionally reuse the customer acknowledgement; do not create an invented internal team greeting or new notification type. SMS is a separate channel.

Receiving an order does not establish successful payment, confirmed underwriting or policy issuance. Identity files/product files stored elsewhere are not email attachments. No coverage dates, processing promise, refund or new action is added.

Native integration and safety

Use this Mailable with a complete HTML Blade view and proposed plain-text alternative; portable {{placeholder_name}} tokens are not automatically Blade. Preserve native recipient/header/queue behavior and document the greeting decision explicitly. Escape text/attributes and use one pass for replacement. Validate logo/images separately and actually embed matching CID assets or use approved HTTPS hosting. No new templating framework is needed.

Five fictional states cover life/motor receipt, explicit optional greeting mapping, supplied zero as a rendering-only case and long values. Source creation requires amount > 0; the zero fixture is not a new valid purchase path. Files: public/ready/insurance-order-received.html/.txt and previews/insurance-order-received-*.html/.txt. No separate per-email project-owned text source was found; Laravel Markdown components can supply generated text, while this extract is proposed equivalent content. Browser checks do not verify coverage/payment, actual email-client/CID behavior or current production delivery.