Add multiple rows to another table

Hi, I am creating a list of collections with 3 statuses, “open”, “pending” and “closed” in a table. I want to select multiple items from my “open collection”, send them, and move those “open collections” to the next status “pending collection” (all show on the same page) In the backend, there is another table “pending table” for these “pending collections”. My problem is:

I have created a button and made the action “add row”, I use “checklist” for all these collections. Then I selected a few items and sent them. The backend “pending table” could only capture the first collection and created a few rows with the first collection. Can I ask what I need to do to make it right, please?

My question would be why do you want two separate tables?

Seems to me all that would be doing is creating extra work and complexity - as you’re already discovering. Separate tables that hold almost identical data is almost always a very bad idea.

It’s trivial to filter rows on the front end.


The idea is that I want the staff to submit new projects for the management to approve. The pending approval tab will only show to the management. If it’s a “todo” list, I think I should make it one page, but this is about another group of people to approve the project submissions, so I have created a separate table. What would you suggest? In this case, should I make it a separate tables?

No, I would just use one table.

You can have different views of the same table on the front end, and filter by status.

Let me try. But how do I select a few items and send them to the management for approve? If I create a button and the action is “add row”, it will only add the first row of that user’s created. I would like to know what step I have done wrong, please?

If you want to send items for approval, isn’t that just a matter of changing the status of those items?
There should be no need to create additional rows.

Just one thing…

Currently, the only way to update multiple items at once is via the Glide API.
However, you can update them one by one as they are “selected”. As long as you have the items in a collection, you can configure the collection item click action so that it does that.

1 Like

I just watched Loqode’s video about using Glide API to do multiple edits/deletes, but it’s a bit difficult for me. Let me give it a try first, and thanks for your answer, Darren :slight_smile:

You can also use a Kanban component, that might suit your use case for moving items across different states.

1 Like

You are making life very difficult for yourself by sending data across tables. And there’s no good reason to do that. As Darren suggested, leave all the projects in the same table. You have projects, they all belong in the same table, end of story. Now if projects can have a status that changes (open, pending, closed), then create a column for this attribute (open, pending, closed). That’s how you could/should set things up in the backend (Data Editor).

Now in the frontend (Layout Editor), create tabs looking at the same table (Projects) and filter as needed (status, staff-management, etc.). In business terms you are “submitting” projects for approval, but in technical terms nothing is being sent anywhere: button clicks change the value of an attribute (the status for instance) and the filters take care of the rest (display information in certain places).

1 Like

I thought that by using the filter function, the content would also download to the end user’s computer, which would slow down the loading speed, so I thought that it would be better to separate the table for the “pending projects”.

I will try it this way later, thanks for the guidance guys :slight_smile:

Yes, filtering is done on the front end at the users device, so it doesn’t affect how many rows are loaded onto individual devices.

If you want to restrict which or how many rows are loaded, you can use Row Owners. But that could introduce additional complexities that you may not be ready to deal with. The main reason to use Row Owners is if security of the data is a concern. And that doesn’t appear to be an issue in this case.

How many rows in total are we talking about? Unless it’s tens of thousands, I wouldn’t worry about it. And if it is tens of thousands (or more), then you should be considering one of the high scale data sources.

1 Like

Just hundreds of rows, not much data in it. Ok. I will give it a try, thanks, Darren.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.