Getting started.

When you first log in, you'll land on the dashboard. This gives you a snapshot of your current state: requests by status, active agent runs, recent activity, and aggregate cost.

The status cards across the top (Pending Review, Investigating, Awaiting Approval, Deployed) link directly to filtered views of your request queue. This is where you'll spend most of your time.

Before Speakeasy can do anything useful, you need three things:

1. A connected Salesforce org so the agent has something to investigate
2. A deployment strategy so the agent knows where to implement changes
3. An email route so support requests can reach Speakeasy automatically

All three take a few minutes. Keep reading.

Go to Organizations in the left nav and click Connect Salesforce Org.

OAuth (recommended)

Choose whether you're connecting a production org or a sandbox, then click through. You'll be redirected to Salesforce to log in and authorize access. When you land back in Speakeasy, the org and its credentials are set up automatically.

You can connect multiple orgs this way. Each org gets its own credentials, metadata, and request history.

Username and password

If OAuth isn't an option (restricted environments, testing, etc.), you can connect with a username, password, and security token instead. Click Connect with Credentials and fill in the fields. Credentials are encrypted at rest with AES-256-GCM.

After connecting

Once an org is connected, you can test the connection from the Overview tab, configure its domain and aliases (used for client matching), and set a deployment strategy.

Before the agent can make changes, you need to tell it where to implement them. This is configured per org on the Overview tab under Execution Preferences.

If you don't set a preference, the agent operates in read-only investigation mode. It can look at your org and tell you what it finds, but it won't propose or deploy any changes.

Scratch org

The agent spins up a disposable scratch org for each request, implements the changes there, and promotes them to production via approval. The scratch org is deleted automatically when the session ends.

Setup:

1. Make sure you have at least one production credential connected
2. Enable Dev Hub in your production org (Salesforce Setup > Dev Hub, one-time toggle)
3. In Speakeasy, select your production credential as the Dev Hub credential
4. Click Re-check status to confirm Dev Hub is enabled

This is the safest option. Changes are tested in isolation before anything touches production.

Dedicated sandbox

The agent investigates in production (read-only), then implements changes in a designated sandbox. Approved changes are promoted to production.

You can either create a new sandbox or connect an existing one:

Creating a new sandbox: Click Create a Developer Sandbox, give it a name (max 10 characters), choose a license type (Developer, Developer Pro, Partial, or Full), and select the production org. Provisioning takes 2-15 minutes for Developer sandboxes, longer for others. When it's ready, authenticate with the sandbox credentials.

Connecting an existing sandbox: Add the sandbox credentials via the Credentials section, then select it as your workspace sandbox in the dropdown.

Direct production

Changes are implemented directly in production. This is the simplest to set up (no extra steps), but it means there's no intermediate environment.

By default, the agent still requires approval before deploying. There is an Autonomous Mode toggle that lets the agent deploy without waiting for approval. Only recommended for fresh implementations or pre-go-live work with no active users.

Each org has an Admin Notes field on the Overview tab. This is free-form markdown that gets injected directly into the agent's system prompt for every request against that org.

Use it to tell the agent things it wouldn't know from the metadata alone:

