Qsendgridbundle Laravel Package

Product Decisions This Supports

• User-facing attachment naming (new in 1.1.1): Product and support teams can now control the filename recipients see (e.g., Invoice-2024-0042.pdf instead of tmp_x9f2.pdf), which directly affects perceived quality of transactional emails, receipts, reports, and exports.
• Feature work: Enables branded document delivery, localized filenames, and compliance-friendly naming (invoice IDs, case numbers, date-stamped reports) without custom Mailable code.
• Roadmap: A reasonable dependency for document-delivery and export workflows; worth flagging if the roadmap includes customer portals, automated reporting, or multi-tenant branded communications.
• Build vs. buy: If the team is currently hand-rolling attachment filename logic or patching Laravel mailables, this package replaces low-value custom code with a maintained, versioned dependency. The 1.1.1 addition is additive and low-risk, so adoption cost is mostly evaluation time.
• Prioritization signal: The release is a minor, backward-compatible enhancement—useful for polishing existing attachment features rather than unlocking new product lines.

When to Consider This Package

Consider it when:

• The product sends generated or user-specific files via Laravel mail (PDFs, CSVs, statements, reports) and the displayed filename matters to recipients.
• You need to decouple storage filenames from presentation filenames (internal IDs vs. customer-friendly names) without per-Mailable hacks.
• You operate multi-tenant or multi-brand communications where filenames must reflect the tenant, locale, or document type.
• You want auditability and consistency in outbound document names for support, compliance, or archival.

Look elsewhere or defer when:

• Attachments are static assets with fixed names, or the app does not send file attachments through Laravel.
• You need full document management capabilities (versioning, access control, retention policies)—this is a naming/attachment convenience, not a DAM.
• The team already has a well-tested internal abstraction for attachment handling; migrating for a single naming feature may not justify the churn.
• Strict dependency-review processes would make a minor package upgrade disproportionately expensive relative to the benefit.

How to Pitch It (Stakeholders)

For executives: Version 1.1.1 is a small, backward-compatible enhancement that lets us control the filenames customers see on emailed attachments. The business value is presentation and trust—professional, branded, traceable document names instead of system-generated ones—with no migration or breaking-change risk. It supports existing receipt, reporting, and export workflows and is cheap to evaluate.

For engineering: The release adds an API for defining attachment names—additive only, no deprecations or breaking changes. It removes the need for custom filename logic inside Mailables and keeps storage naming separate from customer-facing naming. Recommended action: run a short spike against one transactional email flow, confirm the API fits our mail stack, then adopt if it reduces custom code.