Closed on one device. Open on the rest.

A recall lands, it matches three devices in a subscriber’s portfolio, and the recommended action reads the same on all three — because it is the same recommendation, written once, for one document. What happens next, per device, is not the same action. It is three.

One recommendation, one row per match

The recommendation’s text lives on the item: written once, by the reviewer who approved it, and never duplicated. Its state — open, in progress, done, or dismissed — lives somewhere else entirely: on the product_match row that joined this specific document to this specific product in your portfolio. A document that matches three of your products creates three match rows, and marking the action done on one of them writes to that row alone. The other two are untouched, and an approved match with no state row yet reads as open by default — the obligation exists the moment the item publishes, not the moment someone in your team clicks it.

Why this isn’t a bug to route around

Collapsing the three into one shared state would be the easier build. It would also be wrong: whether a device-quality finding actually reaches a given product, and what closing it out should mean, is a judgment specific to that product’s own file, made by whoever owns it. A recall of a component your lead device shares with two others might close identically on all three in an afternoon — or it might not, if one of the three sources that component from a different lot, a different supplier, a different line. Folding the three states into one would quietly assume the answer is always the first case.

The action closing on your lead device is not evidence that the finding was assessed, or dismissed, against the other two. It is evidence about the lead device, and nothing past it.

The practice

Reading the Action Center as a portfolio worklist, not a single running tally, means checking a shared finding against every product it matched — not just the one your team happened to open first. A device-quality program that already tracks corrective actions per product, per 21 CFR 820.10’s quality-management- system requirement, will recognize the shape: the same root cause can need a different disposition on every line it touches, and a system that only remembers one disposition per finding would be hiding that from you. FDA Radar keeps the three rows open until a person closes each one, which is described in full on the changelog. That per-product state is a record of what your team decided, not a determination of what the finding means for any one device — regulatory intelligence about where a shared finding lands, never regulatory advice about how each product should be dispositioned.