Features

The extension ships 46 features (count generated from the extension’s own registrations). Every feature is opt-in — toggle it on or off in the options page — and any feature can be remotely disabled without a Web Store re-review.

Features are surfaced through the ⚡ side button menu, which adapts to the page you’re on (Setup, a Flow list, the Flow canvas, a record page, or the standalone Workspace tab).

Highlights

A few features aren’t tied to one Salesforce context — they open from anywhere, or add a whole sub-view to an existing tool.

Command palette (command-palette)

A global, keyboard-first ⚡ overlay on any Salesforce page — press Ctrl/Cmd+Shift+K (or pick View all features from the ⚡ menu). Fuzzy-search across your enabled features, Setup deep-links, objects, a pasted record Id (opens the inspector), and your own custom shortcuts. Recent choices resurface first. Opening it makes zero Salesforce API calls — the Objects list fills in after first paint. Manage custom name→URL shortcuts on the options page; they open in a new tab and reappear under Recent.

Docked side panel

The tools can also run in a docked Chrome side panel (Firefox: native sidebar_action) instead of the centered modal — open it from the toolbar popup’s Open side panel button. It hosts the full Workspace next to the page you’re on, follows the active org as you switch tabs (and quietly disables itself on non-Salesforce tabs), and an Appearance › Default tool surface setting lets you prefer the panel over the modal. Chrome-only, via the sidePanel permission.

SOSL mode in the SOQL Runner

The runner’s toolbar carries a SOQL | SOSL toggle, and the mode also follows what you type — a query whose first keyword is FIND switches to SOSL, a SELECT switches back. That is the same rule the CLI (sfdt soql) and the SOQL Console use, so a query behaves the same in all three places. Clicking the toggle wins over that inference: your choice holds through further edits of the same query, and detection takes over again only when the query’s own language changes.

SOSL results are grouped per returned object: one labelled section per sObject (Account · 2 rows), each with its own table and its own copy of the result toolbar — Copy CSV, Export CSV, Copy JSON, Copy for Excel — so copy and export apply to that object’s rows only (the export filename is per object too). History and bookmarks record the mode and restore it, badging each entry SOQL or SOSL.

In SOSL mode the REST/Tooling toggle and Explain are disabled — the Search resource has no Tooling variant and no query plan. Your transport choice is only unavailable, never reset: SOSL runs on REST because that is all it can run on, and switching back to SOQL puts you back on Tooling if that is where you were.

Generate query (soql-nl-generate)

Describe the query you want in plain English and the SOQL arrives in the editor, for you to read before you run it. Generate query in the runner’s toolbar opens a panel above the editor: type a description, optionally name the objects (leave it blank and they’re inferred from your wording, matched against the org’s own sObject list — never invented), press Generate. The result is written into the query editor and the status line reads review it, then Run. Nothing runs on its own; Run is still the only thing that touches the org, and pressing it is still yours to do.

What is sent, and what is not. The prompt carries your description plus a Markdown field table per object — the same format export-for-prompt copies to your clipboard — built from the object describe: API name, label, type, required, inline help text, and nothing else. It does not carry record data. The prompt assembler is never handed the result set, and a second check scans the assembled prompt (minus your own wording, which is yours) for any value from the results table on screen and refuses the send if it finds one. Large objects are capped at 150 fields, and the prompt says so rather than truncating silently.

Where it goes. Through the bridge to your local sfdt CLI, using the same ai request the Flow AI Assistant uses — the extension holds no AI endpoint and no API key, and this feature adds no browser permission. The CLI decides the provider under your own key. With no bridge running, an unpaired token, or "features.ai": false in the project’s .sfdt/config.json, the panel shows what the bridge said plus the steps to fix it.

A generated string that fails the local SOQL checks — the same rules as sfdt soql validate — is reported in the panel rather than pasted over whatever you already had in the editor. Generation is SOQL only: switching the runner to SOSL closes the panel and disables the button.

Bulk delete from a SOQL result set (soql-bulk-delete)

With it on, and when your result set includes an Id column, the SOQL Runner’s result toolbar gains Delete N rows — and each SOSL object group gets its own, scoped to that object’s rows. The count on the button is the preview: it re-counts on every run and after Load more, and the button disappears again if the next query returns no Id. A flat result set whose rows span more than one object gets no button either — the runner refuses rather than guess which object to delete against.

There is no cap on N. One run deletes every loaded row the plan accepts — the only ceiling is how many rows the runner is holding, and Load more will stack up to ten pages. The count in the button and in the typed phrase is the only thing standing between you and that number.

