Install a blueprint
Installing a blueprint has three stages: read what it will create and what it needs, run a conflict check against your business, then install. Prepare anything it points at — a mailbox, an audience collection — before you start, and resolve any conflicts piece by piece rather than letting it collide with what you already have.
Requirements: a role that can create collections and automations. Some blueprints also need things already set up — a connected mailbox, an existing collection to point at.
Steps
- Read what it will create. Every blueprint declares its components — the collections, templates, automations, and folders it adds — and the settings it needs from you. Read this first; it is the difference between installing deliberately and being surprised.
- Prepare what it points at. Some settings are references to things that must already exist. The email marketing blueprint, for instance, needs a connected mailbox to send from and an existing collection to use as its audience. Set those up before starting, or the install cannot proceed.
- Fill in its settings. Names, variants, and operational limits. Choose these thoughtfully — a blueprint often uses the name you give as a prefix across everything it creates, so a vague name spreads through the whole set.
- Run the conflict check. This compares what the blueprint would create against what your business already has, and reports collisions without changing anything. An empty report means it is safe to proceed.
- Resolve any conflicts, piece by piece. For each collision, choose: use what you already have, install alongside it under a different name, rename the incoming one, or skip that piece entirely. This is a per-component decision, not one blanket choice.
- Install. It builds everything at once — all of it or none of it, never a half-finished setup — and reports what was created.
- Check what landed and adapt it. Everything the blueprint made is ordinary configuration now: rename stages, add fields, adjust automations.
Do not skip the conflict check
It costs nothing and it is the only step that tells you what will collide before anything is written. Installing a second time with the same name is also handled gracefully — the new set is created alongside the old one under a distinguished name rather than overwriting it — but knowing that in advance beats discovering it afterwards.
Watch the operational settings
Some blueprints ship real operating limits rather than cosmetic defaults. Sending limits in a campaign blueprint, for example, are shared across every campaign running from that install, not per campaign — so the number you enter is a total, not a per-campaign allowance. Read what each setting actually governs; the defaults are deliberately conservative and are a sensible starting point.
Notes and limitations
- The install is all-or-nothing. You never end up with half a setup.
- An install can be removed, taking the components it created with it — so a wrong choice is recoverable.
- Reference settings must be resolved first. A blueprint pointing at a mailbox or a collection cannot install until those exist and meet its requirements.
- Target objects may need specific capabilities. An audience collection, for instance, must be able to hold contactable email addresses; one that cannot is rejected at install.
- The CRM setup is already installed when a business is created — do not install it again by hand.
Related
What blueprints are and what is inside one is covered in what a blueprint is. The pieces they assemble are explained in collections and fields and agents and automations; connecting a mailbox first is in connect a mailbox.