Generate PDF Package & Export Files as ZIP 

Summary

Generate PDF Package lets a Super Admin turn selected final submissions into PDF packages in one request. The request runs in the background, not instantly. The Super Admin gets a summary email (and an in-system notification) when it finishes, listing anything that went wrong.

Who can use it

Only Super Admin users can see and use Generate PDF Package (this will be coming to admins in the future).

The summary email always goes to the email address on the Super Admin account that clicked the button. No one else gets a copy. Our Super Admin accounts use email addresses we can't open, so the system will read the Super Admin who requested it and send it to that Super Admins proper email address.

How to request a PDF package

1. Sign in as a Super Admin.
2. Go to the list of submissions and select the submissions you want to include.
3. Click More Actions, then Admin Action, then Generate PDF Package. 
   Note: you will still see the old Generate PDF option. Please make sure you use the new one. 
4. A notification appears saying the packages should be ready within about one hour. You can leave the page; nothing else needs to stay open.
5. When processing ends, you get a summary email and an in-system notification.
6. Download the finished packages from the Download PDFs section.

What happens behind the scenes

Requests do not run the moment the button is clicked. They wait in a shared queue and are picked up in cycles.

1. Queue. The selected records are added to the PDF generation queue.
2. Snapshot. A background process on the server runs all the time. On each cycle it takes a snapshot of every queued request across all client databases and processes them together as one job.
3. New requests wait. Anything queued while a job is running is not added to that job. It waits for the next cycle. This keeps new requests from disrupting the job in progress.
4. One file at a time can fail. If one PDF hits an error, only that file is skipped. The rest keep going.
5. Summary. When the job ends, the requester gets the summary email and an in-system notification.

What this means for timing:

• "About one hour" is an estimate, not a promise. The queue is shared by all clients, so a busy cycle or a request that just missed a cycle can take longer.
• Large requests take longer than small ones.
• Clicking the button again does not speed things up. It adds a second request to the queue and the client will get a second set of packages and a second email.

The summary email

The email sorts every package into one of three results. Knowing the difference is the most important thing for answering client questions.

The subject line shows the counts. Counts of zero are left out of the subject, but the email body always shows all three numbers.

In every case except "all completed," the email includes an issue table (next section).

Reading the issue table

The table groups submissions by problem, not by submission. Each row is one type of issue and the IDs it affected.

• Rows are sorted with the issue that affected the most submissions first.
• Each row lists up to 10 application IDs, then "and N more." The email does not show the full list past 10.
• An application appears only once per issue, even if it hit that issue several times (for example, three broken attachments).
• One application can appear in more than one row if it had different problems.

Because of the 10-ID limit, a client with a long row (for example, "12: #15901 … and 2 more") cannot see every affected ID from the email alone. If they need the full list, escalate it.

Example PDF package emails

These are the five versions of the summary email a Super Admin can receive. {Award Name} is replaced with the real award name.

1. All completed

With only one package, the body says "The package is ready" instead.

2. Some completed with issues, none failed

3. Some failed, none with issues

4. Mixed: completed, with issues and failed

5. All failed

Issue Messages and What To Do

Issues that start with "Attachment not included" or "Image missing" mean the package was still saved. Issues that start with "Package not created" mean it failed and was not saved.

The causes above are our best reading of each message. Confirm with engineering before giving a client a definite reason.

Export Files as ZIP emails

Export Files as ZIP is a separate action that bundles submission files into one ZIP. Its emails look different from the PDF package emails and work differently.

How to export files as a ZIP

1. Sign in as a Super Admin.
2. Go to the list of submissions and select the submissions you want to include.
3. Click More Actions, then Admin Action, then Download as ZIP.
4. When the ZIP is ready, you get an email with a Download button.
5. Click the button while signed in to the platform. Download it within 4 hours, before the file is deleted.

Key things to know:

• The ZIP is deleted 4 hours after it was created. After that, the link stops working and the client must request it again. This is the most common reason a ZIP link "doesn't work."
• The client must be signed in to the platform to download it. A link forwarded to someone without an account will not work.
• Unlike the PDF email, the ZIP problem table has one row per submission. Several problems for one submission share a cell.
• The table lists up to 50 submissions. If more than 50 had problems, it ends with "and N more submission(s) with issues."
• If the ZIP file itself could not be saved (for example, the server disk is full), the email says "The ZIP file could not be written" with a reason. Escalate this.

Example ZIP emails

1. Every submission added

2. ZIP created, some submissions had problems

3. Nothing could be added, so no ZIP was created

If the ZIP file itself could not be saved, the second sentence reads "The ZIP file could not be written: <reason>." instead.

What it does not do

• It is not instant. Packages are built in background cycles. There is no progress bar or way to see where a request is in the queue.
• It cannot be sped up or cancelled by the client. Clicking again creates a duplicate request.
• Failed packages are not saved. There is no partial file to download. The client must fix the cause and request those IDs again.
• It does not fix files. Missing, empty or unconvertible attachments are skipped, not repaired.
• It does not retry on its own. A failed package stays failed until someone requests it again.
• It is Super Admin only. There is no setting to give this to other admin roles.
• The email does not always list every affected ID. PDF emails cap each issue row at 10 IDs; ZIP emails cap the table at 50 submissions.
• ZIP files do not last. They are deleted after 4 hours.

Common client questions

When to escalate to engineering

Escalate when any of these happen:

• All packages in a request failed.
• The email shows "database connection problem" or "The ZIP file could not be written."
• "Unexpected error" happens again after one retry.
• "File not found" affects many applications in the same award.
• No email or notification arrives after several hours, and it is not in spam.
• The client needs the full list of IDs behind "and N more."

Include in the ticket:

• Client site and award name
• Who requested it (the Super Admin's email) and roughly when
• The email subject line, plus a screenshot or copy of the issue table
• The application or submission IDs affected
• What the client has already tried (for example, a second request)