Workflow executes before saving linked records

I have a tables called “Labour” and “Materials”.
Each of them has a column named [Day Sheet Id] which is a REF to table DaySheets with Is a part of? ticked.
When my users create a new Day Sheet they enter the top level details then use the system generated New button to add Labour and Materials.
These display clearly on the Day Sheet View.

I have created a Workflow Rule that generates and emails a PDF when they Save the Day Sheet record - the Day Sheet PDF should include a list of the related Labour and Material records .
Unfortunately, at that point, the PDF generates without displaying the related records, but if I later go back and reprint the PDF, those records are included.

What am I doing wrong and what do I need to do to make sure that my workflow saves the related IsPartOf records before it generates the PDF?

Hi @Griff
Maybe you wish to take a look at the topic " Sending Email Only After Adding a Parent Record and All of Its Children" in the article below

2 Likes

Thanks Suvrutt, I thought that an IsPartOf record was handled simultaneously. I will have to implement this seemingly convoluted mechanism. Thanks again

1 Like

That’s a curious assumption.

Yes, as a newbie I sometimes read into things what isn’t really there.

My assumption came from References Between Tables | AppSheet Help Center where it says “A form comprised of multiple rows should be treated as a single update.” I assumed that AppSheet would likewise trieat multiple rows as a single update and thereby complete the updates as if they were a single update (simultaneously). Oops. I now realise that’s an instruction to the user who SHOULD treat or view it as a single update, it’s not saying that AppSheet will do so. I’m still learning and there’s a lot to read, learn and remember. The good news is that the reference Suvrutt provided gave me a clear explanation and a working solution. Thanks again!

Expressing Ownership Between Tables

References can indicate not only that two tables are related, but that rows of one table should be owned by (or considered a part of) rows from another table. …
There are several implications of enabling this ownership relationship:

  1. A form comprised of multiple rows should be treated as a single update.
2 Likes

I’ve been working with AppSheet for four years an learn new things every day. :slight_smile: :frowning: (not sure which is most appropriate)

2 Likes

I came across this ‘limitation’ as well and had to rethink my approach for my workflow. Don’t know if it is possible in your case, but I ended up making a slice for all newly created records for the specific day and then run the workflow daily at around 9pm, well after the close of business. This works for my specific use case but not sure if it would for you.
The solution that was proposed by @Suvrutt_Gurjar is valid however it also was too convoluted for me especially since it requires additional columns which was hard for me to implement since my data is housed in a SQL database and I am unwilling to create extra columns in the DB just to handle workflows.

2 Likes

Hi Markus,

Thanks for the suggestion. That approach will work for some of the scenarios I need to develop. The one Suvrutt suggested is all I need for this one. However I agree that adding columns just to handle workfloows is not something I particularly like but it seems to be necessary with Appsheet.

Yeah I have come across the ‘extra column needed’ to allow a certain functionality too many times. Having some knowledge of programming myself I keep scratching my head why they didn’t include the option of passing additional variables in an action or workflow. Just like executing a loop function I have it parsed down to only needing 3 actions but that is still 2 too many.

1 Like

Appsheet keeps improving. Maybe down the track they may provide the ability to pass parameters with a call.

1 Like