In AutoCAD Electrical, a parent-child relationship is the mechanism that links related symbols together intelligently across a schematic drawing. A relay is the classic example: physically, it's one component you can hold in your hand, but on a schematic it might be represented by three, five, or six separate symbols spread across multiple drawings. The parent-child system is what keeps all of those symbols connected, synchronized, and aware of each other.

Here's how to build one from scratch and where the real intelligence comes from.

The Parent Symbol: Relay Coil

Start by inserting the relay coil as the parent symbol. When you insert it:

• Assign a tag and fill in descriptions as usual
• Select a catalog number. This is where the intelligence lives (more on this below)
• Once a catalog number is selected, terminal/pin numbers populate automatically from the catalog data, no manual entry needed
• Assign a location code (e.g., MCAB5)

The parent symbol is the "owner" of the relationship. Everything else ties back to it.

Child Symbols: Contacts

When you insert a contact (child symbol) and link it to the parent:

• All information already entered on the parent carries over automatically: tag, description, location code
• The next available pin numbers fill in automatically based on the catalog number
• A cross-reference appears on both symbols showing where each one is located. For example, the contact shows it cross-references back to the coil at drawing reference 403, and the coil shows its contacts cross-referenced in return

Insert a second contact and link it to the same parent. The next set of pin numbers fills in automatically again.

Where the Real Intelligence Is: The Catalog Number

Here's what separates a true parent-child relationship from just giving two symbols the same tag:

The catalog number defines how many children are allowed.

If the catalog number is configured for a two-contact relay and you try to insert a third contact, AutoCAD Electrical will stop you, "ran out of contacts." The software knows the physical component only has two contacts, and it enforces that limit automatically.

Inside the catalog number, there are two key columns:

• Coil pins (or more accurately, "parent pins"): defines the pin layout for the parent symbol
• Child pins: defines how many children exist and their pin assignments (e.g., two convertible contacts for a two-contact relay)

One note: the column is labeled "coil pins" in the catalog editor, but it applies to any parent symbol, not just relay coils. This trips people up when working with non-relay parent symbols where the parent isn't a coil at all.

Summary of What This Gets You

Giving symbols the same tag gets you basic cross-referencing. Building the relationship through the catalog number is what gives AutoCAD Electrical the intelligence to know what the component actually is and how many contacts it physically has.

Rule #1 in Autodesk Fusion is a foundational workflow principle that has been part of Fusion since the beginning. It states: always start a new component before doing design work, and make sure you are actively working inside that component. Every sketch, feature, extrusion, revolve, and hole you create should be owned by its component, not by the top-level design node.

Here's a walkthrough of what it means, why it exists, and what goes wrong when you skip it.

What Rule #1 Looks Like in Practice

1. Start a new design
2. Immediately create a new component (e.g., "Caster Body")
3. Activate that component, you'll see its individual timeline highlighted in purple at the bottom of the screen, separate from the overall design timeline
4. Do your design work, sketches, features, and holes while inside that component
5. When done, go back up to the top-level browser node
6. Create the next component and repeat

You can also link in external files as components alongside your internal ones, giving you a mix of internally built geometry and externally referenced parts within the same design.

Why This Matters

When Rule #1 is followed correctly, each component owns its own features. When you need to edit a hole, you find it in the timeline of the component it belongs to, not buried in a flat list of every feature across the entire design.

When Rule #1 is ignored, all of your sketches, extrusions, and features get assigned to the top-level design node. In the browser, these show up with a salmon-colored title, a visual signal that something is owned at the wrong level. As a design grows, this becomes increasingly difficult to navigate and edit because nothing is organized by component. Every feature for every part lives in one long, undifferentiated timeline.

Internal vs. External Components

A complete Fusion design can be a mix of both:

• Internal components: geometry built directly inside the design file following Rule #1
• External components: separate Fusion files linked into the design from outside

Both types appear in the browser and contribute to the overall assembly. The key is that whether a component is internal or external, it should always own its own features and geometry, never the top-level node.

The Bottom Line

