Support, expansion, and feature requests

# Support, expansion, and feature requests

Canonical: https://docs.flowrelay.app/agent-access/support-and-expansion-requests/
Markdown: https://docs.flowrelay.app/agent-access/support-and-expansion-requests.md

Support, expansion, and feature requests are recorded in FlowRelay so humans and authorized agents work from the same safe request history without turning every idea into a support ticket or roadmap promise.

## Agent workflow
Agents should orient through docs before using authenticated tools.
1. Preview support requests before sending them. The preview redacts the summary and shows the facts that will be included.
2. Submit support only when the grant has support:request scope and the merchant or operator has consented to share the request.
3. Link a diagnostic share, event ID, endpoint ID, or support code when relevant. If there is no diagnostic share, explain why without copying raw event data.
4. Use expansion requests only for future-edition interest, trigger lanes, or capabilities tied to a real merchant task or explicit merchant ask.
5. State the FlowRelay fit: why the request is about reliable event intake, multi-platform event reliability, handoff recovery, replay, diagnostics, operational memory, exception recovery, approved agent operation, multi-install governance, or billing entitlement.
6. Use feature requests only for missing FlowRelay capabilities inside the current product surface, such as Agent Operations ergonomics, event history, replay, diagnostics, setup, billing/usage, rate-limit self-throttling, security, docs, or operator workflow gaps.
7. Treat expansion and feature requests as requests for review, not product commitments, generic product wishlist items, or permission to treat another edition or capability as live.

## Choose the lane
Recording a request is not a commitment. Support requests create a tracked record; expansion and feature requests create review records only. None of them set a timeline, promise delivery, or create a live future target.

Use support for active help or recovery, expansion for future platform/native-edition demand, and feature requests for missing FlowRelay capabilities inside the current product surface.


- Agent question: Something is broken or the operator needs help with a concrete event, endpoint, replay, diagnostics share, or setup; Use: Support request; Do not use it for: Product ideas or future-platform demand.
- Agent question: The merchant wants FlowRelay to support another platform, native edition, trigger lane, multi-store need, or broader event-reliability surface; Use: Expansion request; Do not use it for: Current-product UI/API/docs gaps.
- Agent question: The merchant or agent found a missing FlowRelay capability in Agent Operations, event history, replay, diagnostics, setup, billing/usage, safeguards, security, docs, or operator workflow; Use: Feature request; Do not use it for: Support incidents, platform expansion, generic wishlists, CRM/workflow-builder/data-sync requests, or unrelated software.

## Support request fields
Structured support requests include category, urgency, redacted summary, idempotency key, support consent, contact email when needed, and safe links to diagnostics, events, endpoints, or support codes.


## Expansion request fields
Use an expansion request only when a real merchant ask maps to interest in a future FlowRelay edition. State the current FlowRelay fit plainly. An expansion request is a review record, not a roadmap promise or a live future target.


## Feature request fields
Use a feature request only for a capability missing from the current product. Do not file generic wishlist items. A feature request is recorded as request_recorded_not_committed - it is reviewed, not scheduled.


## Feature request examples
Good feature requests point at a FlowRelay workflow gap. Poor requests ask FlowRelay to become unrelated software.


- Request: The agent needs Retry-After and reset metadata when Agent Operations throttles reads; Lane: Feature request; Why: Missing Agent Operations capability.
- Request: The event list should filter by stable error code and endpoint readiness; Lane: Feature request; Why: Current FlowRelay event-history gap.
- Request: Can FlowRelay support Notion automation handoff receipts and replay context?; Lane: Expansion request; Why: Future native-edition/platform demand.
- Request: This replay failed and I need help; Lane: Support request; Why: Active support/recovery issue.
- Request: Build a CRM; Lane: Neither; Why: Generic product wishlist unless restated as a FlowRelay event-intake or recovery gap.

## API behavior
Feature requests use POST /agent/v1/feature-requests, the existing expansion:request scope, installation-scoped linked-context validation, idempotency, redaction, executed-action audit, and a 10 per day installation limit.

The API returns request_recorded_not_committed. This confirms the request was stored for review only and conveys no commitment or timeline.


## Fit boundary
FlowRelay for Notion because a merchant needs reliable event handoff and recovery into Notion automations is an in-bounds demand signal. Build a CRM is out of bounds unless the request is actually about FlowRelay event intake, handoff, recovery, diagnostics, or approved agent operation into a CRM workflow.


## Future-memory boundary
Shopify Flow plus Wix Automations cross-platform reliability, operational memory for FlowRelay receipts, and exception handling for automated work are in bounds only as review signals tied to FlowRelay event memory, diagnostics, action previews, grants, audits, or recovery paths. They do not make FlowRelay a workflow builder, CRM, task database, or arbitrary data sync tool.


## What not to send
Do not send raw event bodies, endpoint secrets, authentication headers, HMAC values, tokens, Shopify sessions, database URLs, customer records, broad exports, or copied private incidents.


## Conversation boundary
Support conversations can continue by email, but FlowRelay keeps the request record, diagnostic links, grant context, audit trail, and status history tied to the installed store. Product-demand requests are reviewed separately, and a recorded request is not a public roadmap promise.


## Related
- [Share diagnostics](https://docs.flowrelay.app/recover/diagnostics.md)
- [Grants and scopes](https://docs.flowrelay.app/agent-access/grants-and-scopes.md)
- [OpenAPI](https://docs.flowrelay.app/reference/openapi.md)

## Safety Boundary
Do not share endpoint secrets, authentication headers, HMAC values, tokens, raw event bodies, customer records, Shopify sessions, store passwords, or database URLs in public examples.