What's the best way to provide feedback to Adobe on Firefly features?

Senior platform engineer at a mid-market e-commerce shop, running image generation in CI for product banners and social snippets via Firefly's API since their GA.

The channels you listed aren't equal, and the "most effective" one depends on whether you want a ticket closed or a feature built. From my deployment:

1. **Enterprise Support Ticket Escalation (SLA-Driven)**
This is your only path for a reproducible bug or API dysfunction. Our account team can escalate; we got a fix for a rate-limiting header discrepancy in about 10 business days. For *technical blocking issues*, this works. For feature ideas, it's a polite black hole. You need a paid plan with a technical contact.

2. **Official In-App Feedback Form (The Suggestion Box)**
It's a metric, not a conversation. We logged three specific parameter requests (seed control, stricter prompt adherence) through this. Zero direct follow-up in 8 months, but one of the features quietly appeared in a release note. Assume it goes into a prioritization spreadsheet, and vote counts matter.

3. **Adobe Community Forums (The Influence Channel)**
If your feedback is about a *widely-felt pain point*, post it here. Product managers *do* monitor, but they're looking for volume and sentiment. I saw a thread on "weird hands in generations" hit 200+ replies and get an official response from Adobe staff. For your CI/CD parameter snags, unless it's a common workflow, it'll likely drown.

4. **Social Media / Developer Relations (The Lottery Ticket)**
A direct tweet at a Firefly engineer or DevRel can get a surprising fix for a clear, odd bug. We had an issue with the `content_type` parameter in the API silently failing; a tweet with a minimal code snippet got a DM asking for our client ID. It was patched in a week. This is unreliable but weirdly potent for niche technical glitches. Don't use it for feature requests.

My pick is the Enterprise Support channel, but *only* because you're integrating this into a pipeline. If it's a true bug breaking your builds, that's the only way to get a ticket number. If it's purely a feature enhancement, use the in-app form *and* also post a detailed case on the Community Forums to gather votes.

Tell us: is your snag causing generation failures, or just suboptimal output? And what's your contract level?

I agree that the forums seem geared more toward user troubleshooting. In my experience with their enterprise products, product managers do watch the "Ideas" sections, but it's a visibility game. The top-voted threads sometimes get a "we've passed this along" comment.

That official in-app feedback form you mentioned feels like shouting into the void. I've never gotten a response or seen a public log of submissions. It's probably aggregated for high-level sentiment.

For your specific API parameter issues, I'd lean on both. Post a detailed thread in the Firefly community forum, clearly framing it as a feature gap with your use case, and also submit the same points via the form. Doubling up seems to be the only way to cover both the public advocacy route and the internal metric route.

Don't waste your time on the feedback form. It's a checkbox for their PMs to say they collect feedback.

For API parameter issues, your only real shot is through enterprise support. But it's not for feedback, it's for defects. If you can frame your "improvement" as a bug that breaks a contract or a documented expectation, you might get a ticket. Otherwise, they'll file it and you'll never hear back.

Forums are for visibility, but I've yet to see a "we added this parameter" post that stemmed from a forum thread. It's just community managers managing expectations.

You've hit on the key tension: we expect structured DevOps feedback loops, but we're dealing with a massive B2C-focused platform. Your list is the right one, but they each serve a different purpose.

> is it mostly for user help, or do product managers actively track feature requests there?
Based on my integrations work, they do monitor the Ideas forum, but it's for gauging broad demand, not implementing a specific technical parameter. Your detailed CI/CD use case is valuable, but it's a niche audience there. Post it to build public support from other devs.

The feedback form is indeed a metric. However, for API issues, I've found it's the only way to tag your input with the specific product area (e.g., "API parameters"). That categorization matters internally. Use it in parallel with a forum post.

For something as precise as generation parameters, your enterprise support channel is your best lever, but frame it as a limitation impacting a business workflow, not just a nice-to-have. That gives your account team a concrete case to escalate.

Your list correctly identifies the primary channels, but their efficacy is stratified by your goal and your contractual relationship with Adobe. The missing piece is internal prioritization logic.

> I'm particularly interested in process.
For technical parameter improvements, you need to trigger their internal bug vs. feature classification. If a parameter behaves inconsistently with its documentation, route it as a defect via enterprise support. That creates a trackable ticket. If it's purely an enhancement, like requesting a new parameter, you face a demand aggregation problem. The forum can demonstrate that demand, but only if you articulate the developer impact in terms of compute waste or pipeline friction. Merely stating the feature gap is insufficient.

My recommendation is a dual-track, documented approach. First, craft a support ticket that frames the snag as causing tangible inefficiency (e.g., "Without parameter X, we must generate four images to post-process for one usable asset, increasing our API cost and pipeline runtime by 300%"). Simultaneously, post that same analysis in the Community forum's Ideas section, stripped of any proprietary details, to solicit peer validation. This gives the internal team both the business justification and the evidence of broader need.

The feedback form, in my analysis, serves as a sentiment data point for that specific feature area, which can reinforce the other two channels if you use consistent terminology. Relying on it alone, as others noted, is ineffective.

You're thinking like an engineer looking for a pull request process, but you're dealing with a product team that's tracking aggregate demand. Your four channels are all valid, but they're cost centers for Adobe.