Rule #1 is easy to overlook when you're starting out. It's a workflow habit, not a hard system restriction, so Fusion won't stop you from skipping it. But the longer you work without it, the messier your timeline gets and the harder edits become. Building the habit early saves significant rework later.

Wire annotation in AutoCAD Electrical is a tool that pulls wiring data from your schematic drawings and displays it graphically on panel layout drawings. By default, panel footprint symbols are purely mechanical representations. They show component placement but no wire numbers, terminal assignments, or tag information. Wire annotation bridges that gap. Here are the two ways to do it.

Method 1 - Generic Wire Annotation (Quick but Limited)
Go to the Panel tab → Wire Annotation and run it for the active drawing or the whole project. On the right side of the dialog, you can choose what information to display: wire number only, wire number with layer in parentheses, tag in parentheses, etc.

The result is mtext placed on each component showing the wiring detail pulled from your schematics. It works, but the downside is that the text often overlaps the graphical representation of your components, and repositioning everything to make it readable takes significant manual effort.

Method 2 - Custom Footprint Symbol with Attributes (More Control)
The cleaner approach is to create a dedicated footprint symbol specifically for displaying wiring information. This is a separate symbol from your standard panel footprint, same component, but built around connection point attributes instead of graphical geometry.

To make it work, the symbol needs:

• Connection point attributes (e.g., TERM01, TERM02) - same as when building schematic symbols
• Wire number attribute - this is what populates with the actual wire number when annotation runs
• Terminal description/pin number attribute - optional, but adds more detail per terminal

Once the symbol is built and inserted from the schematic list (matched by tag name), run Wire Annotation on the active drawing and the wiring detail fills in automatically, wire numbers, terminal assignments, and tags for every connection point on the component.

Practical workflow tip:
You don't have to choose one or the other permanently. One approach is to use a single footprint symbol with layers, freeze the wiring detail layers for fabrication drawings, and freeze the graphical layers when you just need the wiring view. Alternatively, maintain two separate footprint symbols for the same component and insert whichever is appropriate for the drawing's purpose.

The key takeaway: it's all about the attributes. If your footprint symbol doesn't have the right connection point attributes, wire annotation will run but nothing meaningful will populate.

Anyone else using custom wiring footprints for panel documentation?

Autodesk Build is a construction management platform within Autodesk Forma (formerly Autodesk Construction Cloud ACC) that centralizes project communication, document control, and field data in one place. Here's a breakdown of its core features and how they work.

RFIs

An RFI in Autodesk Build is a structured question-and-answer workflow. You create an RFI with a title, status, due date, and assigned reviewer, then submit it through a configurable approval workflow. Key details:

• RFIs can be linked to other RFIs (cascading/stacked)
• Each RFI tracks cost impact and schedule impact (yes/no)
• Custom fields and RFI types can be configured per project
• Closed RFIs can be hidden from the list view to reduce clutter on large jobs
• Every action is logged in a full activity log for transparency

Submittals

Submittals are separate from RFIs and handle product approvals. You create a submittal item, assign a spec section, set a due date, and attach supporting documentation (PDFs, photos, etc.). Numbering can follow spec sections or a global format depending on project setup.

Project Meetings

Meetings in Build start as an agenda and convert to minutes once the meeting occurs. You can:

• Connect meetings to Microsoft Teams (link auto-generates)
• Add agenda items as individual issues
• Invite non-members (e.g., vendors or external contacts) without giving them full project access
• Create follow-up meetings and track open action items from prior meetings

Photos

Photos can be dragged and dropped into Build with searchable metadata — filter by location, photo type, tags, uploader, or field crew. If photos have GPS metadata, they can be pinpointed on a project map.

Reports

Build includes pre-formatted report templates (e.g., RFI Detail) that output as PDFs. Reports can be filtered, sorted, versioned, and scheduled to run automatically on a recurring basis, with notifications sent to specified recipients when complete.

Activity Log

Every action across RFIs, submittals, files, sheets, and meetings is tracked in a full activity log, who created it, who changed it, when, and what changed. This is one of Build's strongest features for project accountability.