Start with the problem,
not the feature name.

Describe the broken contract.

The most useful question says what should have happened, what happened instead, and which record or user was involved. “My list is broken” leaves several layers open. “The logged-in user should see only joined events, but every event appears after I add the relationship filter” identifies the expected result, visible failure, and likely data boundary.

Include the collection names, relevant property types, relationship direction, screen data, filters or conditions, and action order. Mention whether the behavior appears in Preview, a published web app, or a native build. If the failure changes after navigation or refresh, say so—that often distinguishes temporary component state from data that was actually saved.

Do not submit passwords, API keys, private user records, or screenshots containing sensitive information. A tiny anonymized example with two users and three records is usually more diagnostic than a full production database. Questions help prioritize future answers, but submission does not promise private support or a response on a particular schedule.

Before sending, reproduce the problem once with the simplest possible data and note the last step that still behaves correctly. Include that boundary in the message.