Numbers tables not shifting downward automatically

numbers tables not shifting ...

I have a complicated, multi sheet, multi-table Numbers spreadsheet. On a customer-facing page, some tables hide or reveal rows based on yes/no toggles on another sheet. This seems to work okay, and I only mention it for the "big picture."


These customer-facing pages have multiple tables...many locked in place for page layout reasons. And some of these 'locked in place' tables can grow in row-length based on the conditional options made on another sheet.


I have several other tables below these "locked" tables in close proximity...that are NOT locked.


My expectation is that as my locked tables grow in length...the unlocked tables would shift downward respecting the proximity I had specified.


I'm flummoxed because it doesn't seem to matter how I position the elements on the one page (close together, far apart, etc)...nothing seems to flow. I have to manually go in and reposition the unlocked elements every time.


HELP

Posted on Oct 26, 2026 1:21 PM

Reply
Question marked as Top-ranking reply

Posted on Oct 27, 2026 2:30 PM

I think it's not unreasonable to expect that using filters to reduce the number of displayed rows in a table would have a impact on other tables's positions, just as if rows had been added or deleted. That seems like a valid feature request to me.


The other approach I thought about may depend on the nature of the tables you're building... If it's just a Totals table at the bottom you could put those into Footer Rows - these are rows that are displayed at the bottom of a table, would automatically scale based on the displayed rows, and wouldn't be affected by the filter.


Here's an example I threw together:



The 'Back-End' table is pretty straightforward... a list of all the options and their prices. A simple calculation in the Total field works out the price if the corresponding Qty cell is > 0


The Customer table has four critical elements attached:


1) The full table has to have at least as many rows as the Back End table (or, more specifically, at least as many rows as you'd ever likely want to show).

2) One Footer row (Via Inspector -> Table -> Headers and Footer. Here I have it set to 1, so the bottom row is fixed.

3) The formula in cell A2 is:


=FILTER('Back-End'::A:E,'Back-End'::D>0,"")


