Add application/survey intent type (create, edit)

[dhegstad]

Proposed type

• Type: application/survey
• Actions: both create and edit
• One-line summary: A structured set of questions an app shows to shoppers (post-purchase thank-you / order status pages, POS, or shareable link) to collect attribution, satisfaction, or research data for the merchant.

Why this type

Real merchant asks this captures:

1. "Create a post-purchase survey asking customers how they heard about us" — the canonical attribution survey, the single most common survey use case on Shopify.
2. "Add a TikTok option to my 'how did you hear about us' survey" — an edit that today requires finding the right app, survey, and question by hand.
3. "Set up an NPS survey on the order status page" / "pause the in-store survey during BFCM" — create and lifecycle edits across placements (web checkout and POS).

Who would register intents for it

• OrderSurvey (ours — post-purchase surveys on Thank-you / Order status pages and POS) would register both actions immediately.
• The Shopify survey app category is deep and every app in it maps cleanly onto this shape: Fairing, Zigpoll, KNO Post Purchase Surveys, Grapevine Surveys, and others. All share the same core artifact: named survey → ordered questions (select / text / rating / NPS) → placement(s) → active window.

Schema sketch

Full draft is inline in types/application-survey.md in this PR. Shape summary: id, name, status (draft/active/paused), placements (thank_you/order_status/pos/link), questions[] (prompt, type, options, allow_other), success_message, starts_at/ends_at.

Confirmed:

• inputSchema does not declare required fields
• Field names are consistent with neighboring types in types/ (snake_case, matching fields proposed on application/review)
• For application/*, the schema refs the canonical application schema (TOML example $refs the would-be canonical URL; draft inline pending publication)
• For shopify/* — n/a

Prior art

• application/review is the closest existing type, but it models a public, product-scoped, single-rating artifact authored by a customer. A survey is private, merchant-scoped, multi-question, and placement-aware — the only overlapping field is id, so extending review would fragment it.
• application/faq is published content shoppers read; a survey is a form shoppers answer — opposite data direction.
• application/campaign may distribute a survey, but the questionnaire artifact itself (questions, placements, scheduling) has a distinct shape.

Anything else

• Open question: should shopper-response reading ("what are customers saying in my survey?") be in scope later? We deliberately scoped this proposal to the questionnaire artifact only (create/edit), since responses feel like app data rather than a Sidekick-editable artifact — but we'd welcome reviewer input.
• Branching/conditional questions and audience targeting are listed as commonly-proposed extensions rather than v1 fields, to keep the initial schema small.

🤖 Generated with Claude Code

[dhegstad]

I have signed the CLA!

[dhegstad]

Friendly bump — this is just past the 5-business-day mark from the CONTRIBUTING SLA, so flagging for triage. cc @shopify/sidekick-intents, and @adambarrus in case the team alias doesn't reach anyone.

Happy to iterate on the schema. placements and status are the two fields I'd expect to draw the most comment, since they're the likeliest to vary per app, and I'm glad to drop link from placements — it's the one value with no Shopify surface behind it.

One catalog-level question I'd value your read on, since it changes how much belongs in this type versus elsewhere. Every application/* type in types/ today declares exactly create and edit, which is what this PR follows. But two of the most common things a merchant will actually ask Sidekick about a survey are a read ("how many people have answered?") and a destructive action ("delete the BFCM survey"):

• Are reads meant to stay out of intent types entirely and be served by app-registered tools instead? That's my assumption, but I'd rather confirm than guess.
• If so, can an app expose a tool to Sidekick standalone, or only while an intent UI is open? Ours is registered at runtime from the open intent surface.
• Is the absence of delete across the catalog deliberate? I've left it out to match convention rather than propose it unilaterally, but it's an obvious merchant ask and I'd happily add it if you'd take it.

Separately, CONTRIBUTING notes that merging documents the proposal but doesn't publish the type. Whenever there's even a rough sense of the publish timeline for extensions.shopifycdn.com, that would help — we have the extension built against the draft schema and would be the first adopter, so we're sequencing our release against the publish date rather than the merge.

Thanks!

[adambarrus]

Hi @dhegstad, first: apologies for the slow turnaround. This sat well past the SLA in our CONTRIBUTING guide and that's on me. Thank you for the patience and for a genuinely well-constructed proposal: the prior-art analysis against review, faq, and campaign is exactly what we hope to see, and the merchant asks you anchored it in are real ones.

Initial reactions while we do a full schema review:

1. The type makes sense. The survey app category is deep, and the core artifact (named survey, ordered questions, placements, active window) is consistent across the category. Extending review would have fragmented it; you made the right call proposing a new type.
2. placements: agree this is the field most likely to vary per app. I'd take you up on dropping link from v1 and keeping the enum to Shopify surfaces (thank_you, order_status, pos). Apps with shareable-link surveys can extend later once we see real usage.
3. status: draft/active/paused reads clean. We'll double-check lifecycle vocabulary against neighboring types before merge so the catalog stays consistent.
4. Scoping shopper-response reading out of v1 is the right call. Responses are app data; the questionnaire artifact is the Sidekick-editable surface.

Next step: I'm getting engineering eyes on the draft schema and will come back with a consolidated review by end of this week. Thanks again for being an early adopter here, this is the kind of contribution the catalog needs.