Gravity PDF generates PDF documents from Gravity Forms entries and attaches them to notifications or saves them for download. Each entry can carry multiple PDFs, one per template, with status tracked in gf_entry_meta under keys like gpdf_status_{template_id}. Typical states are pending, generated, sent, and failed, with the last error stored in a sibling meta key.

SleekView Kanban reads gf_entry joined with the Gravity PDF meta and groups by the rendering status. Each card shows the form name, the PDF template, the recipient when the PDF is tied to a notification, the file size when generated, and the last error message when failed. The board makes the rendering pipeline visible in a way the standard PDF settings screen never does.

Dragging a card from Failed back into Pending calls Gravity PDF's re-render method, which queues a fresh attempt and writes a new status. A move to Sent triggers the notification dispatcher if it was held. The plugin keeps owning rendering and delivery. The board owns the visibility ops needs when invoices, certificates, or contracts are not arriving in customer inboxes.

Gravity PDF turns Gravity Forms entries into real documents: invoices, certificates, contracts, receipts. The render itself is reliable when it runs, but anything can break the chain: a missing logo asset, a font that did not embed, a notification step that never fired. The default Gravity PDF interface is built for configuring templates, not for monitoring the pipeline.

Ops teams find out about a stuck render when a customer asks where their invoice is. SleekView Kanban makes the pipeline visible. The status meta Gravity PDF already writes becomes columns, the template and recipient become card content, and failed renders surface with the actual error message on the card.

A drag from Failed back to Pending triggers Gravity PDF's own re-render path, so ops fix the underlying issue once and recover the queue without opening every entry. The plugin keeps owning rendering. SleekView Kanban owns the visibility.