Embedded Files
Dealing with multiple service requests can overwhelm even the most efficient report writers. To tackle this, I developed an AI-powered custom report generation system using Make. The video above demonstrates how it automates this tedious workflow, instantly producing a customised overview or comparative report based on data from an authenticated user.
Overview
The automation begins with a smart form, which collects keywords about the report from the user and sends the data via a dynamic query string to my webhook scenario in Make, where it undergoes an initial validation check. If the data passes the check, the user is prompted to sign in to confirm they are permitted to use the system. If the user provides a username and password combination that is on the webhook scenario's whitelist, the automation runs a more thorough validation check on the user's report data, based on the AI assistant's requirements.
If the data passes this final check, the AI assistant writes the report and sends it to an application that turns it into a file with a customised name and appearance. This application also saves the file to the cloud and sends its URL to another application that immediately opens the file for the user to review and download. Depending on the user's Internet speed, it takes within 10 seconds following a successful authentication for the finished report to be displayed on the screen.
In the event that the AI's server experiences downtime, the user's request will not be immediately terminated: the automation will simply execute a directive that causes the AI assistant to make an attempt to complete the report every minute for up to three times. This allows sufficient time for the AI's server to be restored so that the user's request will be fulfilled in the current browsing session. This automation supports parallel processing, which means that it can fulfil multiple service requests simultaneously.
Details
My automation can be described in five major steps and these form the basis for this section's structure.
Step 1: Data Collection and Initial Validation
The Request Form
Each form field is required: an item is not allowed to be entirely a space or an empty string. If the user's entry contains more than one leading or trailing space, the webhook scenario rejects the payload (request) and displays a validation error message. This is due to the webhook's strict data structure, which is a safety feature I implemented to protect the scenario from potentially malicious payloads, particularly those arising from query string manipulation. These are some examples of query string manipulation and how my automation responds to them:
Example 1
1. When prompted for authentication after submitting the form, click on the address bar of that page to inspect the URL.
2. Locate the text "item1" and carefully change it to another word, e.g., "company".
3. Press the "enter" key to run the URL.
Result: the webhook scenario returns a validation error notice like this one.
Example 2
1. When prompted for authentication after submitting the form, click on the address bar of that page to inspect the URL.
2. Locate the text "?item1=" and "&item2=".
3. Delete the entire string between them and replace it with a gap (at least one space). For example, ?item1=Apple&item2= becomes ?item1= &item2=
4. Press the "enter" key to run the URL.
ℹ️ This particular example demonstrates how to bypass the form's built-in validation check on a user's input by manipulating the query string. However, I implemented mechanisms to validate payloads independently of the form.
Result: the webhook scenario returns this web page prohibiting the user's request.
Step 2: User Authentication
To safeguard the system from abuse, users are prompted to enter a valid username and password on their very first request; this security mechanism is called "basic authentication". I chose not to implement more sophisticated ones like Pretty Good Privacy (PGP) or Advanced Encryption Standard (AES) because this automation does not deal with sensitive data.
Users who provide valid credentials are granted access, while those who provide unknown credentials trigger this web page, which is a customised 401 (Unauthorized) error response from the webhook notifying the user that the login details they provided are invalid. I used prompt engineering techniques with ChatGPT to create the HTML and CSS.
Users who decline the system's request for authentication by clicking the "Cancel" button trigger this web page, which is a customised 401 (Unauthorized) error response from the webhook asking the user to confirm their cancellation request. I used prompt engineering techniques with ChatGPT to create the HTML and CSS.
ℹ️ The system remembers each user, thus preventing repeated authentication prompts. This is achieved through a unique session ID, which the webhook scenario generates and sends to the user's browser as a cookie. Therefore, users are prompted for authentication only once in each browsing session. Closing the browser clears the cookie and terminates the session.
Step 3: Final Data Validation
This step represents intricate validation checks a report writer might perform on a client's submitted data before proceeding to write the report. For example, the writer might have predefined criteria that exclude requests involving certain topics or expressions.
To simulate a requirement like this, I designed this automation not to generate a report if the user submits data containing emoji. Authenticated users who submit data that pass initial validation but contain emoji trigger the 403 (Forbidden) error message from the webhook. This is displayed as a web page—the same one depicted in example 2 of step 1 above—that prohibits the user's request. I created the HTML and CSS for this page using prompt engineering techniques with ChatGPT.
Step 4: Report Writing
I configured Gemini (an AI assistant from Google) using prompt engineering techniques to write reports in a specific way and based on the user's form entries. The automation contains three Gemini modules, each with a unique prompt. The number of items the user sends to the system determines the Gemini module—and thus the prompt—that will handle the request. The outcome will either be an overview report of one item, a comparative report of two items or a comparative report of three items.
Whenever Gemini encounters a situation that prevents it from completing its report (e.g., a rate-limit error or a server error), the Break directive will automatically be triggered. This is an error handler that brings the archived report back to Gemini for completion. I designed this process to happen once every minute for up to three times. If the situation is a server error that Google resolves within three minutes, Gemini would be able to deliver the report in the same browsing session.
Step 5: Report Display
Gemini sends each write-up to a Google Docs module, which I configured to do the following:
1. Create a blank document and save it to the cloud.
2. Give the file a name that incorporates the user's submitted keywords and ends with the first five characters of the scenario's execution ID. For example, if the user submitted "Apple" as the first item and "Microsoft" as the second item, and if the scenario's execution ID has "9f575" as its first five characters, the filename would be "AI Report Apple_Microsoft_9f575".
ℹ️ An execution ID is a unique identifier that the system automatically generates for each request the user makes. I incorporated this variable in the file-naming convention to keep each filename unique. Therefore, if the user resubmits the same keywords, the resulting filename will not have the default prefix "Copy of ".
3. Insert the current date at the top-left corner of the document and with a normal, black, 12px Arial font.
4. Generate a title for the report that incorporates the user's submitted keywords.
5. Insert the report's title two lines below the date on the document, aligned to the centre and with a bold, black, 14px Arial font.
6. Place Gemini's write-up two lines below the report's title on the document, justified and with a normal, black, 12px Arial font.
7. Insert a page number at the footer of the document, aligned to the right and with a normal, black, 10px Arial font.
A Report by Gemini
Once Gemini's report has been transformed to a Google Docs file in the format specified above, the Webhook Response module automatically opens it in the user's browser via 303 redirect. The user could then send the document to a printer or download it in .docx, .pdf, .txt, .rtf and other file formats without signing in to Google.
Demo
Use the button below to see my automation in action. Enter either of these login credentials—they are case-sensitive:
Username = test
Password = 123456
Username = demo
Password = abc123
ℹ️ The automation will not request or collect your personal information at any point.
You could request a report comparing "coffee" and "tea"; get an overview of what "swimming in the ocean" entails; find out how Gemini compares your top three holiday destinations; etc. Feel free to input emojis and extra spaces on the form; resubmit the same keywords to observe the filename; enter incorrect login details during authentication; cancel the authentication request entirely; or perhaps even try the query string manipulation examples I described in step 1 above. Your feedback on my AI workflow automation, prompt engineering, and user experience design skills would be invaluable.
Google Sites
Report abuse