Sandbox Workspace

The Sandbox Workspace is the per-integration UI for working with the simulator that backs Sandbox Mode. When a config's sandboxMode is SIMULATED or READ_THROUGH, a new Sandbox tab appears in the integration config page with four sub-tabs: Data, Snapshots, Activity, Generate. A separate Sandbox impact card appears under every agent run that touched a simulator sandbox, with one-click revert.

This page covers the end-to-end workflow: seed data → run an agent against it → inspect what changed → revert if needed. For background on the four routing modes themselves, see Sandbox Mode.

When the Sandbox tab appears

The Sandbox tab is gated on the config's published sandboxMode:

Switch routing on the Overview tab and publish. The Sandbox tab lights up on the next refresh.

Generate seed data from a description

The Generate sub-tab is the fastest way to populate a fresh sandbox. Describe what you want — entity type, scenario, edge cases — and Fruxon's internal sandbox_data_generator agent produces realistic JSON payloads.

Example prompt:

30 issues for a fintech team mid-sprint, 5 in progress, 2 blocked, mix of bugs and tasks, priorities skewed toward High

Fill in the form:

• Entity type — must match a schema the integration declares (e.g. issue for Jira, contact for HubSpot).
• Count — 1 to 100 per call. Run multiple times for larger seeds.
• Scope (optional) — for entities that live under a parent (a Jira project key, a Slack workspace id).
• Description — natural language; the more specific, the better.

Each generation auto-snapshots the post-generation state as Seed: <prompt summary>. That snapshot becomes the natural revert point — re-running a generation never destroys earlier data; restoring the seed snapshot does.

Browse what's in the sandbox

The Data sub-tab is a per-entity-type table backed by the live simulator store. Click a row to open a JSON drawer with the entity's payload — edit fields and save, or tombstone the entity entirely. Tombstoned rows stop appearing in List tool responses but remain referenced from any past SimulatedToolCall so traces stay reconstructable.

Filter by entity type (chip click) or scope (text input). Empty filters show everything across types and scopes for the config.

Snapshots: bookmark and revert

The Snapshots sub-tab is for bookmarking a known-good sandbox state.

• Take snapshot — captures every entity and sequence counter for this config. Snapshots are stored as JSONB blobs; capture is fast for small-to-mid datasets.
• Restore (↶ icon) — replaces current state with the snapshot. Existing entities, sequences, and tool-call audit history are cleared and replaced. The snapshot itself is kept; restore is non-destructive to the snapshot.
• Diff (⇆ icon) — opens a side-by-side view of the snapshot vs current state: added, modified, and removed entities, with before/after JSON for each modification. Useful for debugging "what changed since I took this snapshot?"
• Delete — destroys the snapshot. Current state is unaffected.

Auto-snapshots from evaluation runs and test-chat sessions are hidden by default; toggle "Show automatic" to inspect them.

See what an agent run did: the Sandbox impact card

Every agent execution that runs in SANDBOX mode auto-snapshots every simulator-routed bound config before tools execute. After the run completes, a Sandbox impact card surfaces in two places:

• Agent Studio chat — directly below the chat input after each sandbox turn.
• Execution detail page — under the Final Result section of every past run.

The card has one row per touched integration config:

Sandbox impact                                              [Revert all]
─────────────────────────────────────────────────────────────────────────
 Jira / Acme prod (Simulated)     +3 issues, 2 modified, 0 removed   8 calls   [Open]  [⋮]
 Slack / #eng (Simulated)         +1 sent message                    1 call    [Open]  [⋮]

• +3 / ~2 / −0 — added, modified, removed entities since the pre-run snapshot.
• 8 calls — distinct SimulatedToolCall rows the run produced against this config.
• Open — deep-link to that config's Sandbox tab so you can drill into the per-entity details.
• ⋮ — per-row menu for future per-config revert (revert-all is the default action above).

Revert all restores every snapshot in the run's group and deletes them — a one-shot rewind back to the pre-run baseline. The card hides after revert so you don't accidentally re-trigger it; reload the page to see it again with collapsed counts.

The card self-hides for production runs and for sandbox runs that touched no simulator-routed configs (the impact endpoint returns an empty list, the card renders nothing).

Activity: the audit log

The Activity sub-tab is the unfiltered SimulatedToolCall ledger for the config — every call the simulator served, in reverse-chronological order. Click a row to see the response payload that was handed back at the time of the call.

Two query filters keep the view manageable:

• Tool key — exact match (e.g. jira.create_issue).
• Execution ID — scope to a single agent run. The Sandbox impact card's per-row Open link pre-fills this filter so you land on "only what this run did."

The activity log is the source of truth for traces and replays — it captures the exact response shape the agent saw, independent of later mutations to the underlying simulated entity.

End-to-end: a typical workflow

A user building a Jira-backlog-scanner agent:

1. Connect Jira as a regular integration config, then on Overview switch sandboxMode to SIMULATED and publish.
2. Generate → entity type issue, scope PROJ-ACME, count 30, prompt "mid-sprint fintech backlog with mix of bugs and tasks, 5 in progress". Auto-snapshot lands as Seed: mid-sprint fintech backlog….
3. Browse the Data sub-tab to spot-check the generated issues.
4. Open Agent Studio, toggle the chat to Sandbox mode, send the test message ("plan today's sprint").
5. Watch the Sandbox impact card appear below the chat: "Jira / Acme prod — +0 issues, 8 modified, 1 sent" (the agent transitioned statuses and dropped a Slack message).
6. Click Open on the Jira row to see exactly which 8 issues changed (filtered to this execution).
7. Revert all to rewind back to the seed snapshot; tweak the agent's prompt; re-run.

Limits and known caveats

• Snapshot size. Entities serialise into one JSONB column per snapshot. Fine for hundreds of entities, expensive for thousands — restore is a single DELETE + INSERT ALL transaction. Flagged for a future child-table + incremental restore upgrade when usage grows.
• Concurrent sessions on the same config. Two users testing the same agent against the same simulator config will see each other's writes. The simulator is per-config, not per-session. Treat sandbox state as a shared resource until per-session isolation lands.
• Vendor mode is opaque. When sandboxMode = VENDOR, the Sandbox tab is hidden and Vendor rows in the impact card show "no diff — vendor sandbox is opaque to Fruxon". Reading state out of Salesforce Sandbox / Stripe test mode is a different problem and out of scope here.
• Generator quality scales with prompt specificity. "Make me some issues" produces generic payloads. "30 fintech sprint issues, 5 in progress, 2 blocked, mix of bugs and tasks" produces realistic ones. The payload_shape template the simulator declares for the entity type is fed to the meta-agent as a hint.

Related

• Sandbox Mode — the four routing modes (None / Vendor / Simulated / Read-through) and how Fruxon decides where each tool call goes.
• Evaluation runs — evals execute in SANDBOX mode by default; the same auto-snapshot + impact pipeline backs the per-revision behavioural comparison.