Run and review Metal AI workflows

Workflows automate multi-step research — screening targets, gathering data, drafting work product — so your team doesn’t do it by hand. Click Automations in the sidebar to open the workflow Overview at /workflows, where every workflow you can see (run-only, editable, or triggered) lives on a single page. Old links to /automations redirect to /workflows.

The Automations area

The Automations subnav lists Create, Overview, and Runs, followed by your Pinned workflows, the workflows you own (Yours), and your Recent runs. Pinned and owned workflows that you can run by hand show a run shortcut next to their name.

Create starts a new workflow.
Overview opens the workflow hub at /workflows.
Runs opens the full run history across workflows at /workflows/runs.

The workflow hub

The Overview is one page for finding, opening, running, and managing workflows. It leads with My runs, followed by the workflow library table. There is no separate “Manage Workflows” destination.

My runs

My runs shows up to four cards, one per workflow you ran in the last 7 days. Workflows with a failed run or a run awaiting approval appear first. Each card shows:

The latest run’s status and when it ran.
The number of runs in the last 7 days.
Outcome counts for succeeded, failed, awaiting approval, and stopped runs. Metal shows only the counts above zero.
An in-progress indicator when a run is still going.
The cadence and next run time, when the workflow has an enabled schedule.

Click a card to open the latest run. Click the failed or awaiting-approval count to open the workflow’s Runs tab filtered to that status. Click View all to open the full run history on the Runs page. Dry runs don’t appear in My runs.

Library

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 creator, connection, trigger, inputs, and lifecycle, or to show deprecated workflows. Filters are saved in this browser, so the hub reopens with the same filters applied next time.
Type. In Table view, the Type column shows Custom for workflows built in your organization, and System or Global for workflows Metal provides.
Run. In Table view, a custom workflow that can be run by hand has an inline Run button. Rows for Metal-provided System and Global workflows don’t show an inline run control.
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

Find a workflow

