Safe fallback paths
Use safe fallback paths to choose ticket_only_fallback, customer-applied evidence and retest_status when connected platform access is missing, too broad or unsafe.
Site owners, developers and agencies
Feature availability
Product, package, provider and deployment boundaries for this page.
- Available from
- Current documentation
- Providers
- wordpresswoocommerceshopifygtmcmp
- Deployment modes
- cloudself-hosted
Before choosing fallback
Use this page when connected repository, CMS, Shopify, GTM or CMP/config access is missing, expired, too broad, unsupported or unsafe. Safe fallback keeps remediation inside the product flow through ticket exports, portable instructions, customer-applied evidence and retest tracking. Fallback is not an untracked side path. The product should still preserve report evidence, customer-safe instructions, customer_applied_status and retest_status.
- Use ticket-only fallback when a connected platform scope is missing, expired, too broad, unsupported or unsafe.
Prepare safe fallback
Follow the path `Access mode blocked → Ticket-only fallback → Customer-applied evidence → Retest → Connected access only if safe`.
- Open /reports/{report}/ticket-exports after connected access is missing, too broad, unsupported or unsafe. Result: ticket_only_fallback and provider export options are visible without requesting credentials.
- Choose provider ticket, portable export or customer-safe instructions. Result: fallback output matches the customer tool without needing connected platform access.
- Include report evidence, affected URL, expected change and customer-applied instructions without secrets. Result: the customer can act without sharing credentials, tokens or private source.
- Track customer_applied_status after the customer confirms the change. Result: the product knows whether a retest can start.
- Run or schedule the retest after evidence is applied. Result: retest_status records fixed, regressed, unchanged or inconclusive outcome.
- Return to connected access only if required_scopes later become safe and approved. Result: fallback does not become an untracked workaround outside the product flow.
Ready fallback states
Continue only when the product shows a customer-safe fallback state.
- Ticket fallback ready means ticket_only_fallback includes issue evidence, expected change and customer-safe instructions.
- Portable export ready means portable_export_status can produce a customer-owned package when a provider is missing.
- Customer applied pending means the customer can mark work complete without granting connected access.
- Retest ready means customer_applied_status is ready for retest and retest_status can record the outcome.
- Connected access reconsidered means required_scopes are safe and approved before returning to a connected access path.
Blocked or unsafe fallback states
Do not work around unsafe fallback output. Fix the artifact before exporting or asking the customer to apply changes.
- Missing provider means use portable export instead of blocking the customer.
- Unsafe scope means stay in ticket-only fallback and do not request credentials.
- Sensitive evidence means redact the artifact before export.
- Missing customer action means do not start retest until customer_applied_status is ready.
- Unclear expected result means revise the customer-safe instruction before exporting it.
- Provider duplicate risk means use ticket-export duplicate handling before creating another external task.
Continue to deployment distinctions
Continue to Cloud and self-hosted distinctions when fallback is needed because the customer environment, private network, agency-managed stack or self-hosted deployment changes what connected access can support. Use Ticket export provider overview or Portable export fallbacks when the next step is choosing an export destination. Use Retest outcomes after the customer confirms the fallback instruction was applied.
Related documentation
Was this page helpful?
Feedback goes into the product documentation review queue.

