Numbers: Auto-add rows/columns to multiple tables

I have an Apple Numbers spreadsheet with multiple tables. In those tables I'm adding data for each day and each day gets a new column OR row (depending on the table).


Right now I have to manually add a column or row on all the other tables and I would like to know whether or not, if I add a row or column to a table, can I make all the other tables automatically add a brand new row or column to ALL of the other tables? Is that possible in Apple Numbers?


Or, and these tables are spread across multiple sheets, if that matters.


For example. In "Table 1" I just added today's sales totals for each person (as if "today" were 1/7/2026) by adding a new column to Table 1.


I would like for "Table 2" and "Table 3" to automatically add a new column anytime I create a new column in Table 1. So far I have yet to be able to figure out how to do this. So ... help.






iMac 27″

Posted on Jan 19, 2026 12:44 PM

Reply
Question marked as Top-ranking reply

Posted on Jan 19, 2026 1:28 PM

Only indirectly, but there are a couple of options.


First would be a pivot table - it looks like Tables 2 and 3 are summarizing the data in Table 1, so it may be a good candidate for a Pivot Table.

Pivot Tables automatically expand to show the relevant data, so adding an additional Date on Table 1 would automatically extend Table 2.


Pivot tables can automatically handle running totals, and dividing out by month (or quarter, or year). Here's a quick Pivot Table I made of some sample data (I added extra data to extend into additional months so show the monthly breakdown):


Because of the potential overhead of the way pivot tables work, they are not dynamic - you'll need to periodically click the refresh button in the Pivot Table sidebar to have it update, but other than that, most of the work will be done for you.


The other possible path would be spilled columns.


Spilled columns (or rows) use formulas that return a range of values rather than a single value. Numbers can then spread (or 'spill') these values into multiple cells.

The only downside is that spilled formulas will throw an error if there's not enough room - for example, a formula that returns 10 columns, but there are only 9 columns on the table - you'll have to manually extend the table to ensure it has enough space for the spilled results.


Answers to some of the other discussions you've initiated also used spilled results, so this shouldn't be too hard to implement. A lookup to find all the dates, another to find all the months, and formulas to build the intersections. You'll just need to make sure the destination tables are large enough.


I'd also recommend flipping your table around. From the looks of it, you expect to extend this table to the right, up to 366 columns by the end of the year.

Tables generally work better when they're taller than they are wide. In other words, having the names across the top and extending the dates downwards. That way you'd have 365 rows for 9 rows (names), rather than 9 rows (names) for 365 columns. Your summary tables can flip this around if you prefer.

2 replies
Question marked as Top-ranking reply

Jan 19, 2026 1:28 PM in response to OlsonBW

Only indirectly, but there are a couple of options.


First would be a pivot table - it looks like Tables 2 and 3 are summarizing the data in Table 1, so it may be a good candidate for a Pivot Table.

Pivot Tables automatically expand to show the relevant data, so adding an additional Date on Table 1 would automatically extend Table 2.


Pivot tables can automatically handle running totals, and dividing out by month (or quarter, or year). Here's a quick Pivot Table I made of some sample data (I added extra data to extend into additional months so show the monthly breakdown):


Because of the potential overhead of the way pivot tables work, they are not dynamic - you'll need to periodically click the refresh button in the Pivot Table sidebar to have it update, but other than that, most of the work will be done for you.


The other possible path would be spilled columns.


Spilled columns (or rows) use formulas that return a range of values rather than a single value. Numbers can then spread (or 'spill') these values into multiple cells.

The only downside is that spilled formulas will throw an error if there's not enough room - for example, a formula that returns 10 columns, but there are only 9 columns on the table - you'll have to manually extend the table to ensure it has enough space for the spilled results.


Answers to some of the other discussions you've initiated also used spilled results, so this shouldn't be too hard to implement. A lookup to find all the dates, another to find all the months, and formulas to build the intersections. You'll just need to make sure the destination tables are large enough.


I'd also recommend flipping your table around. From the looks of it, you expect to extend this table to the right, up to 366 columns by the end of the year.

Tables generally work better when they're taller than they are wide. In other words, having the names across the top and extending the dates downwards. That way you'd have 365 rows for 9 rows (names), rather than 9 rows (names) for 365 columns. Your summary tables can flip this around if you prefer.

Jan 19, 2026 3:13 PM in response to Camelot

The reason I don't want to go with pivot tables is that there are different people working on different aspects of their data. The samples that I'm showing you have nothing to do with the actual data but is close enough is an extremely simple way for me to show you a sample of what I'm trying to do for them. I then give them READ_ONLY rights to the file.


But since they will each be looking at different aspects of the data it is easier to have totally separate tables for each person or group that is working on a separate part of the data.


I will convert my horizontal tables to vertical ones. I will run out of columns far before I would run out of rows. I've been thinking about that already.


But I was hoping that there was a way that I haven't been able to find myself that could add new rows to a table without having to manually add them which I'm doing now. And since there are about 50 different tables I have 49 different tables that I have to add a new column or row (in the near future just new rows).


Back in the '80s with Lotus 1-2-3 I could do so much more than what I can do with Numbers. I've thought about switching to Libré Office but it is so different than any other spreadsheet that I've used before that I would have to start from scratching learning everything which I'm trying to avoid due to time limitations.


As always, I appreciate your help. I've learned a lot because of you and to a lesser extent Badunit.

Numbers: Auto-add rows/columns to multiple tables

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