• Naming conventions (“All custom fields on Account use the prefix ACC_”)
• Objects or fields to avoid (“Do not modify anything on the Lead object, it's managed by marketing”)
• Environment quirks (“This org has a managed package from Conga that owns the Opportunity triggers”)
• Process preferences (“Prefer Flows over Process Builders for any new automation”)

The agent is instructed to pay close attention to these notes. The more specific you are, the better the results.

For consultants managing many orgs, this is the main lever for encoding client-specific context that would otherwise live in someone's head.

Go to Settings and find the Email Routing section.

Set an inbound alias. This is the prefix of your Speakeasy email address. If you set it to acme, your inbound address becomes acme@your-speakeasy-domain.com.

Forward your support emails to that address (or set it as a CC on your support workflow). When Speakeasy receives an email, it runs it through client matching to figure out which org the request belongs to. If the match confidence is high enough, the agent starts investigating automatically.

When an email arrives, Speakeasy needs to figure out which connected org it belongs to. It does this in three passes:

1. Domain match: The sender's email domain is compared against each org's configured domains. If julia@meridianventures.com sends an email and you have an org with the domain meridianventures.com, that's a direct match.
2. Alias match: The subject and body text are checked against each org's aliases. Useful when a client sends from a personal email but mentions their company name.
3. Fuzzy match: If neither of the above hits, Speakeasy does a fuzzy search against org account names and aliases.

You configure domains and aliases per org by editing the org on its Overview tab. The domain field accepts comma-separated values (e.g. acme.com, acme.co.uk), and aliases are keywords that might appear in the email content (e.g. Acme Corp, Acme Global).

For consultants

If you're managing 10+ orgs, setting up domains and aliases properly is worth the upfront time. Every org should have at least its primary client domain configured. Add aliases for common name variations, subsidiary brands, or any other text that might show up in support emails from that client.

All emails come through a single inbound address. The matching logic handles the routing. There are no per-org email addresses.

Requests appear on the dashboard as they come in. Each request moves through a lifecycle:

1. Pending Review - the request has arrived and is waiting for you to kick off the agent (or, if the email match was confident enough, the agent is already running)
2. Investigating - the agent is connected to the org, running queries, and tracing the issue
3. Awaiting Approval - the agent has proposed changes and is waiting for your sign-off
4. Deployed - approved changes have been applied to the org

When you process a request manually, you choose a model tier:

• Haiku - fastest and cheapest, good for straightforward issues
• Sonnet - balanced, handles most requests well
• Opus - most capable, for complex investigations that need deeper reasoning

If you don't choose a tier, the system picks one based on request complexity (Sonnet by default). There's currently no way to set a default per org.

You can also attach notes or files to give the agent additional context before it starts.

Filtering and bulk actions

The request list supports filtering by status and sorting by request number, subject, organization, status, or date. Select multiple requests to use bulk actions: Process All, Cancel All, or Change Status.

You can also view requests for a specific org from that org's Requests tab, which is useful when you're managing many orgs and want to focus on one client at a time.

When the agent proposes changes, you get an itemized list. Each item includes:

• A description of what will change (e.g. “Grant FLS read access to Standard User profile”)
• An action type (Create, Modify, or Delete)
• A risk level (Low, Medium, or High)
• A rollback plan describing how to undo the change if needed

You approve or reject each item individually. If something looks off but isn't outright wrong, you can send a clarification instead. The agent will revise that specific item based on your instructions and re-present it for review.

You can also Approve All or Reject All from the top of the request if you want to move fast.

Nothing touches your Salesforce org until you submit your decisions. That's the whole point.

Every time the agent processes a request, it creates a run. You can see all runs for a request in the Agent Runs section of the request detail page.

Each run has several tabs:

• Summary - overview of what happened, which model was used, and the outcome
• Findings - the agent's analysis: root cause, proposed resolution, and approval items
• Validation - results from the secondary AI validation pass that checks the agent's work for gaps or inconsistencies
• Steps - a detailed log of every tool call, SOQL query, and reasoning step the agent took, in order
• Files - any artifacts or metadata snapshots from the session

The Steps tab is the most useful for troubleshooting. It distinguishes between tool calls (grey cards showing the API call or query) and reasoning steps (blue cards showing the agent's thinking). If a run produced unexpected results, this is where you find out why.

Costs

Each run shows its total cost, and you can hover over the cost to see a per-phase breakdown (investigation, resolution, etc.). Aggregate cost is shown on the dashboard and the monitoring page.

There is no per-org cost breakdown at this time. If you're tracking spend per client, you'll need to aggregate from individual request costs.

Open any connected org and go to the Ask tab. Type a question in plain English and Speakeasy will translate it into the appropriate SOQL queries, Tooling API calls, or metadata lookups.

This is read-only. The agent can look at your org but can't modify anything through this interface.

A few things you can ask:

• “How many active users have the System Administrator profile?”
• “What flows run on the Opportunity object?”
• “Show me all custom objects with more than 50 fields.”
• “Are there any validation rules on Account that reference a specific field?”

Conversations are saved and you can pick up where you left off. Responses stream in real-time.

The Explorer tab gives you a full inventory of your org's metadata. To populate it, click Scan Org from the org detail page.

The scan runs in two phases: a deterministic metadata collection pass, followed by AI-powered analysis of code quality and automation patterns. You can watch it progress in real-time.

Once complete, you can browse:

• Objects and fields with counts and types (standard vs. custom)
• Flows, triggers, and validation rules per object
• Apex classes with quality analysis
• Page layouts, components, and security settings

The Health tab scores your org across four dimensions: code quality, automation health, technical debt, and data model. It also flags issues like overlapping automation (e.g. a Process Builder and a Flow both firing on the same trigger).

You can re-scan at any time. Scan history is preserved so you can track how your org changes over time.

Inviting users

Go to Settings and scroll to the Users section (admin only). Enter an email address and choose a role:

• Admin - full access, can manage users and settings
• Member - can process requests, approve changes, use chat and explorer
• Viewer - read-only access to requests and org data

The invited user receives an email with a link to set up their account.

Email routing

Also in Settings. See the Email Routing section above.

You can submit requests programmatically using the ingest endpoint. This is useful for integrating Speakeasy with ticketing systems, Slack bots, or internal tools.

POST /api/ingest/api
Content-Type: application/json
Authorization: Bearer <your-jwt-token>

{
  "subject": "Field not showing on page layout",
  "body": "The new Custom_Field__c on Account is not visible...",
  "sender": "julia@meridianventures.com",
  "organizationId": "<org-id>",
  "severity": "medium"
}

The organizationId and sender fields are optional. If omitted, Speakeasy will attempt to match the request to an org the same way it does with inbound emails.

For real-time updates on request status, agent progress, scan results, and chat responses, connect via Socket.IO.

Full API reference and webhook documentation is available on request. Get in touch and we'll get you set up.