On the workflow hub, find the one you want and click Run. (Workflows that run on events or webhooks 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.

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.

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, project, or list. Look for Run Workflow on the company, deal, or project page, or the workflow control on a list, then choose the workflow and provide its inputs.

Organization-specific workflows

Some workflows are configured for a specific organization instead of shipping as a built-in product. Deal intake, investor-request intake, and comparable-company research are common examples. Firms use different mailboxes, field maps, ownership rules, and systems of record, so Metal configures these workflows for your organization. If your organization has one:

Open Automations, search for the workflow, and select it. For event- or webhook-triggered workflows, open View runs rather than starting a manual run.
Provide the required inputs. If the workflow runs on email, send the source message to the inbound address your Metal contact gave you.
Open the run and review the output before you rely on it.

If you do not see the workflow, it has not been configured for your organization or shared with you. Ask your Metal admin or Metal contact to confirm the trigger, review step, and write behavior before you use it.

Portfolio workflows

See Work with portfolio companies for portfolio workflows, the Portfolio Monitoring request tile, and how they differ.

Run a comparable-company workflow

Comparable-company workflows, sometimes called comparable-deals workflows, are configured for specific organizations. See Organization-specific workflows if you do not see one.

Open Automations from the sidebar, or open the relevant company, deal, or project page and click Run Workflow.
Select the comparable-company workflow.
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.
Open the run page to watch progress and review the output.

Run a conference-prep workflow

Conference-prep workflows help a team walk into a conference, roadshow, or scheduled meeting with current company, relationship, and deal context. They are configured for specific organizations. They are not a built-in product with a dedicated page. If your organization has one configured:

Build or open the attendee universe as a company or people list. You can search and select records, paste a list, or upload a file.
Start the run from Automations, or open the list and use its workflow control if the workflow accepts a list as input.
Provide any remaining required inputs. Optional fields can be left blank.
Open the run page to watch progress and review the output.

Review the Output tab and any artifacts before you share them. See Organization-specific workflows if you do not see a conference-prep workflow. Do not assume every organization gets the same inputs, columns, or output format. Conference prep is different from meeting-briefing workflows such as an LP meeting briefing, which draft a brief for an upcoming calendar meeting. A conference-prep workflow works from an attendee or target list. Who can see, run, and edit a workflow depends on its sharing settings. Open the share dialog from the workflow to change them.

General access. New workflows start as Restricted, so only the users and teams you share with can open them. Organization admins can open any workflow in your organization. Switch to Anyone in your org with link to let everyone in your organization open the workflow.
Per-share roles. Each user or team you share with gets a role. New shares default to Viewer; shares created before per-share roles existed keep Editor access. Change the role from the dropdown next to each person or team.
- Viewer can open and run the workflow, see its run history, and view its steps read-only, but can’t change them.
- Editor can also edit the workflow’s steps and open its Settings tab.
Run visibility. Choose All Runs Visible to let everyone with access see every run, or Own Runs Only so users see only runs they triggered.

Access is the union of your shares, and Editor wins over Viewer. If any direct or team share gives you editor access, you can edit the workflow even when another share makes you a viewer. A viewer share on its own never grants editing, even when general access is set to the whole organization.

Run an LP meeting briefing

An LP meeting briefing workflow prepares relationship history, recent correspondence, commitments, and open questions before an LP meeting. It is configured for your organization, not a built-in workflow, so its name varies. For example, your organization may call it LP Pre-Meeting Notes. To run it:

Open Automations and search for the name your organization uses.
Click Run and provide any required inputs. Run stays available when the workflow also runs on a schedule, so you can start a manual run.
Open the Runs tab to review briefs that already ran.
Review the Output tab and any artifacts before you share them. Check sourced facts separately from open questions.

If you do not see the workflow, it has not been configured or shared with you. See Organization-specific workflows. An LP meeting briefing is different from Board meeting prep (portfolio company board meetings) and DDQ Solver (answering questionnaires). You can also prepare manually from the LP and fundraising process records. See Prepare for an LP meeting.

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.

Start a dry run from the app or the API:

In the app. In the Run workflow dialog, expand Advanced options and turn on Dry run, then click Run.
Over the API. Set dryRun: true on the request. See Automate research with workflows for the API call.

Metal marks dry runs so you don’t confuse them with live runs:

A Dry run badge appears next to the run in run history lists.
The run page shows a banner: Dry run — write calls were validated, not executed.
Each write step that was validated but not executed shows a Dry run validated marker next to the tool name.
In the Runs tab (heading Run history), a run mode filter offers Live runs, Dry runs, and All runs. It defaults to Live runs, so switch it to find your dry runs.
Dry runs don’t appear in My runs on the workflow Overview.

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.

Intake a teaser or CIM

Deal intake is usually an organization-specific workflow, not a built-in product like DDQ Solver. See Organization-specific workflows if you do not see an intake workflow or have not received an inbound address. A configured intake workflow can turn an inbound teaser, CIM, file, or email into a reviewed deal — and write to your CRM, such as DealCloud or Salesforce, when that step is part of the workflow. To run intake:

Forward the teaser or CIM to the inbound address your Metal contact gave you, upload the file, or open Automations and run the intake workflow.
Open the run and review the extracted company, deal, source, and proposed create or update. Do not treat an unverified match as the live record.
Approve only after you confirm it is the right company and deal. A well-configured workflow creates a deal when none exists and updates a matching live deal instead of creating a duplicate.
Confirm that passed or dead records are left alone, and that the source file stays attached to the deal.
After approval, check the deal in Metal and — if CRM write is configured — the matching record in your CRM, such as DealCloud or Salesforce.

Intake emails and questions

Deal intake no longer uses a Deal Intake agent. No agent reads, answers, or replies to an intake run, and no agent thread is opened for it. Each email that reaches your intake workflow starts a run. Send the deal even if the email has little detail. Intake decides whether there is a deal. Replies on the email thread don’t answer questions, report status, or stop a run. The Metal team answers a run’s questions on its review page. You hear from a run only through its fixed emails to the sender, when your organization has them turned on and the run has an email thread to reply on.

Run outcomes

When a run ends, Metal records its outcome and the reasons for it. The outcome says what intake did with the email.

Outcome	Meaning	Reasons
Processed	Intake did all of the work.	None
Partly processed	Intake did some of the work but not all of it.	The material doesn’t have enough readable information to score. The CRM records for the deal need a correction, so intake didn’t update your CRM. The Opportunity chosen for the run couldn’t be used. A person chose not to write to the CRM. A problem on Metal’s side blocked the CRM write. Some planned writes didn’t save.
Not processed	Intake found nothing to act on.	The email has no deal material. The email says a file is attached but none arrived. No attachment could be read. The attachments aren’t deal material. Every attachment was already taken in by an earlier run. The deal is already Abandoned in the CRM.
Failed	The run stopped, the Metal team rejected its plan, or your CRM isn’t set up for deal intake.	The run stopped in a named phase. The plan was rejected. Your CRM isn’t set up for intake.

Each reason has fixed text. If you resend an email whose earlier run was Partly processed, Not processed, or Failed, intake runs again. For example, resend after you correct the CRM records. A resend of a run that was Processed, or that is still in progress, isn’t processed again.

Emails to the sender

Metal composes up to two fixed emails for each run’s original sender. They come from Metal Deal Intake, and each is sent at most once. Only a run started by an email sent to your intake address has a thread to reply on. A run started by a Workflow email trigger, by hand, or through the API has none, so its emails are composed and stored but never sent.

Receipt. Sent after intake finds a deal document in an email that isn’t a repeat. It says Metal received your email, intake is running, and you’ll get another email when it’s done.
End email. Sent when a run completes, or when intake stops with an error. For a Processed run, it summarizes what intake wrote. For a Partly processed run, it adds a What we could not do list with each reason’s text. For a Not processed or Failed run, it contains only the reason text. A run whose plan the Metal team rejected, or that someone asked to stop, gets no end email.

Sending is turned on per organization and is off by default. Metal turns it on for your organization. When sending is off, Metal still composes and stores each email but doesn’t send it. Metal also doesn’t send for a dry run or a run with no recipient. Turning sending on later doesn’t send emails that were already composed.

Questions a run asks

Some runs pause on one or more questions, each with a list of options. The questions a run asks at one pause form a single set, and the run resumes only after every question in the set has an answer. For example, when several open opportunities in your CRM match the deal, the run asks which one it is:

Salesforce has 2 open Opportunities that match Acme Corp / Project Atlas. Which one is this deal?

1. Acme Corp - Project Atlas (006XXXXXXXXXXXX)
   Company: Acme Corp · Project: Project Atlas · Stage: Sourcing · Created: 2026-03-02
2. Acme Corp - Atlas add-on (006YYYYYYYYYYYY)
   Company: Acme Corp · Project: Atlas add-on
3. Stop: write nothing
   Nothing is written to Salesforce or Drive.

When your CRM matches the company or the project name but not both, the run asks whether the deal is one of those records. The Metal team answers each set of questions on the review page. The sender is never asked.

If the answer picks a record, intake updates that record the same way it would for a single match. Its usual checks still run.
If the answer is Stop: write nothing, nothing is written to your CRM. The run ends Partly processed, with the reason that a person chose none of the matching records.

Review and change an answer

The Metal team reviews intake runs on the run’s review page. The page shows when the email was received. When a run has ended, a banner at the top shows its outcome and each reason. The banner also shows the status of the end email: Emailed to sender with the time sent, Sending, Not emailed (test run), Not emailed (sending is off), Not emailed (no email thread), Not emailed (no recipient), Not emailed (send failed), or a plain Not emailed for any other reason. The page lists each email in an Emails to the sender section, in the order Metal composed them, and you can open each email’s text. When a section, such as extracted facts, scores, Salesforce, or Google Drive, is empty because of a reason, it shows that reason instead of Not recorded. A Questions section shows one card for each set of questions the run asked, in the order asked. Each card shows every question with its options, the chosen answer, who chose it, such as Metal team answered, and the Message recorded with the set of questions, when there is one. When an answer was changed, the card also shows the original answer. Runs from before the agent was retired can still show Agent chose on answers the agent recorded. The Metal team can:

Answer the open questions. Pick one option for each question in the card, add an optional Message, and click Answer and continue. The message is required when any answer is Stop: write nothing. The form is available as soon as the run pauses, on a dry run or a live run.
Change answers on a run that is waiting for approval and has no decision yet. Click Change answers on the newest answered card. The form opens with the current answers filled in. Change at least one answer and write a Message, which is required. Metal then re-plans the run from those answers, and the run returns for approval with a new plan. Nothing is written to your CRM before approval.

Earlier answers stay on the run for the record.

Editing a deal you already have in Metal is a different path. When writeback is enabled, those edits can sync to your CRM, such as DealCloud or Salesforce. See Write edits back to your CRM.

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).
A Debrief tab that summarizes what the run did (see Run debrief).
Downloadable artifacts, including an Output report where applicable.

