Building Reusable, Linked Modules for Scalable Onboarding

Last updated: March 23, 2026

If Playbooks are your onboarding blueprint, Modules are the structured milestones that bring them to life. When you move Modules into the Library, you stop rebuilding work — and start scaling it.

What Are Library Modules?

Library Modules are reusable milestone blocks that can be inserted into Playbooks, other onboarding flows, and active projects. Instead of recreating "Technical Setup" in three different Playbooks, you create it once in the Library — and reuse it everywhere.

If a milestone appears in more than one Playbook, it belongs in the Library.

Step 1: Create a Module

  1. Go to Library › Modules and click + Create Module.

  2. Add a name, description, and tasks.

  3. Optionally configure: role restrictions, data fields, visibility settings, and Work Order.

  4. Click Save.

Your module is now available to link into any Playbook.

Step 2: Link the Module to a Playbook

  1. Go to Library › Playbooks and open the Playbook you want to edit.

  2. In the List tab, click + Module and choose Add Linked Module.

  3. Select your module.

The module appears in your Playbook with a Linked Module tag. You can still add Playbook-specific tasks around it to customize the flow.

Step 3: View Where a Module Is Used

  1. Open the module in Library › Modules.

  2. Click the Linked Playbooks tab.

A banner shows how many Playbooks are using that module (e.g., "This Module is linked to 3 Playbooks").

How Updates Propagate

Edits made to a linked module in the Library automatically propagate to every Playbook using it. One important exception: projects that have already been created do not retroactively update — propagation only affects future projects.

Within a Playbook, linked modules display a green Linked Module label. Click through to view or manage the source module in the Library.

Planning a major change? Duplicate the module before editing to avoid unexpected updates in live Playbooks.

Internal Naming vs. Customer Portal Naming

Modules support separate internal and customer-facing names.

  • Internal Name — what your team sees in the Library, Playbooks, and reporting. Use operational language (e.g., "Phase 2 – Technical Enablement").

  • Customer Portal Name — what customers see in the portal and email notifications. If left blank, the internal name is used. Override it when internal language includes jargon, acronyms, or process terms customers shouldn't see (e.g., portal name: "Security & Setup").

Work Order: Controlling Task Sequence

In Module Settings, the Work Order setting controls whether tasks must be completed in sequence. Options:

  • Any Order — default; tasks can be completed in any sequence.

  • Customer Tasks Sequential — customer tasks must follow order; internal tasks are flexible.

  • Internal Tasks Sequential — internal tasks must follow order; customer tasks are flexible.

  • All Tasks Sequential — every task must be completed in order.

Work Order is enforced across all projects using the module, and Library updates apply to future projects only.

Using Modules in Conditional Logic

Library Modules unlock flexible automation. You can add modules conditionally via Workflows — triggered by CRM values, task completions, or other events. Examples:

  • If Opportunity Type = Enterprise → Add "Enterprise Security Review" module

  • When "SSO Confirmed" task completes → Add "SSO Configuration" module

Adding Modules to In-Flight Projects

Library Modules aren't just for Playbooks. You can insert them into active projects to introduce structured work mid-stream — especially useful when requirements change, services are added, or customers upgrade plans.

Tips & Troubleshooting

  • Archiving a linked module: You'll be prompted to leave an unlinked copy in each Playbook or remove the module from all linked Playbooks entirely. This can't be undone — choose carefully.

  • Permissions: You need edit access to both Playbooks and Modules to create, link, or archive modules.

Best Practices

  • Keep modules focused on a single milestone — avoid mixing unrelated work

  • Name clearly and consistently; use Portal names strategically

  • Update centrally — never duplicate to make a small change

  • Design modules with automation in mind from the start