Chain-local surveys and chain-only steps solve a problem that shows up once a workflow gets more structured: some questions belong inside a chain, but not all of them should behave the same way. Some should stay reusable across the project. Others should belong to one chain only. Conejo supports both patterns, but the names can sound similar if you have not used them yet.

The short version

• Shared survey: a project-level survey that can be used directly and, depending on availability, can also be used in chains.
• Chain-only survey: a shared survey whose direct route is closed, so it only collects responses through chains.
• Chain-local survey: a survey owned by one specific chain. It is automatically chain-only and is meant to live inside that chain.

If you want to reuse a question across multiple chains, keep it shared. If the question belongs to one chain only, make it chain-local.

What chain-only actually means

Chain-only is an availability decision. It tells Conejo that the survey should not collect responses through its own direct public route. Instead, it should only be reachable when someone is moving through a chain.

That changes a few practical things:

• the direct survey link shows a closed page,
• standalone access settings stop being the main way the survey is managed,
• scheduling, access, and response limits are meant to be handled by the chain that is presenting the step.

This is useful when a question is part of a guided path and does not make sense as a standalone prompt.

What makes a survey chain-local

Chain-local is not just another label for chain-only. It is a different scope. A chain-local survey is owned by one chain and is meant to stay attached to that chain. In the data model, it is marked as chain-local, assigned to an owner chain, and automatically set to chain-only availability.

That means the survey is not just hidden from standalone sharing. It is treated as part of that chain's internal workflow shape.

In practice, this is what makes chain-local useful:

• the step belongs to one chain,
• sharing and QR distribution happen from the parent chain,
• editing the step does not accidentally turn it into a reusable project-wide building block,
• the question can evolve specifically for that one chain.

When to use a shared chain-only survey

Choose a shared survey with Chain Only availability when the question should be reusable across more than one chain, but still should not collect responses directly on its own route.

This is a strong fit when:

• the same follow-up question appears in several chains,
• the project wants one reusable building block for multiple workflows,
• the question belongs in chains operationally but should still be managed at the project level.

In this setup, the survey stays shared, but its direct standalone path is closed.

When to use a chain-local survey instead

Choose a chain-local survey when the step should belong to one chain and should not be treated like a reusable shared asset. This is usually the better choice when the wording, logic, or role of the question is specific to one flow.

Chain-local is a strong fit when:

• the step only makes sense in one chain,
• you want to edit it freely without affecting other workflows,
• the chain needs custom layout or helper steps that are not meant to be shared around the project,
• you want a cleaner boundary between reusable project surveys and chain-specific steps.

How flexible surveys fit into the picture

Flexible surveys are the bridge between standalone and chained use. A flexible survey can be shared directly and can also be included in chains. When it is used in chains, chain access can still be toggled on or off. This is useful when a survey should stay available in both contexts.

That makes flexible the right fit when the question is genuinely dual-purpose. If the survey really belongs only inside a guided flow, chain-only or chain-local is usually the cleaner choice.

How to think about direct links, QR, and settings

The easiest way to remember the sharing behavior is this:

• Shared standalone or flexible survey: share its own direct link or QR code.
• Shared chain-only survey: do not share the survey directly; share the chain route that contains it.
• Chain-local survey: always share through the parent chain, because the chain owns the respondent-facing route.

That same rule applies to scheduling and access expectations. Once a step only collects through chains, the chain becomes the main surface for deciding when and how the respondent can reach it.

Common mistakes to avoid

• Using chain-local when the survey should really be reusable. That creates unnecessary duplication later.
• Keeping a survey flexible when it no longer makes sense as a standalone route. That leaves extra sharing paths open for no good reason.
• Treating chain-only and chain-local as the same thing. One is availability; the other is ownership and scope.
• Sharing a direct survey link for a chain-only step. The respondent should enter through the chain instead.

A practical decision rule

If the question should be reused across flows, keep it shared and choose the right availability mode. If the question belongs to one flow and should stay with that flow, make it chain-local.

That one distinction usually clears up the whole decision:

• Reusable? Shared survey.
• Chain access only? Shared survey with chain-only availability.
• Owned by one chain? Chain-local survey.

Where to go next

Once this distinction is clear, the next useful step is usually deciding how the rest of the chain should behave: branching logic, presenter and QR sharing, or whether the completed flow needs a dashboard for review. The better you separate reusable shared surveys from chain-local steps, the easier those later workflow decisions become.