Z-index property that is independent from Auto Layout

​@Josh But when though? Now it is limited to child items in a auto-layout...

November 2025 still having issues with z index management.

In the example I attach below, I’ve set the stacking as first on top because I need the gradient on the background to be under the carrousel. I need it to be under the faqs box too. However, as the faqs box is positioned after the text with the gradient background it stays below.

Perhaps I could set them both in a new auto layout, then change the stacking order for them both on that new AL. That way I could keep the page AL as first on top. However, it would be much easier to have a z index input for each AL child.

 

There are lots of other ways Figma could enable this. “Always on top” or “treat as overlay” or even allowing components to hold onto overlay interactions in prototyping. It’s frustratingly difficult to do something as basic as build a menu that reliably opens in instances.

I think it is genuinely insane that this has not been implemented. It’s completely messing up my attempts to make sticky elements because for whatever reason, the autolayout overrides the “always on top” behaviour of sticky elements and everything scrolls in front of it! What is even the point, then?

The team was “thinking this through” 4 years ago, did they somehow come to the conclusion that this is unnecessary despite this being crucial for accurate prototypes? I cannot rely on hacks forever.