The run header shows the run’s status next to its outcome. Find your recent runs under My runs on the workflow Overview, or open Runs in the Automations subnav for the full run history.

Run outcomes

A workflow can define a set of outcomes that describe the business result of a run. Each outcome has a label and belongs to one of four categories:

Succeeded
Partial
Declined
Nothing written

A run that completes shows its outcome category and label. Steps in the workflow declare the outcome. If no step declares one, Metal infers an outcome from the run’s results and marks it as inferred. If Metal can’t pick an outcome, the run shows No outcome. Runs from before outcomes were added, and runs of workflows without outcomes, show — in the Outcome column.

Define outcomes in the builder

Editors define a workflow’s outcomes on the Outcome contract card in the builder, on the workflow’s Steps tab.

Open the contract

On the Outcome contract card, click Define outcomes, or Edit outcomes if the workflow already has a contract.

Add outcome codes

Click Add outcome code for each result the workflow can reach. Each outcome needs:

Code: a unique identifier that terminal steps return, such as contact_unconfirmed.
Category: one of Succeeded, Partial, Declined, or Nothing written.
Label: the headline shown on the run, such as “Refused: source contact unconfirmed”.
Description (optional): when the code applies.

Save

Click Save contract.

A contract needs at least one code and can hold up to 254. Codes must be unique, and insufficient_evidence is reserved. To stop declaring outcomes, click Remove contract and confirm. Runs of a workflow without a contract show no declared outcome.