Clicking it runs a fixed sequence, and there is no path through it that skips a step:

1. A backup CSV is generated and handed to your browser — exactly the rows about to be deleted and nothing else, serialised by the same code as Export CSV, so it quotes commas and quotes identically to the export you already use.
2. A modal asks you to type the phrase exactly — DELETE 12 Account. Confirm stays disabled until it matches; Escape and the backdrop cancel, and can never confirm. The count is inside the phrase deliberately: you can retype DELETE from muscle memory, but not a number you have not read.
3. Only then does anything reach the org, in waves of 25 with a live progress count. A Cancel button stops the next wave; so does closing the runner or running a new query. Rows already sent cannot be recalled.

A failed row does not abort the run: every row that did not delete is listed afterwards by Id, with its reason. A row that timed out is called out separately as may still have committed — the request never came back, so re-run the query to see what is actually left rather than retrying blind and deleting something twice.

Rows the org confirms are gone disappear from the table; rows that failed — including the timed-out ones — stay, because they are the ones to re-check. Deletes follow the runner’s REST / Tooling toggle, and add no new extension permission — they go through the same worker-proxied session every other write already uses.

Schema Browser (schema-browser)

A two-pane object/field explorer — a searchable, windowed object list beside a per-object field table (types, lengths, required, inline picklist values, formula source, flattened compound fields, reference targets as clickable cross-links, and child relationships). Copy API name on any field, Insert into query to drop a field straight into the SOQL Runner draft, and an Export selected for prompt field picker (every field pre-selected; unselect what you don’t want) that hands the chosen fields to export-for-prompt. Runs as a Workspace tool and from a record page via the ⚡ menu; all describes share one session cache.

Field Impact Analysis (field-impact)

“What writes this field?” — the question a schema browser can’t answer. Open it from the Schema Browser’s per-field What writes this? action, from the Show API Names panel’s field picker, or standalone from the Workspace / ⚡ menu, and it gathers three kinds of writer for one Object.Field:

• Flows — MetadataComponentDependency narrows the candidates, then @sfdt/flow-core parses each candidate’s metadata and keeps only the ones that actually write the field (Create/Update Records field assignments, and $Record.Field__c-style Assignment elements). A flow that merely reads the field in a filter or entry criterion is dropped — something a raw dependency query cannot do for you.
• Workflow field updates — read from the Tooling API, which names the target field outright.
• Apex — a best-effort Tooling text search over class and trigger source.

Every row is badged confirmed or inferred, the same vocabulary the CLI’s sfdt dependencies --gaps report uses:

An inferred hit is never shown as confirmed, and the confirmed/inferred counts are reported separately.

Scan limits and precision are both stated rather than hidden, in a Scan scope note. A standard field has no dependency edge to narrow by, so Flow coverage falls back to a broad sweep of the most recently modified active flows — and on that path a flow is reported only when its own metadata binds the write to the object you asked about. A write into an untyped or Apex-defined variable is skipped rather than guessed at: matching on the bare field name would otherwise attribute any flow writing some other object’s Status / Type / Rating to yours. A flow whose metadata can’t be read at all is likewise not listed on that path — nothing linked it to your field in the first place, so a row would imply a reference that was never established. The trade is deliberate — a missing row is recoverable, a confident-looking false one is not — and the note says which results that rule omits. Per-scan caps (including the Apex search’s true bound) and any query the org refuses are disclosed the same way. Each row carries an Open link into Flow Builder or the relevant Setup page.

Debug Logs — Analyze view

The Debug Logs viewer gains a per-log 📊 Analyze action (backed by a pure Apex-log parser) that renders a sortable method-timing table (total / self / count), per-namespace governor-limit snapshots, and SOQL / DML / callout inventories with jump-to-line into the raw body, plus a truncation banner. A Flame chart shows the same data as a canvas invocation-tree timeline — zoom into a subtree, hover for detail, click a frame to select it (synced both ways with the method table). You can 📂 Import log — drag-drop or pick a local .log/.txt and analyze it with no org connection — and Execute Anonymous gains 📊 Run & analyze, which runs the Apex, finds the log it produced, and opens it in the Analyzer.

Flow Builder

Setup → Flows

Setup & navigation

Salesforce APIs (Setup, Flow Builder, Trigger Explorer)

Record & Object Manager pages

Workspace tab

These run inside the standalone Workspace tab: