Understanding Playbook & Project Automations

Last updated: February 18, 2026

If Workflows decide when a project gets created,
Playbook & Project Automations decide what happens after it exists.

These automations run inside OnRamp — triggered by project activity — and can call out to other systems like your CRM or webhooks.

They are the execution layer of automation.

Two Places You’ll See Them

Playbook & Project Automations live in two related places:

1⃣ Playbooks (Library → Playbook → Automations tab)

This is where automation logic is defined.

When configured on a Playbook:

  • The automation becomes reusable

  • Every project created from that Playbook inherits it

This is the recommended place to manage automation logic.

2⃣ Projects (Project → Automations tab)

This is where automations execute.

Inside a project, you’ll see:

  • Active automations

  • Execution history

  • Logs

  • Errors (if any occurred)

Playbooks define the rules.
Projects execute them.

Important: If the Playbook Is Used in a Workflow

Here’s the operational nuance most teams miss:

If you add a new automation to a Playbook and that Playbook is used in an active Workflow, you must update the Workflow.

Why?

Because Workflow versions control how CRM record IDs are mapped into the project — and automations that update your CRM require a valid record ID.

What You Need to Do

  1. Go to Workflows

  2. Open the Workflow that uses the Playbook

  3. Create a new version

  4. Navigate to the Project Automations card

  5. Map the appropriate CRM record ID for the automation

  6. Publish the new version

Without this step, the automation may run — but fail due to missing record context.

Why This Matters

CRM update actions (like “Update Salesforce field” or “Update HubSpot field”) require:

  • A valid CRM object reference

  • A populated record ID

If that ID isn’t mapped in the Workflow version, the automation won’t know which record to update.

This is one of the most common causes of write-back failures.

What Triggers Playbook / Project Automations?

Automations can trigger from activity inside the project, including:

📌 Project-Level Triggers

  • When project created

  • When project updated

  • When project completed

📦 Module-Level Triggers

  • When module completed

✅ Task-Level Triggers

  • When task completed

And optionally:

  • Only when a specific subtask answer matches a defined value

This allows conditional logic based on customer inputs.

🧠 Data Field Triggers

  • When a specific Playbook data field changes

  • When any Playbook data field changes

These are ideal for syncing structured onboarding data back to your CRM.

What Actions Can They Take?

Once triggered, automations can:

🔄 Update CRM Fields

  • Update Salesforce field

  • Update HubSpot field

Common examples:

  • Onboarding Status

  • Implementation Complete

  • Go-Live Date

📎 Upload Files to Salesforce

Automatically attach files generated in OnRamp to CRM records.

➕ Add a Module

Dynamically expand project scope when certain conditions are met.

Example:
If SSO Type = Okta → Add “SSO Setup” module.

🌐 Call a Webhook

Trigger external systems, internal tools, or data pipelines.

How They Actually Execute

When a trigger condition is met:

  1. OnRamp evaluates the automation logic

  2. If conditions match, it prepares the action

  3. It sends the payload to the target system (CRM, webhook, etc.)

  4. It logs the result inside the Project → Automations → Logs tab

If something fails, it’s recorded with:

  • The action attempted

  • The payload sent

  • The error returned

Nothing runs invisibly.

When Should You Use Playbook Automations?

Use them when you want to:

  • Sync onboarding progress back to your CRM

  • Trigger milestone-based updates

  • Route follow-up actions conditionally

  • Extend project behavior dynamically

Use Workflows when you want to create projects.
Use Playbook Automations when you want projects to do things.

Best Practices for Clean Automation Design

  • Trigger on meaningful lifecycle events — not every task

  • Keep conditional logic simple

  • Always map a valid CRM record ID

  • When updating a Playbook used in Workflows, publish a new Workflow version

  • Test with real records

  • Review logs before making sweeping changes

Automation should reduce noise, not create it.

How This Connects to Workflow Automation

Here’s the full automation picture:

  • CRM → Workflow → Project Created

  • Project Activity → Playbook Automation → CRM Updated

That’s the closed loop.