Defaults, inheritance, and locking an organisation default in place. A template does nothing at all until something points at it, and this is the step people forget.
What binding means
Binding is the link between a record type and the template that governs it. Build the best claim approval in the world and nothing changes until a contract is told to use it. On a contract, the binding sits in that contract's own Settings, under its progress claim workflow, so two contracts on the same project can genuinely run different processes.
Where each module binds
Elsewhere the pattern is the same with a different location: per type in the tool's settings, or through an approval workflow card that can inherit the organisation default. Checking a module's bindings is the fastest way to answer "why did that not go for review".
Inheritance
Leave a binding on the organisation default and it follows the standard, including when the standard changes. Point it at a project copy and it stops following. Both are legitimate; what causes trouble is not knowing which one a project is on.
Auto-approve, never nothing
If a record type genuinely needs no review, bind an auto-approve template: a trigger straight to an End block that approves. It sounds like ceremony and it is not. There is always a workflow, some of them just say yes immediately, and that means every record has a recorded path rather than a silent gap.