There is unfortunately no way to do so as of today. You would have to remove auto-layout entirely or maybe use variants of a component without autol-layout?

Check this other post too:

https://forum.figma.com/t/auto-layout-reverses-the-order-of-my-layers/1190

I’ve also just come across this same issue. Would be nice to be able to override the z behaviour.

Same problem. Can’t build prototypes without adjustable z-index

Still no override for this? If I do not use auto-layout I cannot have component elements “Fill container”. So I cannot have possibility to scale manually component instances. But, if I use auto-layout my helper tooltip stays on the lower z-index. Is there maybe a way to reverse the ordering in the auto-layout or force the z-index like in html (like “z-index: 10001 !important;”)?

I’ve submitted a feature request recently.

Can we keep upvoting and resubmitting until @anon21722796 accepts the importance of this and replies “We have added this to our roadmap”?

Agreed, this is an essential feature that Auto Layout should support. Any word from @Figma_support?

Also encountering this issue. We want to componentize dropdown as an input state, but the order of layers is getting in our way. Seems like such a huge limitation!!

This is such a kludgy way to handle auto layout… please fix this it’s making things so unnecessarily difficult

I’ve done this. It’s a wonky solution, but it works. If your object is at the top of the auto layout order in layers, move it to the bottom. Flip the entire group (that has auto layout applied) vertically (Object>Flip Vertically, or ‘Shift + V’). Then flip each individual item in the auto layout order in layers vertically so that everything is displayed right side up. You may need to do some additional layer sorting for the other items. But now, you’ll notice the z-index ordering is reversed so that things overlap the way you want them to. If this is in a component and you want to avoid things flipping in your designs, group everything in a container group and move your auto layout to the container.

This worked 🙌

@Bobby_Spiecher I combined the steps of your hack into a plugin you so you can do it in one step now.

Same wonky solution so not ideal but at least it’s faster.

I agree, we need to be able to manually adjust the z-index of layers without interfering with the order they are laid out.

[Usecase]: In my case I have an autolayouted frame which holds three layers, one of which contains a child which overflows the parent. This represents a dropdown menu being active which should not push content downards.

This is the way

Yeah, here is another need 😦. That can be similar as “fix scroll” usage maybe.

There’s actually an easier way to do this reversal “hack”… Simply select the auto layout frame you wish to reverse and manually drag the top adjustment handle of the frame past the bottom of the frame to its same height.

That being said, @Figma_Support can we please get confirmation that you’ve seen this issue and are taking the step to build a feature that allows this z-index reversal? This hack breaks the auto layout by reversing the entire frame. Thus we cannot build components which have predictable overrides.

Same problem on my side and I can’t delete my auto-layout because it will break the interaction of my prototype. Is there still no solution to keep using auto layout and force a certain z-index?

Not sure if anyone in this thread is still stuck trying to figure out how to achieve this, but you might have some luck by editing the “advanced layout” settings and change the canvas stacking setting to “first on top”, which essentially will reverse the z-index priority of the items in your auto layout frame:

This worked. Cheers Bobby

Thank you! You’re a hero.

This Really Worked <3

And now add a dropdown component where options open downwards, with tooltip flying upwards, and you are back to the frustration land.

This stacking order does not fill the need for z-index

Not sure if I understand your specific case correctly, but do you mean something like this?

I was able to achieve this without modifying any auto-layout child’s z-index. The Figma file is public so if you want to see how everything is set up you can do so here:

This is the case

I see. You can still achieve this effect with auto layout and reversing the stacking order of items, but you will have to reorganize how your UI is built somewhat.

Instead of having a single vertical auto layout and several rows, you will want to have a vertical auto layout for each column’s rows (ID/Risk/Status). You can then set the stacking order for the Risk column to “First on top”, and the stacking order for the Status row to “Last on top”.

I updated the file I shared earlier with this prototype, so feel free to take a look at it to see how I’ve set it up. Maybe not the cleanest solution, but it will do what you need.

Hi Simon. I appreciate you going new lengths to workaround the lack of adjustable z-index mechanism and recreating the scenario.

You solved the problem locally. There are many other creative ways to solve this locally. Like rendering tooltips as overlays for example.

You changed the layer structure from row-based to column-based. This allowed you to have up and down flyouts to display correctly, but broke row hover possibility, cell stretching when one of the cells has multi-row content and will still have the same z-index issue for everything extending left and right. So you basically rotated the problem from vertical plane to the horizontal, creating additional non-z-index related errors.

Without z-index properly implemented by Figma, workarounds will always be solved in one place, but always break in another.

We have a modular (cell content, cell, row, grid) data grid component in our design system, used across an enterprise application landscape. And data grid is just one of many components affected by the lack of z-index. Others are lists, selectors, search forms and more.

Patching all instances locally is a seriously bad decision because of the scale. It will require design maintenance effort that is larger than the benefits it returns. We are better off calling front-end developers when they are about to develop the UI to explain things verbally, or creating a throw-away screenshots.

Although your help effort is appreciated, this is not an issue a community member can help resolve. This is a request to Figma dev team for an irreplaceable functionality. Unfortunately Figma is not hurrying.