Adapt a blueprint to your business
Everything a blueprint installs is ordinary configuration afterwards — rename stages, add or remove fields, adjust its automations, delete what you do not use. Adapt it to your language and process rather than bending your process to its defaults, and change one thing at a time so you can tell what broke if something does.
Requirements: a role that can manage collections, fields, and automations.
An installed blueprint is a starting point, not a contract. What it created behaves exactly like anything you built yourself, and the sooner it speaks your language rather than a generic one, the sooner people use it properly.
Start with the words
The cheapest and most valuable change is naming. If your team says "jobs" and the blueprint says "deals", rename it. If your stages are "quoted, scheduled, done" and the blueprint offers "qualification, proposal, negotiation", change them. Software that uses different words than the people using it creates a small tax on every conversation.
Renaming is safe: labels can be changed freely. Note that a field's underlying identifier stays as first created, so the label and identifier may drift apart — harmless, and worth knowing if you look at technical details later.
Then the fields
Add what your work needs and the blueprint could not have guessed — a reference number, a machine type, a preferred technician. Remove what you will never fill: an unused field is not neutral, it is a small permanent question in everyone's mind about whether it should be filled.
Prefer archiving over deleting when retiring a field, so nothing is lost if you were wrong — see add or change a field.
Then the stages
Stages are where a generic setup is most obviously generic. Match them to how work actually moves in your business, including the awkward step everyone forgets — "waiting on parts", "pending approval". One rule holds: stages that mean the work is finished must be marked as closed, which is what keeps "how much is still open" meaningful.
Then the automations
Read what shipped before changing it — a blueprint's automations are also a worked example of how automations are built, and there is usually something to learn from them. Then adjust: change the message text, alter the timing, switch off what does not apply.
Test after every change. A blueprint's automation may send mail, so verify with a dry run rather than on real customers — see create and activate an automation.
Change one thing at a time
The temptation after installing is to reshape everything at once. Resist it: when something stops working, you want to know which change did it. Adapt, use it for a few days, then adapt again. Real use surfaces things no amount of planning will.
Notes and limitations
- Labels rename freely; identifiers do not — the two may differ afterwards, which is fine.
- Field types are fixed — a different type means a new field and a data move.
- Archive rather than delete what you might want back.
- Finishing stages must be marked closed, whatever you name them.
- Reinstalling does not reset your changes — it creates a second set alongside the first, so it is not a way to undo customization.
- Removing the installation removes what it created — including anything you have since built on top of it.
Related
What a blueprint is and what it contains is in what a blueprint is; installing one in install a blueprint. The pieces you are adapting are covered in collections and fields and stages vs option field vs status.