Automations

Pro, Business, the Pro trial, and the lifetime and AppSumo Practice and Firm plans.

An automation rule runs one action when one event happens in your workspace. Each rule pairs a trigger with an action, and it applies to every onboarding.

Plans and access

Automations need a plan with API access. That means Pro, Business, the Pro trial, the Practice and Firm lifetime plans, or the AppSumo Practice and Firm plans. Free, Starter, and the Solo plans do not include them.

Only owners and admins can see the Integrations tab. On a plan without automations, the section shows "Trigger automatic actions when events occur, like sending emails or webhooks. Available on Pro and Business." with an Upgrade plan button, and no Add rule button. Rules you made on an earlier plan stay listed, so you can still pause or delete them.

Portico checks the plan again before it runs a queued event. If your plan no longer includes automations, Portico skips that event's actions and does not retry them. A skipped action does not change the rule's last-run line.

Create a rule

1. Go to Settings > Integrations and scroll to the Automations section.
2. Click Add rule. The New automation rule dialog opens.
3. Enter a Rule name of up to 200 characters.
4. Choose a trigger under When this happens....
5. Choose an action under ...do this, then fill in the fields for that action.
6. Click Create rule.

A new rule starts turned on. Each rule in the list shows its name and a summary line, such as "When Onboarding completed → Notify team member".

Triggers

Actions

Every trigger concerns one onboarding. When an action runs, Portico reads that onboarding and its client, so all four actions work with all four triggers.

Portico reads these details when the action runs, not when the event happens. If the client's email address changes in between, Send email uses the new address.

Send email always writes to the onboarding's client. This holds even when a team member's countersignature triggers Signature signed.

Portico retries a failed action and then stops, as described in Failures and retries.

Placeholders

The Available placeholders card lists {{client_name}}, {{client_email}}, {{team_name}}, and {{template_name}}. You can use them in Subject, Body, and Message.

Each placeholder fills in from the event's onboarding and its client, on every trigger:

• {{client_name}} and {{client_email}} are the client's current name and email address.
• {{template_name}} is the name of the template behind the event's onboarding.
• {{team_name}} depends on who reads the message. In Send email, it is your firm name as clients see it. In Notify team member, it is your Team name.

The card does not list four more placeholders that also work. They are {{company}}, {{due_date}}, {{progress_pct}}, and {{event_type}}. {{due_date}} is blank when the onboarding has no due date. {{event_type}} is the event name, such as onboarding.completed.

Send webhook

Portico sends a POST request with a JSON body to your Webhook URL. The URL must be a public HTTPS address of up to 500 characters.

The request carries three headers:

• Content-Type: application/json
• X-Portico-Event-Id
• Idempotency-Key

Both ID headers hold the same value as the body's id field. Every retry of the same action sends the same id and body, so use it to ignore duplicates.

The request has no X-Portico-Signature header, so you cannot verify it with a signing secret. For signed requests, use the Webhook section on the same tab. See Webhooks.

The body looks like this for Onboarding completed:

{
  "id": "0b7e5c1a-4f2d-4e8b-9a61-3c5d7f9e2b10",
  "event": "onboarding.completed",
  "timestamp": "2026-10-14T09:30:00.123456+00:00",
  "data": {
    "onboarding_id": "5d2f8a90-1c3e-4b7a-8f64-2e9d0c1b3a57",
    "client_id": "8a41c7e2-6b0d-4f3a-9c15-7e2d4b6a9f08",
    "client_name": "Jane Smith",
    "client_email": "jane@example.com",
    "template_id": "c3e9a1b7-2d4f-4a6c-8e10-5b7d9f1a3c62",
    "template_name": "New client onboarding",
    "status": "completed",
    "progress_pct": 100,
    "created_at": "2026-10-10T14:05:12.654321+00:00"
  }
}

event is the trigger's event name, and timestamp is when Portico recorded the event.

On every trigger, data carries the base fields shown above. They describe the onboarding and its client at the moment of the event. created_at is when the onboarding was created.

Each trigger adds its own fields to data:

For a subscription, payment_intent_id holds the Stripe subscription ID.

The webhook body keeps the details from the moment of the event. A later change to the client's email address does not appear in it.

To look up more about an onboarding, call GET /api/v1/onboardings/:id with the onboarding_id. See API reference.

Notify team member

This action emails one member of your workspace. The email comes from Portico, not from your firm:

• From: Portico, at notifications@portico.run.
• Subject: your team name in square brackets, followed by "Workflow notification".
• Body: the heading "Workflow notification", your message, and the line "From automation rule in" followed by your team name.

