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 a nutshell

• 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 fields are not available. Use the variable defensively by adding defaults:

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

• Apply this pattern when using data that is not pre-auth to avoid empty values conditions that won't match. 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 fields in this state.

  • Hubble skips auth‑dependent conditions inside Dynamic blocks' settings, if no other available condition exists it shows the Default setting if present. Static blocks render as usual.

• Authenticated customers

  • After logging in, all fields are available.

  • Dynamic block conditions can match and display personalized content.

How matching via Conditions works today

• Static blocks

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

• Dynamic blocks

  • Pre‑auth: Auth‑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 auth-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.