Skip to main content
Wangwangwang
New Member
September 2, 2026
Question

Variable Mode shows binding to the wrong collection even though the variable is correctly mapped

  • September 2, 2026
  • 1 reply
  • 16 views

Hi everyone,

I'm currently cleaning up and standardizing token mapping across our design system, and I've run into a variable/mode issue that I can't explain.

I have an Accordion component that should be mapped exclusively to our Gifted variable collection.

When I inspect the component and click into the variable bindings, everything appears correct. The variables are bound to the expected tokens within the Gifted collection.

However, when I look at the Modes section in the right-hand panel, Figma shows that the component is also tied to the Common Components collection, which shouldn't be happening.

What's confusing is that, after further investigation, it seems the issue may be related to a success state icon variable. The problem is:

  • The Accordion component doesn't appear to have any success state icon variables in its variable assignments.
  • The success state icon variable only exists in the Gifted collection.
  • There isn't a corresponding success state icon variable in the Common Components collection.
  • Yet the Modes panel still indicates a binding to the Common Components collection.

I'm trying to understand:

  1. Why would a collection appear in the Modes panel if none of the component's visible variable bindings reference that collection?
  2. Could there be hidden or inherited variable references causing this?
  3. Is there a way to identify exactly which layer/property is causing Figma to report that collection dependency?
  4. Has anyone seen stale or incorrect collection references persist after variables have been remapped?

I've attached screenrecording showing:

  1. There isn’t success state button token in Common Component collection
  1. however, the success state button component is shown as being mapped to Common Component collection ( eventhough it does not exist there)
  2. the success state button ONLY exist in Gifted Collection, which is the correctly mapping 

Any insights would be greatly appreciated. Thanks!

1 reply

djv
Figmate
Community Support
September 2, 2026

Hi ​@Wangwangwang, thanks for reaching out again with this!

(Linking your earlier post here, so anyone landing there will hopefully also find this one.)

Good news: this isn't stale data or a broken binding. What you're seeing is expected, but not obvious. The Modes panel lists every collection whose modes affect your selection, including collections reached indirectly through aliases. If a variable in Gifted is aliased to a variable in Common Components, then Common Components shows up in Modes, because switching its mode could still change what renders. No layer is directly bound to it, which is why clicking through every layer turns up nothing.

That also answers your question about the success state icon: the token doesn't need to exist in Common Components for the collection to appear. What matters is whether the Gifted token points at something that lives there. To confirm: open the Variables modal → Gifted collection → find your success state icon variable → click its value. If it shows a variable chip rather than a raw hex or number, that's an alias. Follow it and see which collection it lands in. Worth checking a few of your other Gifted tokens too; usually it's a whole layer of the system aliasing down to shared primitives, not one stray token.

 

If that's what's happening, you have two options depending on intent:

  • Keep it. Aliasing brand tokens down to a shared primitive layer is a common and healthy pattern. Common Components appearing in Modes is just Figma being transparent about the dependency.
  • Break it. If Gifted really must be self-contained, replace the aliased values with direct values (or with aliases to tokens inside Gifted). Once nothing in the chain reaches Common Components, it'll drop out of the Modes panel.

One thing to note either way: when a variable aliases across collections, it currently resolves from the referenced collection's default mode only; it won't follow along mode-for-mode. That's a known limitation we've had feedback on, and worth designing around if you're relying on aliases for theming. 

If you trace the aliases and Common Components still shows up with nothing pointing to it, let me know. I can help connect you with our support team to take a closer look.