Here, {{team_name}} is the Team name from Settings > Account. Your Email sender name does not appear in this email.

Message is required, up to 10,000 characters. Choose the person under Team member. The list shows each member by email address.

If that person leaves your team, the rule shows "Former team member" when you edit it. Choose a current member before you save.

Send email

Send email takes a Subject of up to 500 characters and a Body of up to 10,000 characters. Both are required.

The email goes to the client of the event's onboarding, at the address on file when the action runs. It comes from your firm:

• From: your firm name as clients see it.
• Body: your logo when you have uploaded one, then your text, then your firm name.

Your firm name is your Email sender name from Branding. Without a sender name, it is your Team name. If your team name is still the signup placeholder, such as "Jane Smith's team", the email shows the owner's name instead.

Body is plain text. Line breaks carry over, and HTML tags appear exactly as typed.

If the client has no valid email address, the action stops and does not retry. The rule's last-run line then says "The client has no valid email address. Update the client's email address."

Create new onboarding

Choose a template under Template. The list shows your workspace's templates.

When the rule runs, Portico creates an onboarding from that template for the same client. Then Portico sends it, as a manual send does:

• The client gets the usual invite email with a link to the form.
• Reminders follow your Default reminder schedule from Settings > Client experience.
• The send counts toward your plan's monthly onboardings.
• The onboarding's history records the creation and the send.
• Portico sends the onboarding.sent event to your webhook and to Zapier.

The new onboarding has no due date and no assignee. Reminders that count from a due date therefore do not apply to it.

If the send cannot go ahead, Portico creates nothing and does not retry. Nothing counts toward your monthly limit. The rule's last-run line shows "Failed:" and the reason:

If the template is deleted, editing the rule shows "Deleted template". Choose another template before you save.

Failures and retries

Portico queues each action when its event happens and works through the queue every 5 minutes. An action can run a few minutes after its event.

• Each rule runs on its own. One failing action does not stop other rules for the same event.
• Send webhook counts any 2xx response as success. Portico follows redirects and waits up to 10 seconds for a response.
• A 4xx response other than 408 or 429 stops retries for that action.
• Other failures are retried, and the wait roughly doubles after each failure. Portico honors a Retry-After header of up to 1 hour.
• Some failures stop at once, because a retry would fail the same way. Examples are a client without a valid email address, a deleted template, a signature with the sample agreement text, or a used-up monthly limit.
• Portico tries each action at most 10 times, then stops.

See whether a rule ran

Under each rule's summary line, a second line shows its latest run:

• "Has not run yet": Portico has not run this rule's action yet.
• "Last ran", followed by a date and time: the latest action succeeded.
• "Failed, trying again:", followed by a reason: the latest action failed, and Portico will retry it.
• "Failed:", followed by a reason: the latest action failed, and Portico has stopped trying.

Each reason says what to do, such as "The template no longer exists. Edit the automation and choose a template."

The line shows only the latest run. The app keeps no run history, so check the receiving system to see what a Send webhook action sent.

Edit, turn off, or delete a rule

Each rule has a switch to the left of its name:

• Turn a rule off: click its switch. The rule keeps its settings and stops running for new events.
• Turn it back on: click the switch again.

To change a rule:

1. Click Edit on the rule. The Edit rule dialog opens.
2. Change the name, trigger, action, or action fields.
3. Click Save changes. The rule stays on or off as it was.

To delete a rule:

1. Click the trash icon on the rule.
2. In the Delete rule? dialog, click Delete rule. Deleting cannot be undone.

These changes apply to later events only. Portico copies each matching rule's action when an event happens, and queued actions run with that copy.

If your plan no longer includes automations, you can still turn rules off and delete them. You cannot add rules, edit them, or turn them on.

If Portico cannot confirm a change

When you create, edit, turn on or off, or delete a rule, the button you clicked stays busy until Portico answers. If Portico refuses the change, a message says why, nothing changes, and your edits stay in the dialog.

If Portico cannot tell whether the change went through, the section shows "We could not confirm whether your last change went through. Check its result before you make another change." You cannot change other rules until you choose one of these:

• Check result: Portico looks up the change. If it went through, the list shows it.
• Try again: sends the same change again. It appears only in the browser tab where you made the change.
• Stop this change: makes sure the change can never apply later. If it already went through, it stays.

The same controls appear for team members, invites, custom client fields, and custom domains.

Automations, webhooks, and Zapier

Use the Webhook section when your server needs to verify each request. Use Zapier to connect onboarding events to other apps without code.