Sandbox Mode
Exercise the full Slack/Teams approval flow end-to-end — without modifying a single real user, license, group, or device.
In one sentence
Inbound + outbound communication with your people stays real (Slack and Teams cards post to your actual workspace), but outbound system mutations are mocked — no real Okta, Entra ID, M365, Intune, Jira, or Confluence calls leave the AscendCore process.
What stays real vs. what gets mocked
✅ Stays real
- • Slack approval cards post to your real workspace
- • Teams approval cards post to real conversations
- • Approval clicks are captured + acknowledged
- • Audit log writes (tagged
mode: "sandbox") - • SHA-256 hash chain stays unbroken
- • Rate limiting + plan-tier enforcement
🧪 Routes to mock
- • Okta API (users, groups, factors, passwords)
- • Microsoft Graph (Entra users, groups, licenses)
- • M365 license assign/revoke
- • Intune device sync + configuration
- • Jira REST API (users, project roles)
- • Confluence REST API (spaces)
Why this exists
1. Procurement-grade pilot
Run AscendCore against sandbox for the first 1–2 weeks of onboarding before flipping to production-targeting integrations. Removes the "what if a runbook accidentally locks out our CEO?" anxiety on day one.
2. Training new IT staff
New analyst onboarding? Practice approving cards in sandbox before getting production permissions. They see the entire approval flow including the audit trail — without risk of an accidental offboard.
3. Regression testing
Want to verify a new runbook flow end-to-end before unleashing it on real users? Flip to sandbox, run it twice, verify the audit trail, flip back. No cleanup required.
How to enable
- Sign in to your admin portal as an owner.
- Navigate to Settings → Test Mode.
- Toggle Sandbox. The yellow banner appears across the top of every dashboard page.
- Run any runbook from Slack or Teams. The approval card is prefixed
🧪 SANDBOX —so the approver can't miss it. - When you're done, flip back to Live. Optional: use the Reset sandbox audit history button to clear the sandbox-tagged audit rows.
Audit log semantics
Sandbox events are written to the same audit_events table as production events. Each row carries a mode column ("live" or "sandbox"), and the dashboard's audit page filter pill lets you view either or both.
For SOC-2 / ISO evidence exports:use the "Production" tab. Sandbox rows are filtered OUT by default — your auditor sees only real activity.
For the SHA-256 hash chain: the mode tag is notpart of the canonical record that produces each row's hash. Sandbox rows chain identically to live rows — your independent chain verification works on either subset.
What happens if I flip mode mid-flight?
Cards honor the mode they were created under, not the current org mode at approval time. So if you posted a live approval card in Slack, flipped to sandbox, and then approved the card — it still executes against your real systems. The flip affects only future card creation.
What sandbox mode is not
- Not a separate workspace. Slack and Teams still post to your real workspace — only the downstream API calls get mocked.
- Not chaos engineering.Mock responders always succeed; they don't simulate failure scenarios (Phase 4 may add this).
- Not free of rate-limit accounting.Sandbox calls count against your plan's rate limit (prevents free-tier abuse via mass sandbox runs).
- Not multi-tier. One sandbox per org, not staging / dev / qa / sandbox tiers.
