Updating Projects from a Library Module (Beta)
Last updated: October 19, 2026
Library modules are edited in a draft and published when they're ready. When you publish, you can push the module's changes into every customer project that already holds a copy of it. OnRamp shows you what will change in each project before anything is written, changes only work nobody has started, keeps the edits your teams made, and lets you undo the update for 14 days.
Before you start
Features turned on. Drafts for library modules come with playbook versioning and project updates. Ask your OnRamp contact if you don't see them.
Permission to publish. Anyone who can publish playbooks can publish a library module and 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.
Edit a library module
A published library module is read-only. Your changes go into a draft, and nothing you change reaches playbooks or projects until you publish.
Open the module from Library › Modules. It shows Published, when it was last published and by whom.
Select Edit. OnRamp makes a draft of the module and opens it. The header reads Editing draft.
Make your changes. They save as you go, and the header shows when the draft was last saved, for example Saved just now.
Select Publish when the module is ready, or Delete draft (the bin icon) to throw the draft away and go back to the published module.
Only one person edits a module's draft at a time. While someone else has it open, the header reads Locked by and their name. Select Unlock to take it over; their changes are already saved in the draft. If you come back to a draft later, select Edit draft to carry on.
Which projects a publish reaches
A publish can update every active project that holds a copy of the module, however the copy got there:
from a playbook that links the module,
added by a workflow's conditions,
added by an automation,
or chosen when the project was created, or added to it later.
Playbooks that link the module use the published module straight away, so new projects from them get it. Each linking playbook's Activity tab notes the publish.
A playbook's own copy isn't linked. A playbook that holds its own copy of a module, rather than linking to the library, isn't changed by a library publish, and neither are projects created from it. That copy follows the playbook's own versions. See Updating Projects from a Playbook.
How OnRamp decides what changes
For every item the module put in a project, OnRamp compares what the project received, what the module says now, and what the project holds today.
| The project received | The module now says | The project has |
|---|---|---|
| SOC 2 Type II report required. | SOC 2 or ISO 27001 report accepted. | SOC 2 Type II report required. |
Here the project still has what it received, 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 module's 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 publish made. A project that wasn't updated by an earlier publish gets this publish's changes, not everything it missed.
Publish and update projects
In the draft, select Publish. The Publish module dialog says what the publish does, for example: New projects, and the playbooks that link this module, use the published module. It also updates 3 of 3 active projects. If no active project holds a copy of the module, the dialog says so and the publish only affects playbooks and new projects.
Read What changes. It groups the changes into what the publish adds, changes and removes, with how many projects each reaches, for example: Adds 1 task · 3 projects; Changes 1 description · 1 project; Removes 1 task · 3 projects. Below it, Customers will see sums up what shows in customer portals, and the dialog lists the playbooks that link the module.
To decide project by project, select Review all N projects. Each project shows its changes and any edits it keeps. Clear a project to leave it out, or select Leave out on a single change. On a Your call line, choose whether to replace the team's edit for that project. The review works the same way as for a playbook; see Updating Projects from a Playbook.
Choose Update N projects now, or Only use the published module for new projects to leave projects in progress with the copy they have.
Optionally select Add a note for project teams, such as why the module changed. It appears in the activity of every project the update changes.
Select Publish and update N projects. The module is published, and you return to it.
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 3 of 3 projects, with undo for 14 days.
Each project's activity gets an entry for every item that changed, such as "Updated Review SOC 2 report from library module", with what changed and your note. OnRamp doesn't send assignment emails or run project automations when an update lands.
One update at a time. You can't publish the module again until its last update has finished. If you try, OnRamp tells you to publish once the update is done.
The record on the module
Every update leaves one entry on the module's Activity tab, for example: Updated projects in progress. Done: 3 of 3 projects updated.
The entry is tagged Done, Stopped before finishing or Undone, and lists the first few changes pushed. Select View record to see each project, what changed in it and how it went. The link works from any activity feed the entry appears in.
Undo an update
You can undo an update for 14 days. Select Undo update in the results dialog, or open the update from the module's Activity tab with View record.
Every value the update wrote goes back, unless the project has changed it again since.
Items the update added are removed while they're still untouched.
Items the update removed come back, with the subtasks they had.
The record then reads Update undone, project by project.
Undoing an update doesn't unpublish the module. To change the module back, edit it and publish again.
What a publish 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 |
|---|---|
| The module | Updates its name, its name in the customer portal and its task order setting. |
| 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. |
| 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. |
| Dependencies | Adds new blocked-by links and removes links the module dropped. Never blocks a task that's already under way. |
| Dates | Updates due and start offsets, counted from each project's start date, and date rules if your organization uses automatic dates. A project's end date never moves. Dates work as they do for playbook updates. |
| Automations | Adds new automations and updates changed ones. A deleted automation is turned off and keeps its history. An automation the team turned off is never turned back on, and nothing runs at the moment of the update. |
| Data fields | Adds fields the module or its tasks gained, empty unless you choose to use the module's value, and removes fields it dropped where the value is still empty or still the module's. |
| Removed items | Removes a task or subtask only where nobody has started, answered, commented on or logged time against it, and a subtask stays while an automation uses it. |
A library module doesn't carry project settings, email templates or resources, so a library publish never changes those. They come from the project's playbook.
Automations in older copies. Automation changes reach every project that got the module through a playbook. A project that got the module another way (a workflow, an automation, or added by hand) gets automation changes only if the module was added after library publishing arrived. Older copies like these keep their automations as they are, and everything else in them still updates.
New projects only
These changes reach projects created after you publish, but never projects already running. The publish dialog lists them as reaching new projects only.
The order of tasks and subtasks. Each project keeps its own order.
Tags on the module and its tasks.
Changed values of data fields that the module already had.
Merge field definitions. Each project keeps its own copy.
Questions
Does publishing a playbook update its linked library modules in projects?
No. A linked module belongs to the library, so a playbook update leaves its items alone. Its changes reach projects when you publish the library module.
Can I update projects later instead of when I publish?
Not yet. You decide in the publish dialog. If you choose new projects only, projects in progress keep the copy they have. If the update fails to start, the results dialog offers Try again.
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 sums up what they'll see before you publish.
Why was a project left alone?
The dialog, the review and the results always give the reason, such as a task in progress, a subtask already answered or an edit made in the project. The reasons are the same as for playbook updates; see the full list in Updating Projects from a Playbook.
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 module's activity marks the update Stopped before finishing.