Authentication states

Overview

Hubble supports blocks for customers who arrive via secure email links to Shopify account pages, most commonly the Order Status page. In this pre‑authenticated state, Shopify restricts many customer fields from the Customer Accounts API. Hubble handles this by showing safe general content until the customer logs in, at which point personalized content can display.

Block types in Hubble

• Static blocks

  • No display conditions. Ideal for universal messages and banners.

• Dynamic blocks

  • Can define one optional Default setting as a fallback.

  • Can add multiple additional settings with conditions that resolve when met.

• Special blocks

  • Purpose‑built blocks with unique features and a separate creation flow. Some can also be used with conditions.

Using variables with safe defaults

• You can reference variables like {{ customer.first_name }} in any block type.

• In pre‑auth, some customer fields are not available. Write defensively by adding defaults:

  • Example: Hello, {{ customer.first_name | default: "buyer" }} !

• Apply this pattern anywhere you use customer data to avoid empty values in pre‑auth. This keeps content clear for guests and personalized for logged‑in customers.

What customers see

• Pre‑authenticated customers

  • Can open account pages via secure email links, commonly the Order Status page.

  • Shopify limits access to many customer fields in this state.

  • Hubble skips customer‑dependent settings with conditions inside Dynamic blocks and shows the Default setting if present. Static blocks render as usual.

• Authenticated customers

  • After logging in, customer fields are available.

  • Dynamic block conditions can match and display personalized content.

How matching via Customer targets works today

• Static blocks

  • Always safe to show as they aren't used with Customer targets.

• Dynamic blocks

  • Pre‑auth: Customer‑dependent conditions are skipped. If the dynamic block doesn't find a matching setting available and it has a Default setting, Hubble shows it when defined.

    • Note: There is no extra configuration for pre‑auth behavior at this time. The “default” behavior above is built‑in.

  • Auth: All conditions are evaluated normally. If none match, the Default setting acts as fallback when defined.

Best practices

• Always include a useful Default in dynamic blocks

  • This ensures guests see relevant content even when customer data is unavailable.

• Keep defaults non‑sensitive

  • Reserve sensitive or personalized content for authenticated views.

• Use defensive text with variables

  • Provide defaults like {{ customer.first_name | default: "buyer" }} to avoid empties in pre‑auth.

• Leverage static blocks for universal messages

  • Shipping promos, policy notices, and storewide CTAs are ideal candidates.

Testing your setup

• Create a test order via normal checkout.

• Open the Order Status link from the confirmation email in an incognito window to simulate pre‑auth.

• Confirm that static blocks and dynamic block Defaults appear as expected.

• Log in to confirm personalized conditions render for authenticated customers.

References

• Shopify: About the Order Status page.

• Shopify: About pre‑auth order status UI extensions.