Skip to main content
Workflows automate multi-step research — screening targets, gathering data, drafting work product — so your team doesn’t do it by hand. Open Workflows in the sidebar to reach the workflow hub, where every workflow you can see (run-only, editable, or triggered) lives on a single page.

The workflow hub

The hub is one page for finding, opening, running, and managing workflows. There is no separate “Manage Workflows” destination.
  • Views. Toggle between Table and Board in the top-right of the hub. Table is the default and packs more workflows into view; Board shows each workflow as a card grouped by section. Metal remembers your last choice per browser.
  • Search. The search box in the top-left filters by workflow name.
  • My workflows. Click the My workflows chip to show only workflows you created. Click it again to clear the filter.
  • Filters. Open the filter menu next to My workflows to narrow by status (Published/Draft), creator, connection, trigger, inputs, and lifecycle. Filters are saved per user, so the hub reopens with the same filters applied next time.
  • Board cards. On the Board view, clicking anywhere on a card opens the workflow. The Run button and the Favorite star are independent actions and don’t navigate away.

Run a workflow

1

Find a workflow

On the workflow hub, find the one you want and click Run. (Workflows that run on events or email show View runs instead.) In Table view, clicking a row opens the workflow’s detail page; in Board view, click Run on the card or open the workflow first and run it from there.
2

Provide inputs

In the Run workflow dialog, fill in any required inputs, then click Run. Optional fields can be left blank — a blank optional field is omitted from the run rather than sent as an empty value. If Run is disabled, its tooltip names the specific required fields that still need a value. Fields supplied by a webhook or event trigger, and fields reserved for manual runs, appear in their own section. They are optional for manual runs; on triggered runs, the workflow fills them itself.
3

Watch it run

You’re taken to the run page as it executes.
You can also start workflows from resource pages when the workflow is meant to run against a specific company, deal, or project. Look for Run Workflow on the company, deal, or project page, then choose the workflow and provide its inputs.

Run a comparable-company workflow

Comparable-company workflows, sometimes called comparable-deals workflows, are configured for specific organizations. They do not appear as a separate default section for every customer. If your organization has one configured:
  1. Open Workflows from the sidebar, or open the relevant company, deal, or project page and click Run Workflow.
  2. Select the comparable-company workflow.
  3. Provide the required inputs. These usually include the target company or deal, and may include documents, folders, or scoring context depending on how your workflow is configured.
  4. Open the run page to watch progress and review the output.
If you do not see the workflow, it usually means one of these is true:
  • The workflow has not been configured for your organization yet.
  • You do not have permission to see or run it.
  • The workflow is private, unpublished, or tied to an event/email trigger rather than manual runs.
Ask your Metal admin or Metal contact to confirm the workflow is configured, published, and shared with the right users.

Dry-run a workflow

A dry run steps through a workflow to validate that each tool call has the inputs it expects, without executing any side-effects. Use it to check that a workflow you’re wiring up will call the right tools with the right arguments before letting it hit production systems. In a dry run:
  • Read-only tools (search, lookups) still execute normally, so the agent can gather the context it needs to plan.
  • Write and destructive tools — the ones that would normally prompt for permission — are checked against their input schema but never run. The step reports whether the call was valid instead of performing it.
  • Permission prompts are skipped, since nothing gated actually executes.
Trigger a dry run by setting dryRun: true on the request. See Automate research with workflows for the API call. Dry-run mode carries over. Retrying or re-running a dry run produces another dry run, so nothing gated executes. To run for real, start a new run instead of retrying the dry run.

Review results

On a run page you’ll find:
  • A Steps tab showing each step as it runs.
  • An Output tab with the result once the run completes (it opens automatically).
  • Downloadable artifacts, including an Output report where applicable.
Find past runs under Recent Runs on the workflow hub.

Open a workflow’s detail page

Clicking a workflow in the hub opens its detail page, which has two tabs:
  • Run History (default) — every run of the workflow, filterable by status and approver.
  • Steps — the workflow’s configuration and builder. Editors see this tab; run-only users don’t.
The detail page replaces the old builder URL. Any bookmarks to /workflows/build or /workflows/build/<id> now open the hub or the workflow’s detail page automatically.

Answer DDQs and RFPs

DDQ Solver is a built-in productized workflow with its own overview, run history, and knowledge-bank settings. It is not started from the generic Run workflow dialog. You prepare an answer-source folder, click Answer DDQ, upload a questionnaire or paste questions, review the extracted questions, generate sourced answers, and download the export. See Answer a DDQ or RFP for the full process, including how to prepare and inspect the DDQ Bank when it is enabled for your organization.

Run titles

Each run has a short title so you can identify it in a list without opening it. Metal generates the title when the run is created, using the workflow name plus context from the run — for example a linked company or deal. If generation is unavailable, Metal falls back to a deterministic {workflow name} — {subject} title, preferring a resolved company or deal name and otherwise the first non-empty string input that is not a raw record ID. Titles are capped at 120 characters. Runs without a title — including older runs created before this feature was added — show the run’s date instead in the runs table and the run-detail breadcrumb. Rename a run at any time:
  • On the Workflows runs table, hover the Run column and edit the title inline.
  • On a run’s detail page, click the pencil next to the title in the breadcrumb, edit, and press Enter to save or Escape to cancel.
