How Do You Design a Multi-Board System in Altium Designer?

Detailed Explanation

Many products aren't a single PCB. A main board, a display or sensor daughtercard, and a battery/charging board connected by cables or board-to-board connectors is a common pattern in consumer, industrial, and wearable hardware. Altium Designer treats this kind of connected board set as one system with dedicated document types, rather than leaving the team to track connector pinouts and mechanical fit across separate, unrelated PCB projects by hand. For the schematic-to-PCB workflow each individual board still follows, see how do you use Altium Designer's schematic and PCB layout workflow? For how this compares with KiCad more broadly, see Altium Designer vs KiCad. See the Altium topic for the full set of Altium workflow guides.

The Problem Multi-Board Design Solves

Connecting boards through cables, harnesses, or direct board-to-board connectors introduces failure modes that don't show up on any single board's design rule check: a connector on one board that doesn't match its mating connector on another, a pin mapping that's correct in each board's own schematic but wrong once the two are actually wired together, or two boards that are individually manufacturable but physically collide once mounted in the shared enclosure. Catching these issues on a bench prototype, after both boards are already fabricated, is a far more expensive mistake than catching it during design. Altium's multi-board tools exist to move that check earlier, into the design phase itself.

Multi-Board Schematic: Capturing the Logical System

A multi-board project holds a multi-board schematic document (.MbsDoc) alongside references to each child PCB project. Each child board appears in this schematic as a graphical block called a module, with module entries exposed on the module representing that board's connectors. Altium recognises these automatically from components in the child project marked with a System: Connector parameter. The modules are then wired together with connections, which come in three forms depending on the physical interconnect they represent: a direct wire connection, a cable (a single connector-to-connector conduit for multiple signals), or a harness (a conduit that can fan out to more than one connector across the boards it links). This logical layer is where the system's intended connectivity is defined and checked, independent of how the boards are physically arranged.

Multi-Board Assembly: Physical Placement and Mates

The multi-board assembly document (.MbaDoc) is the physical counterpart. It imports the real PCB geometry (board outlines, mounted components, connector positions) from each child project referenced in the multi-board schematic, so the actual boards can be positioned and oriented relative to each other in 3D. Mates are the mechanism for keeping that positioning correct: a mate locks the relative placement of two boards (or a board and a mechanical reference), commonly used to align a board-to-board connector pair so the assembly reflects how the boards will actually plug together. With boards positioned, the assembly view supports mechanical collision checking against enclosure geometry or against each other, catching a clearance problem while it's still a design change rather than a re-spin.

Connectivity Validation Across Boards

Because the multi-board schematic captures connector-to-connector relationships explicitly, Altium can flag a mismatch between what one board's connector expects and what the connected board actually provides. It's the system-level equivalent of an electrical rule check, spanning project boundaries instead of stopping at a single board's net list. Changes made to a child project's connectors propagate back through the same Engineering Change Order (ECO) mechanism used for a normal schematic-to-PCB update (see how ECOs move a design from schematic to PCB), so a connector pinout change in one board's schematic surfaces as a synchronisation prompt in the multi-board project rather than silently going stale.

System-Level BOM and Documentation

A multi-board project also generates a system-level ActiveBOM that aggregates the bill of materials across every child PCB project into a single list, with each line item traceable back to the board it came from. This matters for products that are procured and assembled as one system even though they're fabricated as separate boards: a single, consolidated BOM avoids the error-prone manual merge of per-board BOMs that would otherwise be needed at the procurement or contract-manufacturing stage. The multi-board assembly can also feed Draftsman for system-level assembly drawings showing how the boards, cables, and enclosure fit together, alongside the standard per-board fabrication output each child project still produces independently.

How This Differs from KiCad's Workflow

KiCad does not have a dedicated multi-board project type, a shared system-level schematic, or an equivalent to Altium's module/mate/connection model as of current KiCad releases. Teams designing connected multi-board products in KiCad generally manage each board as its own separate project and cross-check connector pinouts and mechanical fit manually, or lean on community tooling built around KiCad's file formats for tasks like panelisation and board extraction from a shared layout. That workflow can still produce a correct multi-board product (plenty of connected-board hardware ships out of KiCad), but the system-level connectivity check, positional mating, and consolidated BOM that Altium's multi-board documents automate are, in KiCad, left to the design team's own process discipline rather than the tool. For the broader licensing, collaboration, and tooling comparison between the two platforms, see Altium Designer vs KiCad.

Multi-Board Design and Rigid-Flex Systems

Multi-board assemblies aren't limited to boards joined by connectors and cables. A project can also reference rigid-flex sub-projects as part of the same system, useful when a product mixes genuinely separate rigid boards (connected by cable) with a rigid-flex board whose own flex region already provides one of the interconnects. Deciding whether a given interconnect should be a flex circuit within one rigid-flex board or a cable between two separate boards in a multi-board assembly is a mechanical and cost trade-off (see rigid vs flex vs rigid-flex PCBs for that decision in more depth), but once made, both approaches are represented within Altium's multi-board tooling rather than requiring a different design system for each.

Design Considerations

• Mark connectors with the System: Connector parameter early, in each child project, not retroactively once the multi-board schematic is already being wired up. Retrofitting this after modules are placed means re-checking every module entry Altium already generated.
• Decide the module/connection structure before detailed board layout begins on any child project. Reworking which board owns which connector after layout is well underway is a bigger change than adjusting the logical connectivity on paper first.
• Use mates deliberately, not as an afterthought positioning aid. A mate that's set up correctly keeps the physical assembly consistent as individual boards evolve; skipping mates and manually repositioning boards after every change reintroduces the exact coordination problem multi-board design exists to solve.
• Treat the system-level BOM as the procurement source of truth for a multi-board product, rather than manually merging each child project's individual BOM, which is where per-board BOM discrepancies most often go unnoticed until a build. Zeus Design designs multi-board electronic products in Altium Designer, from individual board layout through system-level connectivity and mechanical fit.

Common Mistakes

• Treating each board as an independent project with no multi-board document at all, then discovering a connector mismatch or enclosure collision only once both boards come back from fabrication. This is exactly the class of error the multi-board schematic and assembly are built to catch earlier.
• Forgetting to re-import updated child project data into the multi-board assembly after a board's connector or outline changes, leaving the physical assembly showing stale geometry that no longer matches the actual PCB.
• Wiring connections in the multi-board schematic without first confirming pin-for-pin agreement between the mating connectors on each board, which produces a system schematic that looks complete but doesn't reflect what the physical connectors will actually do once mated.
• Skipping mechanical collision checking in the assembly view because the boards "look like they'll fit," rather than actually verifying clearance against the enclosure and against each other in 3D.
• Assuming a KiCad-based multi-board product can rely on the same automated system-level checks Altium provides. Without a native multi-board document type, that verification has to be built into the team's own process: connector pinout review, mechanical fit checks, and BOM consolidation all need an explicit manual step rather than a tool-enforced one.