Filter runs by outcome

The global Runs page and a workflow’s Runs tab both have an Outcome column and an outcome filter. The filter applies only to the runs loaded on the current page. If no loaded run matches, load more runs to check older history. On a workflow’s Runs tab, a run’s row details also show the outcome code and its source, declared or inferred.

Run debrief

Open the Debrief tab on a run page for a summary of the run:

The outcome, and whether it was inferred.
Summary counts: steps executed, steps skipped, writes, documents produced, and duration.
The actions the run took.
Skipped steps.
The blocker or failing step, if any.
For inferred outcomes, the model’s confidence in its choice.

Runs without a debrief show No debrief for this run. While a run is still in progress, the tab says the debrief will be available when the run finishes.

Completion notifications

Completion notifications use the run’s outcome in the title and the debrief in the body, with a link to the run and its debrief. Runs that end as Declined or Nothing written still send a notification, even when they produce no output. Slack run updates add an Outcome: <category> — <label> line when a step declared the outcome. Inferred outcomes don’t appear in Slack updates.

Open a workflow’s detail page

Clicking a workflow in the hub opens its detail page, which has up to five tabs:

Overview (default) — a summary of the workflow: its trigger, sharing, recent runs, and steps.
Runs — the workflow’s run history, with the run mode, status, outcome, and approver filters.
Steps — the workflow’s configuration and builder. Editors can change steps here. Users who can view the workflow but not edit it see a read-only version. See View steps read-only.
Version history — each saved version of the workflow definition, with who changed it. You can compare versions, and editors can restore an earlier one.
Settings — the workflow’s name, section, description, and evaluation. Users with the Editor role see this tab; viewers don’t. Deprecate and delete controls appear only for the workflow’s creator and org admins.

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.

