Filament Jira Feedback Laravel Package

Product Decisions This Supports

• Closing the feedback loop inside the product: This package embeds a Jira-backed issue-reporting flow directly into Filament admin panels, so internal users, operators, or beta customers can report defects and requests without leaving the tool. That supports decisions about where feedback is captured and how quickly it reaches the backlog.
• Build vs. buy for feedback capture: Rather than building a custom form, auth handoff, attachment handling, and Jira API integration, the team can adopt a small plugin. This is a credible “buy/assemble” decision when the product surface is already a Filament panel and Jira is the system of record.
• Roadmap and prioritization inputs: Because reports land in Jira, existing triage, labeling, and sprint processes can be reused. This supports using real user-reported issues—rather than ad hoc Slack/email reports—as roadmap evidence, provided the Jira project and issue-type conventions are defined.
• Support deflection and internal tooling quality: For back-office, operations, and admin-facing products, in-context reporting reduces the “where do I report this?” friction and gives support teams a traceable path from user report to engineering work.
• Release-specific product risk: Version 1.1.6 fixes a defect where users could not report issues through the portal (ZCP-85). This is a patch-level fix to the package’s core value proposition, so any prior 1.1.x evaluation should be revisited before rollout; the reporting flow should be regression-tested in the target Filament panel.

When to Consider This Package

Consider adoption when:

• The product’s admin/back-office surface is built with Filament (Laravel/PHP) and the team wants an embedded feedback/reporting entry point rather than a separate tool.
• Jira is already the engineering system of record, and the team is comfortable with Jira project, issue type, and field configuration as part of the product-operations workflow.
• The feedback audience is internal, operational, or invited/beta users—not a fully public customer-facing portal requiring hardened abuse prevention, SLAs, and branded support UX.
• The team values low integration cost over deep customization: a config-driven plugin is preferable to a bespoke integration.
• The organization can accept single-maintainer/open-source dependency risk and has a lightweight review/upgrade process (pin versions, test upgrades, monitor releases).

Look elsewhere when:

• The product is not on Filament, or the team wants a framework-agnostic or public-web feedback widget.
• Requirements include complex routing/triage rules, custom SLAs, advanced permissions, attachment governance, PII controls, or enterprise support guarantees.
• The issue tracker is not Jira, or the organization needs a vendor-supported integration with contractual assurances.
• The team cannot tolerate patch releases that fix core reporting behavior without a formal QA cycle; in that case, a more mature or internally owned integration may be safer.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost plugin that lets users of our Filament admin tooling report issues directly into Jira. It shortens the path from user feedback to engineering backlog and avoids a custom integration project. The main caveat is dependency maturity: release 1.1.6 fixes a bug that blocked users from submitting reports, so we should pilot it with a defined group, pin the version, and validate the reporting flow before broader rollout.

For engineering: The package is a Filament plugin that creates Jira issues from an in-app reporting form. Adoption is configuration-led rather than a bespoke build, which reduces initial effort but introduces a third-party dependency. Version 1.1.6 is a patch fix for the core report-submission flow (ZCP-85); we should add a regression test around submission in our panel, confirm Jira field/project mapping, and establish an upgrade-review step. If our requirements stay close to “capture a report and create a Jira issue,” this is a reasonable build-vs-buy trade; if we need custom triage, public-facing hardening, or vendor support, we should reassess.