Perform action on selected rows

Looking for some help on this topic.
I need to be able to select a number of rows and then perform an action to create a pdf.
The rows will be different every time so I cannot filter them in the template.
Is this possible? Users are taking screen shots at the moment which is not ideal. The fault description is a long text field so screenshot will not capture the full fault.

If you need to have these records in the same PDF you could create a separate form where your users can select records to be added. Then you can use that record for filtering the Start: & End in the template.

1 Like

Not sure I understand how that would work. Is the feature to apply an action to selected rows something that is being looked at?

Using multi-select, you can apply an action to each of the selected rows individually, but you cannot apply an action to all of the selected rows at once.

@Aleksi’s suggestion is a good one.

thanks, it would be really, really useful to be able to apply an action to selected rows. Its difficult to apply individually if you have lots of rows. Really need this feature also so I can select all rows and reset the value of a column to zero after email with pdf is sent.

What you are asking CAN be done with AppSheet currently. Just not directly as in “select these rows and then create a PDF from them right now”.

Selection is nothing more than an indicator that the row is selected. You can do this by adding a column named, say, “Selected?”

Then there are two things that need to be worked out

  1. How are the rows marked selected? By user, by some data change or both.
  2. When does the PDF get created? Automatically or by user request? If automatically, then how does the system decide its time to generate the PDF?

Once you have this worked out then it is just a matter of the PDF template getting the list of rows that are marked “Selected?” and producing the report.

There are details that need to be considered but your specific use case will help guide those details.

There is a challenge with this method if two or more users are requesting the pdf at the same time. That’s why I didn’t propose it.

Oh right @Aleksi, I see what you mean. So if user A select rows 1 and 3 that they want to pdf but if User 2 selects rows 2 and 4 before user A hits the action button then all 4 rows will be on pdf.

I had another similar issue. I have a table of products (thousands of products). We have a construction site with several Blocks, A,B,C… I created a table with columns Product, Quantity. I want each block manager to enter the quantity of each product that he needs and then send a pdf. I had to create an App for each Block and give permission to only one user to use. I know I could have put into one App and give permissions to logged in user to each table. Issue is that Block A manager who has exclusive use of his table, may put quantities against a lot of products on Floor 1. Once pdf is sent he needs to reset each row to zero individually so it he is ready to start again for Floor 2- done at a later date. Not sure what the solution is to this.


It sounds like you may be describing what is essentially an order entry system.
If so, this is typically implemented by creating an Order record that represents the Order and OrderDetail child records for each product in the Order.

The Order record contains:

  1. An OrderId field containing a UNIQUEID to identify the Order record.
  2. An OrderDate field indicating when the Order was created.
  3. A Ref field to the “Customer” or in your case the Block Manager.
  4. An OrderStatus enum field to track the status of the order.

Each OrderDetail record contains:

  1. An OrderDetailId field containing a UNIQUEID to identify the OrderDetail record.
  2. A Ref to the parent Order record.
  3. A Ref to the Product record being ordered.
  4. A Qty reflecting the quantity of the product being ordered.

The virtue of such a design are many.

  1. It is a well known pattern that is proven to work.
  2. It provides a permanent record of all Orders.
  3. It makes it possible to “track” the status of each order by updating the “Status” field in the Order record.
  4. There are no concurrency problems because every Order is independent.
  5. Your PDF reports can extract data from the Order, OrderDetail, Product, and BlockManager records that are linked to the Order via Ref fields.

Hi Philip,

I have actually created an ordering system. Our system is pretty complicated. The Block manages Pdf’s will feed into the Ordering system once approved. We do bulk ordering of items and draw off from that order as and when needed so items are not sitting on
site before they are needed taking up space or get lost or stolen. A simple example would be if we had 300 apartments, we would place an order with a supplier for 300 baths, 300 toilets and 300 sinks. 10 of each may be needed each week. The ordering system
has to deal with the draw offs and deliveries to site.

We use the Block managers pdf’s for more complicated products such as lengths of pipe or high spec items.


Martina Hawkins

Business Systems Manager

**Kind Regards


@Aleksi @Steve @Phil

@Martina I apologize if I added confusion. I was not trying to contradict any other comments. I was reacting to your statement and trying to point out that AppSheet has great flexibility to create your own solution IF what was suggested or currently provided in AppSheet is not sufficient.

To back up to your original post, if your goal is to simply allow a user to select a set of rows and produce a PDF report from them, then @Aleksi initial solution is perfect!!

However, you added later in the thread that you also wanted to “reset the value of the column to zero” after the PDF is sent. If by business process, two users would NEVER overlap their row selections, then @Aleksi solution is STILL the perfect choice AND you can include that automatic reset of the rows in the Workflow.

BUT…if two users COULD select the same row, the implication is that you either need to:

  1. have the row available for ALL PDF reports being created at that time (i.e. no reset)
  2. you only allow that row on a single report.

What I posted was a general idea responding to this implication and then made the statement below to acknowledge that you’ll need to adjust for your specific circumstances.

For example, you mentioned the problem with two users trying to report at the same time. You can combat that by not only having a “Selected?” column but also a “Who Selected” column. The benefit being that the row can only be selected by one user at a time. Last one to select wins and gets the row on their report!

The assumption always being that a row reset is performed after the report (or reports) have completed.

Bottom line, AppSheet is flexible enough that there is ALMOST ALWAYS a way to create your own custom solution to resolve an issue.

At the end of the day, the job of us developers is to save the users time and headaches with software improvements and sometimes we have to get creative to overcome obstacles!!

If you still need help with resolving your issue, please don’t hesitate to continue posting your queries

Good Luck!

1 Like