View steps read-only

If you can view a workflow but not edit it, the Steps tab opens in read-only mode. Use it to see how a workflow works before you run it, or to reuse a prompt in your own workflow.

Every step, branch, input, and output pane opens with its form disabled. You can’t add, save, or delete steps.
Prompts and code show as text you can select and copy.
Agent steps list their connections by name.
Webhook secrets stay hidden.

Metal-provided Global workflows don’t show the Steps tab. The Settings tab stays editor-only. On a run page, the Options menu shows View workflow instead of Edit workflow when you can’t edit the workflow.

Answer DDQs and RFPs

DDQ Solver is a built-in productized workflow with its own overview, run history, and answer-bank settings. It is not started from the generic Run workflow dialog. You prepare bank sources, 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.

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

Open a workflow’s Version history tab to see each saved version with who changed it and a summary of definition changes. You can compare two versions; if you can edit the workflow, you can also 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 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 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:

Under Who can approve?, choose Specific people.
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.
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 whenever the trigger is enabled. The trigger’s pause switch is the way to stop them. Sharing settings don’t affect whether a trigger fires. Configure a trigger only when you actually want it running.
General access controls who can find the workflow on the Workflows page. Workflows set to anyone in your organization appear for everyone; Restricted workflows appear only for their creator and the people or teams they’re shared with. See Share a workflow.
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.

Attach files to a Send email step

A Send email step can attach files produced earlier in the run, such as a generated report. Use it to deliver a workflow’s output directly to recipients’ inboxes. A Send email step delivers only to users in your organization and to addresses on your allowed recipient domains. Metal skips other addresses. Admins manage the allowed domains under Settings → Email Domains. In the step form, under Attachments, choose one of two modes:

Individual files. Click Add file for each attachment. Enter an exact filename, artifact ID, or saved output ID from an earlier step. Each field accepts workflow template syntax.
Dynamic list. Click Dynamic list and enter a template that resolves to an array of file references. The files and their count can change on every run. For example:
{{ (index .Steps "generate-report").results.outputIds }}

Click Individual files or Dynamic list to switch between modes. Switching clears the current attachments. Attachment limits:

Up to 10 files per email.
Up to 10 MiB per file.
Up to 20 MiB total across all attachments.
When the step sends from a custom-domain From address, the full encoded email, including the body and attachments, must also fit within 10 MiB.

After the run, the step’s run details list the attachments that were sent.

Write an HTML body for a Send email step

By default, a Send email step’s body is Markdown, and Metal renders it to formatted HTML. Switch to HTML when you need control over the email’s layout, such as a styled table or a branded summary. In the step form, under Format, choose Markdown or HTML. Markdown stays selected unless you change it. When you choose HTML, the Body field (placeholder Email body (HTML)) accepts an HTML fragment. You don’t need <html>, <head>, or <body> tags. You can use workflow template syntax in element text and in quoted href values:

<h2>Weekly pipeline summary</h2>
<p style="color: #333333;">{{ .Steps.summarize.text }}</p>
<a href="{{ .Input.taskURL }}">{{ .Input.taskTitle }}</a>

Metal escapes each inserted value, so values from earlier steps can’t add markup to the email.

Allowed content

HTML bodies accept a fixed allowlist:

Elements. a, b, blockquote, br, caption, code, div, em, h1–h6, hr, i, li, ol, p, pre, small, span, strong, sub, sup, table, tbody, td, th, thead, tr, u, ul.
Inline styles. The style attribute accepts only these properties: color, background-color, font-*, text-*, line-height, letter-spacing, white-space, word-break, overflow-wrap, margin, padding, border*, border-radius, width, height, max-width, min-width, display, vertical-align, table-layout, and border-collapse. border* covers the border shorthands and sides. Longhands such as margin-top or padding-left, the font shorthand, and properties outside this list aren’t allowed.
Links. Links must use absolute https:// URLs that point to the Metal app. Links to other hosts or subdomains aren’t allowed. Sign-in and connection pages of the app can’t be linked — for example /oauth, /callback, and /settings/connections are rejected. The same rule applies to URLs written as plain text in the body.
Template syntax. You can only use template syntax in element text and quoted href values, as in href="{{ .Input.taskURL }}". An unquoted href={{ ... }} is rejected, and template syntax in other attributes, such as title or alt, isn’t allowed.

