Difference between detaching and pushing overrides to main?

WHAT THIS TESTS: This question tests whether you understand the relationship between main components and instances in Figma, particularly in a shared library context. It reveals if you know how to manage local experimentation versus global system updates, and whether you grasp the governance implications of each action.

A GOOD ANSWER COVERS: First, define detaching as a permanent break. When you detach an instance, it becomes a regular frame or group with no link to the main component. Any future updates to the main will not apply, and your local changes do not affect the library. Second, define pushing overrides as an upstream sync. It takes the changes you made to a specific instance and applies them to the main component, which then propagates to all other instances after you publish the library update. Third, scenario for detaching: use it when you need a one-off deviation that should never be a variant, such as a marketing page with a radical layout change, or when you need to edit the layer tree in ways overrides do not support. Fourth, scenario for pushing overrides: use it when you discover a better default while working in context, like a corrected border radius, an updated icon, or fixed padding that should become the new standard for every team. Fifth, mention the publish step. In a shared library, pushing overrides modifies the main component in the library file, but subscribed files only see the change after you publish the update.

COMMON WRONG ANSWERS: A major red flag is saying you detach an instance to fix a bug in the design system. Detaching hides the fix locally and creates drift. Another red flag is claiming push overrides works without library edit access or without publishing; in a shared library, permissions and the publish flow matter. Candidates also stumble by saying push overrides breaks the link, or by not distinguishing between local scope and global impact.

LIKELY FOLLOW-UPS: An interviewer might ask what happens to nested instances when you detach a parent, or how you would handle a situation where you want to keep most of the system but need a persistent local override. They may also ask how library permissions affect who can push overrides, or how you would recover if someone detaches a widely used instance.

ONE CONCRETE EXAMPLE: Imagine a card component used across a product. A designer needs to add a third button and rearrange layers for a single promotional screen. They detach the instance because this layout is an exception, not a new variant. Later, another designer notices the card shadow looks too heavy in dark mode while working in a feature file. They adjust the shadow override on their instance, push that override to the main component, and publish the library. Every subscribed file now receives the lighter shadow automatically.