# Support and expansion 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 and expansion requests are recorded in FlowRelay so humans and authorized agents work from the same safe request history.

## Steps
Complete these in order.
1. Use support.request.preview before sending a support request. 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.request.submit 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. Treat expansion requests as requests for review, not product commitments, generic product wishlist items, or permission to treat another edition or capability as live.

## 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
Expansion requests include expansion type, FlowRelay fit, triggering context, a concrete FlowRelay reason, requested edition/platform context, requested capability, use case, optional business impact, urgency, optional volume or operating context, and an idempotency key. They are grouped for review.


## 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.


## 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 include raw event bodies, endpoint secrets, authentication headers, HMAC values, Shopify tokens, Shopify sessions, database URLs, customer data, merchant incidents, or copied private logs in public examples.