Images, media, <style> blocks, stylesheets, scripts, and other external resources aren’t allowed.

How Metal checks HTML bodies

While you edit. The form shows inline warnings for content that isn’t allowed. The warnings are advisory. They don’t block Save Step.
When you save. Metal checks the HTML when you save the step. If the body contains content that isn’t allowed, Metal rejects the save and shows an error for the affected field.
When the step runs. Metal sanitizes the rendered HTML before it sends the email. If the body is empty after sanitization or larger than 32 KiB, the step fails.

In the step’s run details, an HTML body appears as plain text, not as rendered HTML.

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.

Field	What it sets
Title	Event title, also used as the email subject.
Description	Event description, written in Markdown and rendered as formatted HTML in the email body.
Start / End	Event start and end. Accepts either an RFC 3339 timestamp with an offset, or a local date-time like `2026-09-14T13:30`. Local values are interpreted in the timezone below.
Timezone	IANA timezone (for example, `America/New_York`) used to interpret local Start/End values. Defaults to your browser’s timezone.
Location	Optional physical address or meeting URL.
Recipients	Metal users, the user who triggered the run, or external email addresses. Recipient rules match Send email: recipients must be org users or addresses on your allowed recipient domains, with or without a custom From. Metal skips other addresses.
From	Optional verified custom-domain sending address. When set, the invite is sent from your domain. The same recipient rules apply.

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 many of your firm’s configured canvas workflows, including workflows that also run on a trigger. Built-in productized workflows such as DDQ Solver are not available through Metal MCP. Use the dedicated in-app experience instead. Ask the assistant to discover the workflow, inspect its required inputs, start a run, and poll until the output and artifacts are ready. See Run a workflow for how MCP workflow discovery relates to the API and which built-in workflows are in-app only. 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.

​The Automations area

​The workflow hub

​My runs

​Library

​Run a workflow

​Organization-specific workflows

​Portfolio workflows

​Run a comparable-company workflow

​Run a conference-prep workflow

​Share a workflow

​Run an LP meeting briefing

​Dry-run a workflow

​Intake a teaser or CIM

​Intake emails and questions

​Run outcomes

​Emails to the sender

​Questions a run asks

​Review and change an answer

​Review results

​Run outcomes

​Define outcomes in the builder

​Filter runs by outcome

​Run debrief

​Completion notifications

​Open a workflow’s detail page

​View steps read-only

​Answer DDQs and RFPs

​Run titles

​Run canvas

​Version history

​Human review steps

​Who can approve

​Find runs waiting on you

​Pick specific approvers when building a workflow

​Pause and resume triggers

​Attach files to a Send email step

​Write an HTML body for a Send email step

​Allowed content

​How Metal checks HTML bodies

​Send a calendar invite from a workflow

​Run workflows from MCP

The Automations area

The workflow hub

My runs

Library

Run a workflow

Organization-specific workflows

Portfolio workflows

Run a comparable-company workflow

Run a conference-prep workflow

Share a workflow

Run an LP meeting briefing

Dry-run a workflow

Intake a teaser or CIM

Intake emails and questions

Run outcomes

Emails to the sender

Questions a run asks

Review and change an answer

Review results

Run outcomes

Define outcomes in the builder

Filter runs by outcome

Run debrief

Completion notifications

Open a workflow’s detail page

View steps read-only

Answer DDQs and RFPs

Run titles

Run canvas

Version history

Human review steps

Who can approve

Find runs waiting on you

Pick specific approvers when building a workflow

Pause and resume triggers

Attach files to a Send email step

Write an HTML body for a Send email step

Allowed content

How Metal checks HTML bodies

Send a calendar invite from a workflow

Run workflows from MCP