> is it mostly for user help, or do product managers actively track feature requests there?

They track them, but they're counting votes. Your specific API parameter snag is a rounding error unless you can rally other devs on the forum to say it's blocking their pipelines too. The feedback form is worse; it's a sunk cost for their analytics dashboard.

If you're on an enterprise plan, frame it as a cost issue for them. Tell support your current workaround burns extra API calls or requires a secondary service, creating quantifiable waste. That's a language their business side understands. Otherwise, you're just adding to the noise.

Great breakdown of the channels. Your DevOps perspective hits the nail on the head - it's about triggering their internal process.

You mentioned framing feedback as a defect vs. an enhancement, which is spot on. I've seen similar tactics work in cloud security when reporting ambiguous IAM policies. If you can tie your API parameter issue to a specific, quantifiable impact like increased latency or failed pipeline runs, you can sometimes push it through enterprise support as a reliability concern, not just a nice-to-have. It moves it from a "feature request" bucket to an "operational issue."

The forums are still worth it for your use case, though. Post your detailed CI/CD workflow there. You might not get a direct response from a PM, but if other engineers echo the same friction, it builds a data point they can't ignore. It's about creating a paper trail across both public and private channels.

You're assuming there's a process that yields predictable results. There isn't. It's a product feedback swamp, not a structured DevOps loop.

All the advice about framing it as a cost or defect is theoretically sound, but it hinges on one variable: whether your support rep or forum moderator has the will to reclassify your request. Most don't. Their KPIs are about ticket closure, not advocating for niche API parameter changes.

The brutal truth is that unless your "snag" is causing a 15% increase in failed pipeline runs that their monitoring can see from their end, it's just noise to them. You'll get a ticket number and a "we'll pass it to the product team." That's the end of it. The only channel that occasionally works is publicly shaming them on a high-visibility platform when an API behavior blatantly contradicts their own docs, and even that's a gamble.

Great thread. That DevOps mindset is exactly what's missing from most feedback channels.

You're right to focus on the **process** trigger. Based on pushing similar IaC service feedback, the enterprise support route only works if you can attach a metric. Can you measure the pipeline cost of your workaround? Something like "this missing parameter forces an extra image processing step, adding X seconds and Y% to our job time" gets their attention. It shifts it from a feature request to a performance/inefficiency ticket.

And I'd still post in the forums with that same data. You won't get a commit SHA, but it helps other devs find your case and amplify it. It's a two-pronged attack: one ticket for their backlog, one public post for demand signaling.

Exactly. Quantifying the impact is the key differentiator between noise and a supportable ticket. Your example of "adding X seconds and Y%" is the right template, but we need to specify the measurement methodology for it to be credible.

A raw time delta isn't enough. You must baseline the Firefly API call, then measure the workaround step's latency and error rate with statistical significance. I'd run a benchmark suite, perhaps using a tool like `k6`, to capture the 95th percentile latency increase and the extra compute cost on your infrastructure. Present that as a monthly aggregate cost impact.

The trap is that many support teams will dismiss this as a client-side problem. The framing must tie it back to their service: "Our workaround generates 30% more API calls to your service for the same output, increasing our bill and your load." That aligns their cost with yours.

Good question, and I think the earlier replies have given a solid view of the landscape. The common thread about quantifying impact is spot-on, but there's one more layer to it.

Beyond just measuring your own pipeline costs, try to estimate the load or inefficiency your workaround creates on their end. If a missing parameter forces thousands of users to make two API calls instead of one, that's a scaling problem for them, not just a cost problem for you. That kind of framing can sometimes bridge the gap between a support ticket and a platform engineering concern.

Also, don't discount the forums for this specific use case. While they're for gauging demand, a well-documented post about CI/CD friction can become a reference point that other enterprise users link to in their own support cases. It creates a paper trail of shared pain that's harder to ignore than isolated feedback forms.

You've got a great list, and you're right to focus on the process angle. For your specific CI/CD parameter issue, I'd lean on the enterprise support channel first, especially since you're already measuring pipeline impact like others suggested. Frame it as a reliability or efficiency blocker with those numbers in hand.

But I've also had luck using the forums to find other teams with the same niche workflow. Post your detailed use case there - not just the problem, but how you're quantifying the extra steps. If a few other engineers chime in with "we have this same pipeline friction," it turns your individual ticket into a pattern their product team can't ignore. It's a two-track approach that's worked for me with other SaaS APIs.

Exactly right about the vote counting. The forums are useful for exactly one thing: creating a paper trail of aggregated user demand. A single post about an API parameter is useless. But if that post gets linked by five other enterprise users in their separate support tickets, it becomes a quantifiable signal.

Your advice on framing it as a cost to them is the only way to get a single ticket moving. Tie the extra API calls directly to their infrastructure load, not just your bill.

That's a really good point about linking forum posts in support tickets. I've never thought about using them as a reference like that.

So if I'm understanding this right, even if the forum post itself gets no direct response, its real value is as a public artifact that others can cite? That makes the "aggregated demand" thing a bit more concrete. It's like creating a paper trail for a pattern, not just a one-off complaint.

Do you know if support reps actually check those links, or is it more for the product team if the ticket gets escalated?