Drawing Flag Notes vs BOM Cells in SolidWorks — Workarounds for the Missing Parametric Link

A question on r/SolidWorks last week: can you make flag note ⑤ in a drawing appear automatically in the BOM cell for line item 1? The answers suggested balloons, linked notes, and custom properties — all partially right, none complete. SolidWorks does not have a native mechanism for this. What it has is a custom property workaround that approximates the result, with specific limitations that trip people up.

What flag notes are (and are not)

A flag note in SolidWorks is a drawing annotation with a bordered symbol — typically a circled number like ①, ②, ③ — stored in a flag note bank. You create them via Insert → Annotations → Note, check Flag Note, and assign a border shape and symbol from the PropertyManager. Once created, a note can be added to the bank with Add to Flag Note Bank, making the symbol reusable across sheets.

Flag notes exist for process callouts: standard notes that appear in multiple drawings with a consistent symbol (safety warnings, surface treatment specifications, inspection requirements). The symbol is cosmetic. SolidWorks tracks flag notes for consistency — you can view all notes sharing a symbol across sheets — but the symbol does not carry parametric data. It is a border shape applied to a text annotation, not a BOM field.

This is the root of the mismatch. When users want “flag note ⑤ → BOM row 1”, what they actually want is: a value that appears both in the BOM table (in a specific cell for a specific line item) and in a drawing note (formatted as a flag), where both update together when the underlying data changes. SolidWorks cannot do that natively because drawing notes and BOM cells are independent data consumers. A note reads from either the drawing document or from a model custom property. A BOM cell reads from a model custom property. They share a source, but there is no direct note-to-cell link in either direction.

The $PRP workaround

The standard workaround uses custom properties as the shared source. Both the flag note and the BOM cell read from the same property on the part or assembly. When the property changes, both update.

Here is the mechanism:

Step 1: Add a custom property to the part.

In the part file, open File → Properties (or the custom properties tab in the Task Pane). Add a property — call it ProcessNote or ShopNote or whatever matches your drawing standard. Set the value to the note text you want in the BOM and on the drawing.

Property name:  ProcessNote
Type:           Text
Value:          Heat treat per AMS 2759/3

Step 2: Add a BOM column linked to that property.

In the drawing, right-click the BOM → Edit. Add a column, set the column type to Custom Property, and type the property name (ProcessNote). The BOM cell for each line item now shows the property value from that component’s file.

Step 3: Create the flag note referencing the same property.

Insert a note (Insert → Annotations → Note). Instead of typing the text directly, use a property link. In the note text box, click the Link to Property icon (the paperclip button in the note editor toolbar), choose Component in view, and select ProcessNote from the list.

The note now reads: $PRPVIEW:"ProcessNote" internally, displayed as whatever value the property holds.

Step 4: Apply the flag note border.

With the note active, go to the Border section in the PropertyManager, choose your border shape (circle, hexagon, flag shape), and set the symbol or sequence number. Check Add to Flag Note Bank if you want this to appear in the bank for reuse.

The result: the BOM cell and the drawing note both display the ProcessNote value. Change the property in the part file, and both update on regeneration.

Where it breaks down

The link runs one direction only. If someone edits the BOM cell (double-clicks, changes the text, clicks Keep Link), the cell is now broken from the source property. The flag note still shows the original property value. There is no way to type in the flag note and push the change back to the BOM — the $PRP reference is read-only from the note side.

The note does not know which BOM row it corresponds to. SolidWorks has no mechanism to say “this flag note belongs to item 3 in the BOM.” The note is attached to a view or a feature annotation, and the BOM row is determined by BOM ordering. If you reorder the BOM (sort by part number, or a new component is added that changes item numbers), the note still shows the same property value — which is correct — but the visual association between ③ and BOM row 3 is now broken unless the note content (not the symbol) uniquely identifies the item.

Multi-configuration assemblies are awkward. If a single assembly has configurations that change the active components, the property value shown in the BOM may differ per configuration. The flag note uses $PRPVIEW which reads from the model as loaded in that drawing view. If you have a configuration-specific drawing view, the note and BOM cell are consistent for that view. If the drawing has views from multiple configurations of the same assembly, the note will always reflect whichever configuration the drawing view it is anchored to uses.

Weldment cut list tables are different. If you are working with weldment cut lists rather than assembly BOMs, the $PRPWLD prefix is the right syntax — $PRPWLD:"PropertyName" reads from weldment cut list item properties. The regular $PRPVIEW does not resolve cut list item properties correctly. Mixing the two in the same drawing produces notes that look correct in preview and show blank on paper.

The $PRP namespace map

When building these note links manually, the correct prefix depends on what you are reading from:

The most robust choice for notes that should track a specific component is $PRPVIEW anchored to the view that shows that component. Notes floating off in blank drawing space with no view attachment will resolve $PRPVIEW to the first model view on the sheet — which may not be the component you intended.

Doing this in the API

If you need to set these cross-references programmatically — for example, building a macro that populates notes from custom properties on an assembly — the INote interface exposes the raw note text including the $PRP tokens:

// C# — read the raw text of a note (includes $PRP tokens)
var note = (INote)swDraw.GetFirstNote();
while (note != null)
{
    string rawText = note.GetText();
    // rawText might be: "$PRPVIEW:\"ProcessNote\""
    // note.GetText() returns the substituted value, 
    // note.PropertyLinksText returns the raw token string
    Console.WriteLine(rawText);
    note = (INote)note.GetNext();
}

The distinction matters for macros that re-populate note text: if you call INote.SetText("new value"), you replace the $PRP link with a literal string. The note no longer updates when the property changes. To preserve the link, you must construct the $PRP token string and set it via the text, not the resolved value.

To write a property link programmatically:

// Set a note to track a custom property from its attached view
note.SetText("$PRPVIEW:\"ProcessNote\"");

SolidWorks will resolve the token on the next regeneration. This is how you build note templates via macro without breaking the parametric link.

What this does not solve

The original user request — flag note ⑤ in the drawing should appear in the BOM cell for line item 1 — cannot be fully automated with this approach. The custom property bridge handles the case where you want consistent text to appear in both places. It does not handle the case where the flag note number (⑤) is meaningful and should appear as data in the BOM. That would require custom properties like InspectionCode set to 5 per part, BOM column showing InspectionCode, and a flag note bank with symbol ⑤ anchored to those same parts. Consistent, but manual: somebody still has to assign the right numbers to the right parts.

For teams where the flag note sequence is driven by manufacturing or inspection requirements that live outside SolidWorks, the gap is real. The correct architecture is to own that data in SolidWorks as a custom property from the start — entered in the part file, surfaced in the BOM column, referenced in the drawing note — rather than trying to link an annotation that was never designed to carry process data to a BOM table that was never designed to receive it.

Internal linking between the BOM coordination problem across CAD, procurement, and ERP and this annotation layer is the same structural issue: notes and BOM cells both read from model properties, but the assumption that they will stay in sync breaks the moment someone edits one side directly. The SolidWorks weldment cut list naming behavior is the same class of problem — data that looks like it should be shared is actually maintained in two separate systems that the user must keep manually aligned.