The My Recent Runs widget uses the run title too.

Run canvas

Workflows that use conditional branch steps are drawn on a canvas that lays each arm out as its own lane. The lane the run took is drawn normally; the arm that was not taken is dimmed, along with the edges into it, so you can see at a glance which path the workflow chose. Steps in the dimmed arm are marked as skipped, and you can still open them to see what they would have run. Click any card — including a skipped one — to open its details in a pane beside the canvas without collapsing the rest of the run.

Version history

If you can edit a workflow your organization owns, open it in the builder and click Version history in the header. The history page lists each saved version with who changed it and a summary of definition changes. You can compare two versions and restore an earlier one. Restoring runs a check first, then saves the restored definition as a new live version, so you can still see what you rolled back from. Deprecated workflows and Metal-provided global workflows cannot be restored this way. Workflow definitions are also versioned over the API. See Workflows in the Developers product.

Human review steps

Some workflows include a Human review step that pauses the run and waits for a person to approve or reject before it continues. When you open a paused run, the step shows a message from the workflow, any pending changes to review, and the reviewers who can act on it.

Who can approve

The workflow builder chooses one of three reviewer modes for each Human review step. The run page shows all eligible reviewers joined with or.
  • Anyone with access. Any Metal user who can open the run may approve or reject.
  • Specific people. Only the users the workflow author picked can approve or reject. Their names appear on the paused step, and each one receives an approval notification. Org admins and owners cannot approve unless they are on the list.
  • Assign automatically. An agent picks a single reviewer when the step pauses. If it cannot assign one, org admins and owners can approve as a fallback.
If a reviewer isn’t available (for example, the account is deactivated), the run stays paused until someone eligible acts on it or a Metal admin restores access. Ask your Metal admin if a run stays paused and no one on your team can approve it.

Find runs waiting on you

The Mine filter on the Workflows page lists runs where you’re an eligible reviewer, including runs where you’re one of several people who can approve. You’ll also get an email and in-app notification when a step you can approve starts waiting.

Pick specific approvers when building a workflow

When editing a Human review step in the workflow builder:
  1. Under Who can approve?, choose Specific people.
  2. In the Approvers picker, search for and select the Metal users who may approve or reject this step. You can pick up to 100 active users from your organization.
  3. Save the workflow.
Every listed user has equal authority. Any one of them can approve or reject, and all of them are notified when the step pauses. Switching to Anyone with access or Assign automatically clears the approver list.

Pause and resume triggers

Email, event, and webhook triggers each have a Trigger enabled switch on the Inputs & Trigger sheet in the builder. Turn it off to stop new automatic runs from that trigger; turn it back on to resume. Schedule triggers work the same way, but per schedule. Each schedule row has its own enabled switch, so you can pause one schedule (for example, the weekly digest) while sibling schedules (like the nightly refresh) keep running. Resuming a paused schedule does not fire a catch-up run for the missed window — its next run is the next scheduled time after you enabled it. A few things to know:
  • Automatic triggers fire whether the workflow is a draft or published. The trigger’s pause switch is the way to stop it — draft status does not. Configure a trigger on a draft only when you actually want it running.
  • Publish status still controls where the workflow appears and who can see it. Draft workflows stay on your Manage list; publishing puts them on the main run list for the rest of your organization.
  • Pause state is stored per trigger type. Switching a workflow from, say, webhook to email starts the new trigger enabled.
  • Manual triggers do not have a pause switch — starting a manual run is always up to the user who opens the Run dialog.

Send a calendar invite from a workflow

Workflows can email a calendar invite using a Send calendar invite step in the workflow builder. Each run of the step sends one iCalendar meeting request to the recipients you specify, using the same email delivery path (and verified custom-domain senders, when configured) as the Send email step. Use it to book a meeting as part of an automation — for example, after an approval step, schedule a follow-up call with the deal team and an external contact. Configure the step in its form (not raw JSON). Every field except Location and From is required, and text fields accept the standard workflow template syntax so you can reference earlier steps and inputs. When the run finishes, the step’s run details show a receipt with the resolved Start and End, timezone, location, sender, recipients, and the event UID that the recipient’s calendar uses to identify the meeting.
Calendar invites are one-way sends. Metal does not currently ingest RSVPs, and updating or cancelling a previously sent invite is not supported. If the meeting details change, send a new invite — recipients may see both messages.

Run workflows from MCP

If your admin has enabled the Metal MCP server, an MCP-compatible assistant can run the same workflows you can access in the app. Ask the assistant to:
  1. Use list_workflows to find the comparable-company workflow.
  2. Use get_workflow to inspect the required input schema.
  3. Use run_workflow with the required inputs.
  4. Use get_workflow_run to poll the run and read the output, artifacts, and citations.
MCP access follows your Metal user permissions. If the assistant cannot find the workflow, confirm that you can see and run it in the Metal app first.
Building automations programmatically? See Automate research with workflows in the Developers product.