Hi,
We have 100% testing policy in my company. End of production line we are testing our products which are called End of Line Tests (EOL Tests). We want to share these test results with our costumers as a .pdf document. Is there a custom widget or something for saving my steps in a file as .pdf? @giladl @John
Hi Ozan,
This functionality is built in and you can “print” each step with triggers and save it to pdf. This Knowledge Base article has more details on how to accomplish this How Operators Can Print App Data Or Save it to a PDF
Does this help?
@Beth I have been using the Print Step trigger for some time to generate CofCs, Packing Lists, and other various forms. In some cases, I end up saving them as a PDF as you described and then immediately upload the PDFs back to a File field in a table. This is mostly as I don’t want / can’t regenerate the form again in the future and want to archive it within Tulip in the event we (or our customer) needs it.
I’m sure I could use a connector function with an external paid API to generate PDF forms that can be sent back to Tulip and saved to a table but having a built-in Save Step as PDF to File field in Table action would be incredible.
I’m not sure if this is what @OzanB was thinking but I am!
Hi @Beth
no, because you have to leave the Tulip environment and have to add the PDF file name manually (ok, you can copy a file name with path to the clipboard) but that’s not a smart Tulip-like workaround.
Due to security reasons the stations haven’t access direct access to the shared folder for storing the PDFs.
It also breaks the workflow inside Tulip when using the OS dialog.
Regards Chris
Hi and thank all of you for your feedback,
@Beth, the problem here is, when I embed a .pdf file to the step and fill it from the app itself. It creates a page with pdf controller and this blue margins. When I try to print it it comes with all this margins and pdf controls that I dont want. Now, I created a copycat of my pdf file in the step (which is not .pdf) I am printing this page. However, It would great if we can save this pages in a table as pdf or other document types just like, @doneil mentioned above.
In addition to that, I found the same solution just like @ChrisF mentioned if you want to modify it in pdf I have to leave Tulip environment. I am not a developer I am not good if need to write a script.
Again, Thank you all for your contributions to this topic. Also, sorry for my late response, I was out of office for a week. I guess we need to create a development request for such actions.
Regards
Ozan
Thanks @doneil and @ChrisF for the input and discussion here!
@OzanB - I understand better now the challenge here. I will go ahead and turn this thread into a product suggestion so others in the community can vote on it and our product team has the internal ticket to work on.
It seems the main thing that would help here is a built-in “Save step as PDF” in a table and a way to edit the PDF without having to leave the Tulip environment - does this summarize everything correctly?
Hello,
An additional reason to be able to save each step as PDF is that the information is not correct anymore when printing multiple steps.
An example:
You are executing 10 steps and want to print everything at the end of Step 10.
When printing multiple steps like this, all the step titles will be the same as Step10 (if you display the step name with the text widget - App info - Step name). It is because that information has changed with every step and was overwritten each time. At the time of the printing, only the latest value remains. It breaks the ALCOA principle.
To make it work, you need to save the step name into different variables (one for each step) and display those variables.
Same for the User logged in, …
The only moment the data really respects ALCOA for printing is just before leaving the Step itself.
I would love to see a print to pdf button that prints SILENTLY (without OS window/prompt) and save it in a configured location (Cloud/Table). The PDF generation should come from the server and not the client (access to table/rights for the cloud/…).
KR,
Kevin
@Beth have you received any feedback from the team on this feature request? I’d be interested to understand if this is something they would take on.
Hi Darren,
I don’t have a concrete update, but we are having some more internal conversations around this with the product team. The technical lift to accomplish this is actually a bit heavy, so the priority is scoping this work for our roadmap. I hope to have more updates in the near future!
Since Tulip is using electron under the hood of the client, can’t you “simply” use the webContents.printToPDF command bypass the OS print dialog and get to the file data?
Hi @OzanB @doneil @ChrisF @kefl @sebme -
In Platform Release 313 - April 2025 we just released the ability to capture a screenshot of an app during execution. While this is not a pdf, it does allow you to save the screenshot as a variable, save it to a Table Record, or include it in an email or completion.
I believe this would solve most of the use cases mentioned on this thread, but check it out and let us know!
You can read more about it here: Capture App Screenshot
Sorry,
but a screenshot isn’t a PDF report.
So for us that’s absolutely useless.
Regards
Chris
Hi @ChrisF - I’m sorry that a screenshot feature won’t help you here. I understand this is not exactly the same as producing a PDF, but think it will solve some/many of the other requests on this thread, despite that.
Can you tell us more about your specific needs for a PDF and where the screenshot capability would fall short in meeting these needs?
I will mark this as un-resolved for you 
Thanks!
If you need a quality report of a car, a picture of the manufactured car doesn’t fit 
I don’t like to repeat myself again and again, because the wish for internal PDF creation is as old as I have to use Tulip (4+ years).
So if you really want to bring us the best user experience in Tulip, you need to integrate a PDF generation inside Tulip on the fly without leaving the environment and store the PDF directly inside Tulip into a Table or others.
It’s a security break leaving Tulip to store a PDF somewhere in a file system, what is not allowed for our users (we had to setup a separate station only for this).
Only my 2cents
Chris
Same as ChrisF, a picture is not a pdf and the need to print silently one step as pdf is still there.
I would also add the need to merge several generated pdf (to generate a manufacturing batch record) and even the possibility to add intro/ending pages.
KR,
Kevin
I agree with @ChrisF and @kefl. This new feature of taking a screenshot though helpful for some use cases will not work for me either.
I have tried to convert this image to a PDF using Node Red (but failed) and may try using a connector with an external service but as Chris said that opens up security issues and also complicates the system such that it could fail.
Does anyone have any ideas on a reliable way to convert the image to PDF? It doesn’t seem impossible since its already in Base64 format.
Hi all,
We had a similar requirement from a client in a recent project and my colleague @eden came up with a workaround:
This should allow you to print a PDF with all of the specific steps you need
Hope this helps, let me know if you need any help with the method
Kind regards,
Suraj Patel
Bow and Stern IT professional services
Hi @surajp
that’s the normal way to print a fixed group of steps.
But this fails, if you need a dynamic solution like
Step 1,2,4,6
later
Step 1,2,3,5,8
…
Regards Chris
Hi @ChrisF
Absolutely, this doesn’t work well in cases where you may have a different number or set of steps that need to be printed so I agree that it would be very helpful to be able to have the ability to create PDF’s dynamically and be able to store them within Tulip directly.
Similarly, it would be great to have the ability to encode PDF’s as Base64 natively through Tulip connectors, as is currently possible with images.
Kind regards,
Suraj