For Support

This PR doesn't touch the production product — nothing here affects real clinic accounts, patient data, or anything a support ticket from an actual customer would reference. It's scoped entirely to the main demo/training sandbox and other branch sandboxes deployed via Sandbox Ops → redeploy. Treat this page as internal runbook material, not customer-support material.

What might land in an internal "why doesn't the demo sandbox have X" question

"WhatsApp isn't working on the main demo sandbox." Expected, unless someone has explicitly enabled it. Check the repository's Settings → Environments → sandbox for a SANDBOX_MAIN_WHATSAPP variable set to true. If it's missing or false, that's the default — see Overview. If it's set to true but the sandbox still shows the "Feature Disabled" screen (see Walkthrough), the sandbox likely hasn't been redeployed since the variable was added — this mechanism only takes effect on the redeploy action (sandbox-ops.yml:65), not automatically on the next push. Run Actions → Sandbox Ops → redeploy on main.

"I set a SANDBOX_MAIN_* variable but nothing changed on a PR sandbox." Expected — the prefix only applies to main (or whichever branch matches the REF portion). PR sandboxes are configured exclusively through their own PR description's ## 🧪 Sandbox block; this environment mechanism does not apply to them at all — it only fires when sandbox-ops.yml runs against a branch, not the automatic sandbox.yml PR flow.

"I set SANDBOX_ALL_QUEUE=false and it didn't affect the branch I care about." Check for a more specific SANDBOX_<BRANCH>_QUEUE variable — branch-specific settings always win over SANDBOX_ALL_* for the same key (see Environment-sourced settings).

Where to look when a redeploy silently doesn't pick up a change. The "Compose sandbox settings from the sandbox environment" step in the Sandbox Ops job log has a collapsed 🧪 sandbox settings (from environment) group — it prints the resolved toggles and the names of any env keys that were composed (not their values). That's the fastest way to confirm whether a variable/secret was actually picked up, correctly prefixed, and not shadowed by a typo.

What you can't diagnose from the app itself

Because this is purely a deploy-time composition step, none of it is visible from inside the Dentolize app UI or its logs — only from the GitHub Actions run log for the Sandbox Ops workflow. If someone reports unexpected sandbox behavior tied to this, you need Actions access (or someone who has it) to check the run log, not the app's own admin/support tooling.