This performs the first-level filter - it extracts all the data from Back-End::A:E where the value in column D is > 0 (i.e. there's a quantity set).


This has the effect of pulling all the non-0 quantity lines into this table (with a chunk of blank lines afterwards, like:



Which brings us to...


4) A filter is applied to this table to filter out any rows that are blank:



So now the empty rows in the table are suppressed. However, you still have a Totals row since that is part of the footer. In this row (or rows - you can designate up to 5 footer rows) you can put your blurb, Totals, signature lines, etc.


The filter is dynamic - as soon as you set a quantity on any other row in the Back-End table, it will automatically appear in the Customer Table (and disappear if the Qty is set to 0 or blank).


Here you can see I've set a Qty of 4 for item 'r', and it's added to the table, as well as expanded the footer to 5 rows with a signature/approval line:



(since the table is highlighted, you can also see the suppressed rows 9 through 40 since they're blank and filtered out).


This doesn't help if you want more than 5 rows at the footer, but hopefully this does get closer to what you're trying to achieve..?


9 replies
Question marked as Top-ranking reply

Oct 27, 2026 2:30 PM in response to FleursDuMois

I think it's not unreasonable to expect that using filters to reduce the number of displayed rows in a table would have a impact on other tables's positions, just as if rows had been added or deleted. That seems like a valid feature request to me.


The other approach I thought about may depend on the nature of the tables you're building... If it's just a Totals table at the bottom you could put those into Footer Rows - these are rows that are displayed at the bottom of a table, would automatically scale based on the displayed rows, and wouldn't be affected by the filter.


Here's an example I threw together:



The 'Back-End' table is pretty straightforward... a list of all the options and their prices. A simple calculation in the Total field works out the price if the corresponding Qty cell is > 0


The Customer table has four critical elements attached:


1) The full table has to have at least as many rows as the Back End table (or, more specifically, at least as many rows as you'd ever likely want to show).

2) One Footer row (Via Inspector -> Table -> Headers and Footer. Here I have it set to 1, so the bottom row is fixed.

3) The formula in cell A2 is:


=FILTER('Back-End'::A:E,'Back-End'::D>0,"")


This performs the first-level filter - it extracts all the data from Back-End::A:E where the value in column D is > 0 (i.e. there's a quantity set).


This has the effect of pulling all the non-0 quantity lines into this table (with a chunk of blank lines afterwards, like:



Which brings us to...


4) A filter is applied to this table to filter out any rows that are blank:



So now the empty rows in the table are suppressed. However, you still have a Totals row since that is part of the footer. In this row (or rows - you can designate up to 5 footer rows) you can put your blurb, Totals, signature lines, etc.


The filter is dynamic - as soon as you set a quantity on any other row in the Back-End table, it will automatically appear in the Customer Table (and disappear if the Qty is set to 0 or blank).


Here you can see I've set a Qty of 4 for item 'r', and it's added to the table, as well as expanded the footer to 5 rows with a signature/approval line:



(since the table is highlighted, you can also see the suppressed rows 9 through 40 since they're blank and filtered out).


This doesn't help if you want more than 5 rows at the footer, but hopefully this does get closer to what you're trying to achieve..?


Oct 26, 2026 5:24 PM in response to FleursDuMois

Maybe I'm misunderstanding what you're trying to do, or maybe you're misunderstanding Numbers' 'Lock' function...


In general, locked tables don't grow.

Locking a table prevents a user from entering values in the table (although the table may contain references that dynamically pull values from other tables). it also prevents rows or columns from being added.


The main purpose of locked tables is to prevent inadvertent changes to the data (such as by selecting a cell and accidentally typing a new value).


Given the above, I don't understand how:


"... some of these 'locked in place' tables can grow in row-length based on the conditional options made on another sheet"


I don't see how that can be.


If the 'locked' table is pulling data from another table, then it has to be big enough to contain all the results you want. If it isn't, Numbers will throw an error - it won't expand the table, whether or not the table is locked.


On that basis, I don't understand how you're doing what you say, even if the table was unlocked.


Can you shed some more light?

Oct 27, 2026 9:10 AM in response to FleursDuMois

OK, the fact you're using filters to control what's displayed makes a lot more sense, although I don't think it's going to solve your conundrum...


The issue is not with locked vs. unlocked tables. It's with filters.


Yes, unlocked tables will shift around on the page to accommodate new rows added to/deleted from nearby tables. This is true for your summary/'client-facing' tables, too.


The issue you're facing is that when you filter a table, this does not trigger the same table dance on the page. Technically you're neither adding rows to, nor removing rows from the table, so other tables see no need to shuffle. This is true whether the table in question is locked or not.


So your main table has to be big enough to accommodate the maximum number of rows you could want to display. The fact you then decide (via filtering) to hide some of those is of no relevance to the other tables.


Off hand, I don't see an easy way of achieving what you're trying to do... it would likely involve shifting the filters to formulas so that you can calculate how many rows you need, but it's an uplift, for sure.

Oct 26, 2026 5:54 PM in response to FleursDuMois

I'm guessing you have filters built into the locked tables or some similar arrangement.


You mention you have a "complicated, multi sheet, multi-table" document and a "customer-facing page." May I suggest that Numbers may not be the best tool for what you are trying to do?


Numbers is great for personal and small business projects. It allows elegant solutions, and simple collaboration.


But its design generally is not suited to complicated structures for multiple users.


SG

Oct 27, 2026 2:54 AM in response to FleursDuMois

Hi FleursDuMois,

Thank you for joining this user-to-user help forum. Welcome!

FleursDuMois wrote:
Snip ✄
These customer-facing pages have multiple tables
End Snip ✄

Umm... please explain "customer-facing pages".

...many locked in place for page layout reasons.

I do not understand "page layout reasons". Perhaps you are asking for advice on how to arrange tables on several sheets in Numbers.

And some of these 'locked in place' tables can grow in row-length based on the conditional options made on another sheet.

No, as Camelot has already explained: locked tables are locked. They do not expand.


Please examine the excellent Numbers Templates that demonstrate the Numbers approach:

  • Keep the input tables on their own sheet;
  • If necessary, keep the boring calculations on their own sheet;
  • Use a Presentation sheet to show your table of summaries and perhaps some graphics to engage your audience.


Happy Numbering!

Ian.



Oct 27, 2026 7:56 AM in response to Camelot

I use Numbers as both a spreadsheet and a page layout program to generate proposals for clients. There are a few "pretty" pages with multiple tables on them, and then there are a host of back-end utility pages I use to fill in the tables on the pretty pages the client sees. So one table might be a list of items with quantities, prices, and extended prices. Each item occupies a new row in the table. I "lock" tables on the pretty pages to prevent edits being made on the pretty pages. Those locked tables stay fixed in place...but they CAN grow in length as I add items to the client's list of things (from the back-end pages). It does this via filtering...if a quantity is blank or zero, that row is hidden.


So my problem is that I have another table below this list. It is NOT locked. So it should slide up and down the page as the table above it expands or shrinks. This used to work. And though I previously had a problem with it, I was told I needed to be careful about how much space I leave between the tables...they can't overlap for instance.


Nowadays seems there's nothing I can do but always go in and manually move the other tabes on the page. It's not the end of the world, but it used to work.

Oct 27, 2026 8:04 AM in response to SGIII

One of the features of Numbers that sets it apart is it's ability to act as a sudo page payout program. I use it to format proposals for clients so they don't look like spreadsheets. I use back-end pages that are pure utility...check boxes, lists, etc. that are then pulled in to the client pages to make it all look pretty and hide all the nitty-gritty stuff.


Tables used to slide up and down on a page if they weren't locked in much the same way text might flow around a photo when you move a photo in a true page layout program. That no longer seems to be working...or I've changed something to make it stop working.

Oct 27, 2026 1:35 PM in response to Camelot

Yeah...filtering is probably the issue. It was a god-send because that expanding table can have as many as 75 rows...but most clients only see 20-30. Before filtering, I had to go in a manually hide SO many rows. Now my back-end table shows all the rows, but the client table only shows the rows with a positive quantity.


I keep the 'grand totals' table separate from this main table because I hide the pricing info when I print the proposal for on-site work. If I loose track of the proposal on site, I don't want people to know the costs. So I hide all but one row in the grand totals table. Its this grand totals table that I have to keep manually adjusting on the page.


So it seems the filtering option might need a little tweaking to fall in line with how the tables shift around without filtering. I've already put in a request for filtering to work on columns too, so maybe I'd consider this maybe not a bug...but an enhancement or correction.

Numbers tables not shifting downward automatically

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.