Updating Projects from a Playbook (Beta)
Last updated: October 14, 2026
When you publish a new version of a playbook, you can push its changes into the customer projects already running on earlier versions. OnRamp shows you exactly what will change in each project before anything is written, only changes work nobody has started, keeps every edit your teams made, and lets you undo the whole update for 14 days.
Before you start
Permission to publish. Anyone who can publish the playbook can update its projects.
Projects you can edit. An update only reaches projects you're allowed to edit. Others aren't listed and aren't changed.
Finished and archived projects are never updated. Neither is any task that is in progress, completed or skipped.
How OnRamp decides what changes
For every item in every project, OnRamp compares three things: what the version the project came from said, what the new version says, and what the project holds today.
Old version said | New version says | The project has |
|---|---|---|
Introduce both teams and agree the go-live date. | Introduce both teams, confirm the payroll calendar, and agree the go-live date. | Introduce both teams and agree the go-live date. |
Here the project still matches the old version, so nobody changed it, and it gets the new text. If the team had rewritten the description for their customer, the update would keep their version and mark it Your call, so you can decide whether to replace it.
Changed: items nobody has started or edited get the new version.
Your call: items the project team edited keep the team's version unless you choose to replace it.
Left alone: started, completed, skipped or answered work never changes, and neither does anything the team added themselves.
Each publish pushes the changes that version made. A project created from version 2 gets what version 5 changed, not everything versions 3 and 4 changed as well.
Publish and update projects
Open the draft of your playbook and select Publish. If no customer projects are running an earlier version, the dialog says so and only new projects get the new version.
Read What this version pushes to N projects in progress. Each change is listed with what happens to it, for example: Configure SSO · new due date — 38 projects get it · 9 left alone (6 in progress, 3 done) · arrives due today in 3. The number in the heading is the number of projects this publish will update, and it always matches the number on the Publish and update button.
Make the decisions marked Your call. There are two kinds:
A team has its own version. Choose Keep theirs (the default) or Replace with yours.
A new data field has a value in the playbook. Choose Leave empty (the default) or Use the playbook's value.
One choice applies to every project in that line. To decide project by project, use Review projects (below).
Check New projects only. These changes reach projects created from now on but not projects already running, for example a new module order. See the full list below.
Choose Update N projects, or Don't change any projects in progress to publish for new projects only.
Optionally add a Note for your team, such as why the playbook changed. It appears in the activity of every project the update changes.
Select Publish and update N projects.
However many changes a version has, only the list of changes scrolls. The choice, the note and the button stay in view.
Review project by project
Select Review projects in the publish dialog to open What changes in each customer project. It has two views of the same choices, so switching between them never loses a decision.
By project lists every project with what it gets and what it keeps back. Search for a project by name, expand it to see each change, and clear Update this project to leave it out.
By change lists each change once, with its projects grouped under Gets it, Your call, Left alone and Already has it. Clear Include to drop a change everywhere.
On a Your call line, tick Replace their edit with yours (or Use the playbook's value) to decide for that one project.
The review also flags things worth knowing before you publish:
After the project's end date: a new due date lands after the project's end date. See Dates below.
Won't run: a new automation is added, but what starts it has already happened in that project.
Tasks that become visible to customers, and tasks that arrive already due today.
While the update runs
The update runs in the background, one project at a time. You can close the dialog; the update keeps going. If someone starts a task while it runs, that task is checked again just before it would be changed, and left alone.
When it finishes, the dialog shows how it went, for example Updated 41 projects and Left alone in 9 projects, with a row per project and its result.
Each project's activity gets an entry for every item that changed, such as "Updated Kickoff call from playbook", with what changed, which version it came from, and your note.
OnRamp doesn't send assignment emails or run project automations when an update lands. Integrations and webhooks are told about added modules and tasks, the same as when they're added by hand.
The record on the playbook
Every update leaves one entry on the playbook's Activity tab, for example: Pushed version 5 to projects in progress. Done: 41 of 50 projects updated; 9 left alone. Note: Customers kept missing the payroll calendar.
The entry is tagged Done, Stopped before finishing or Undone, and lists the first few changes pushed. Select View record to see every change pushed and each project's result. The link works from any activity feed the entry appears in.
The record is kept for good. The detail of each individual change is cleared after the 14-day undo window, but the playbook keeps the list of changes pushed and every project's outcome.
Undo an update
You can undo an update for 14 days. Select Undo update in the results dialog, or open the update from the playbook's Activity tab with View record.
Every value the update wrote goes back, unless the project has changed it again since. Those read Kept — changed again since.
Items the update added are removed while they're still untouched.
Items the update removed come back.
The undo adds its own entry to the playbook's activity, for example "Put back in 41 projects".
After 14 days an update can't be undone. To reverse it then, publish a new version that changes things back.
What an update can change
Everything below follows the same rules: it only changes work nobody has started, a team's own edit is Your call, and anything the team added or took off themselves is left alone.
Area | What an update does |
|---|---|
Project settings | Updates the description, welcome message, key files and media, whether comments are allowed, customer and internal emails, hiding internal task details from customers, the portal AI agent, showing task start dates in the portal, and the first visit experience. Text is filled in with each project's own merge field values. |
Email templates | Adds template choices the project doesn't have. Changes a choice only where the project still uses the old version's choice. See Custom Email Templates. |
Modules | Renames modules, updates their name in the customer portal and their task order setting, and adds new modules after the same neighbour they follow in the playbook. A new module isn't added if a workflow or automation already put the same module in the project. |
Tasks | Updates the name, description, whether customers can see it, whether it can be done out of order, whether it needs review, required subtasks, time allotted and whether the description shows. Adds new tasks with their subtasks. Moves a task to another module when the playbook moved it. |
Subtasks | Updates the name, description, type and content, and adds new subtasks. A question's change isn't pushed while subtasks still branch from an option it removes. |
Roles | Reassigns a task to the person who holds the new role in that project, without sending an assignment email. Left alone where the role doesn't fit whether the task is internal or customer-facing. See Using Roles in Playbooks and Projects. |
Dependencies | Adds new blocked-by links; a link to a task that's already finished counts as met. Removes links the playbook dropped, and a task left with nothing to wait on becomes ready to start. Never blocks a task that's already under way. |
Dates | Updates due and start offsets. See Dates below. |
Automations | Adds new automations and updates changed ones. A deleted automation is turned off, the way deleting one by hand does, and keeps its history. An automation the team turned off is never turned back on. Nothing runs at the moment of the update; a new automation runs the next time its trigger happens. See Understanding Playbook & Project Automations. |
Resources | Attaches new resources and folders, and takes off ones the playbook removed where the project got them from the playbook. |
Data fields | Adds new fields empty, or with the playbook's value if you chose Use the playbook's value. Removes fields the playbook dropped where the value is still empty or still the playbook's. A field set to apply to every project is never removed. |
Removed items | Removes a module, task or subtask only where nobody has started, answered, commented on or logged time against it. A module goes only when all its tasks are going, and a subtask stays while an automation uses it. |
New projects only
These changes reach projects created after you publish, but never projects already running. The publish dialog lists them under New projects only.
The order of modules, tasks and subtasks. Each project keeps its own order.
Merge field definitions, such as a field's source or fallback text. Each project keeps its own copy.
Changed values of data fields both versions have, and changed settings of resources both versions have.
The playbook's tags, icon, colour, value and currency.
Excluding weekends from dates, because it would move every date in a project at once.
The target length, because it would move a project's end date.
Changes to modules from your module library aren't part of a playbook's versions, so updates don't change library modules in projects.
Dates
Due and start offsets
When the playbook changes a task's offset, the project gets the new date only if the task's date is still the one the old offset gave. If someone moved the date, it's Your call.
The new date counts from the project's start date, not from the day you publish. For a project that started on 1 October, moving a task from day 10 to day 17 makes it due on 18 October, or the following Monday if the project skips weekends.
If the new date has already passed, the task becomes due today instead, so it doesn't arrive overdue. New tasks work the same way.
The project's end date
An update never moves a project's end date, which is usually what you promised the customer. If a new due date lands after it, the dialog says "due after the project's end date in N", and the review tags those tasks After the project's end date, so you can adjust the end date yourself where it makes sense.
Automatic dates
If your organization uses automatic dates:
Date rules are updated. When the playbook changes a task's rule, such as "due 2 days after Kickoff call is done" instead of 5, tasks that haven't started get the new rule and their dates are worked out again. A team's own rule is Your call. New tasks arrive with their rules.
Switching automatic dates on or off is pushed. Projects still using the old setting are switched, and no date moves when they switch. A project whose team changed the setting themselves is Your call.
A date someone set by hand keeps their date, whatever the update changes around it.
Why a project was left alone
The dialog, the review and the results all give a reason whenever a change doesn't reach a project.
Reason | What it means |
|---|---|
Task in progress, Task completed, Task skipped | Work that's under way or finished never changes. |
Subtask already answered | An answer is never overwritten. |
Edited in this project | The team changed it. This is Your call: you can replace their edit. |
Has a value in the playbook | A new data field would arrive with the playbook's value. It's left empty unless you choose Use the playbook's value. |
Module already complete | Adding to it would reopen a finished module. |
Already added by a workflow or automation | The project has it already, so it isn't added twice. |
Someone has worked on it | A removed item stays where someone answered, commented or logged time. |
Other items are still in it | A removed module stays while it holds tasks that aren't leaving. |
An automation uses it | A removed subtask stays while an automation depends on it. |
Subtasks still hang from an option it drops | A question change that removes an option waits until nothing branches from it. |
Its module or task isn't in this project | What the change depends on was removed from this project. |
Turned off in this project | The team turned off this automation, so it isn't changed or turned back on. |
Would make tasks wait on each other | A new link would create a loop, so it isn't added. |
Its role doesn't match whether the task is internal or customer-facing | The role would not fit this project's version of the task. |
Can't be matched safely | The project has more than one copy of the item, so OnRamp won't guess which to change. |
New projects only — can't be pushed yet | This kind of change only reaches new projects. |
Questions
Can I update projects later instead of when I publish?
Not yet. Today you decide in the publish dialog. If you choose not to update projects, they keep the version they're on.
Will customers or teammates get emails?
No. An update doesn't send assignment emails or run automations. Customers see the changes in their portal right away, so the dialog tells you when a task becomes visible to customers.
What about projects created by a workflow?
They're updated like any other project. Modules a workflow added from your module library aren't part of the playbook, so updates leave them alone, and a module the update would add isn't added again if the workflow already added it. New workflow runs use the new version automatically; the publish dialog lists the workflows that use the playbook. See Automating Project Creation with Workflows.
Does a project catch up on every version it missed?
No. Each publish pushes the changes that version made. A project on an older version gets the newest version's changes, not every change since it was created.
What does "Won't run" mean on an automation?
The automation is still added to the project, but what starts it has already happened there, so it won't run in that project. It runs in projects where that event is still to come.
Something went wrong partway through. What happens?
Each project is updated on its own, so one project failing doesn't affect the others. If the update stops early, projects it already updated keep their changes and can still be undone, and the playbook's activity marks the update Stopped before finishing.