Skip to content
AscendCore
🧪 Feature

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 changes leave the AscendCore process. The one outbound write is a note on the originating ticket, labeled Sandbox, when a request came from ServiceNow, Jira, or Freshservice and your org connected that system itself.

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 (labeled as sandbox)
  • • SHA-256 hash chain stays unbroken
  • • A note on the originating ITSM ticket, labeled Sandbox, through your own connection
  • • 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

  1. Sign in to your admin portal as an owner.
  2. Navigate to Settings → Test Mode.
  3. Toggle Sandbox. The yellow banner appears across the top of every dashboard page.
  4. Run any runbook from Slack or Teams. The approval card is prefixed 🧪 SANDBOX | so the approver can't miss it.
  5. When you're done, flip back to Live. Sandbox-tagged audit rows stay in the log; filter them out with the audit page's Production tab.

Audit log semantics

Sandbox events are recorded on the same tamper-evident audit chain as production events. Each event is labeled live or sandbox, and the dashboard's audit page filter pill lets you view either or both.

For SOC-2 / ISO evidence: use the "Production" tab, which filters sandbox rows out so your auditor sees only real activity. The page opens on "All", which shows both.

For the SHA-256 hash chain: sandbox and live events share one chain, so verify the full chain export, which labels each event's mode. Verifying only one mode's events shows gaps where the other mode's events sit.

Sandbox events can't be deleted. Audit records are append-only, and removing one would break the chain.

What happens if I flip mode mid-flight?

The mode is read when a card is approved, not when it was posted. A card always runs under the org's mode at the moment someone clicks Approve.

Live to Sandbox: if a card was posted while your org was Live and is approved after you flip to Sandbox, it runs against the sandbox mocks. The card reports the outcome, but nothing changes in your real systems. Re-run the request after you flip back to Live if you still want it carried out.

Sandbox to Live: a card posted in Sandbox is not meant to be approved after you go Live. Many are refused with a message asking the requester to start the request again, but not every card type is, so deny every open sandbox card before you flip to Live.

Before you flip in either direction, approve or deny the cards that are still open, and ask requesters to start any remaining requests again under the new mode.

What sandbox mode is not