Sandbox Workspace

The Sandbox Workspace is the per-connection UI for working with the simulator that backs Sandbox Mode. Every integration config page has a Sandbox tab. When the config's sandboxMode is SIMULATED or READ_THROUGH, the tab has 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 follows the config's saved sandboxMode:

Pick a Sandbox routing under Advanced on the Overview tab; the empty state's Set up sandbox routing button opens it for you. The Sandbox tab lights up as soon as the change is saved, but runs use the published mode, so publish before you test.

A sandbox run still sends a NONE connection's writes to the simulator by default, and they're stored for that connection. The tab shows them once you switch the connection to Simulated or Read-through.

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.

The automatic snapshots taken before each sandbox run and evaluation aren't listed here. A run's pre-run snapshot is what Revert all on its Sandbox impact card restores.

See what an agent run did: the Sandbox impact card

Before any tool runs, every sandbox run auto-snapshots each connection it routes to the simulator: one saved as SIMULATED or READ_THROUGH, one you set to Simulated or Read-through for that test, and one with no sandbox saved that the run sends there by default. 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 connection:

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 — opens that connection in Integrations; its Sandbox tab has 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. After a revert the card reads Sandbox state reverted to pre-run baseline. and the Revert all button goes away, so you can't trigger it twice.

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. Paste a run's execution ID to see only what that 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 under Advanced on its Overview tab set Sandbox routing 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, then on its Sandbox tab filter Activity by this run's execution ID to see the calls behind those 8 changes.
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 connection. Everyone testing against one connection — in any session, with any agent bound to it — shares one simulated store and sees the others' writes. The store is per connection, not per session or per agent. Treat sandbox state as a shared resource.
• Vendor mode is opaque. When sandboxMode = VENDOR, the Sandbox tab shows its empty state, and a connection routed to its vendor sandbox gets no row in the Sandbox impact card. 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.
• Evaluations — always run in sandbox mode, and refuse to start until every integration they use has a sandbox. An evaluation snapshots each simulated connection before it starts and restores that snapshot when it finishes, so its writes don't stay behind.