Use a PDF Markup Table for RFI and Punch-List Review

PolyPDF can hold visual evidence and a structured register of PDF markups. Rows carry subject, status, page, comments, author, dates, color, layer, workspace, and configured custom columns. Selecting a row reveals its page markup.

That is useful input to an RFI or punch-list process, but it is not the system of record by itself. PolyPDF does not assign a formal RFI number from a project server, route the question to a design professional, attach an official response, enforce contractual due dates, or prove that an issue was issued. Perform those steps in the project platform or procedure your team has approved.

The screenshot includes a callout labeled “RFI 014” as drawing content. That label is an example written by the reviewer, not evidence that an RFI record or attachment exists elsewhere.

A register becomes searchable when subjects are predictable. Put the durable identifier and a short description in Subject, then use Comments for the complete question, observation, or acceptance note. Do not leave the only meaningful description inside a callout graphic.

PolyPDF offers No Status, Open, In Progress, Completed, Accepted, Rejected, and Reviewed. Your project may define those words differently. Document the team's meaning before review begins; for example, Completed may mean the field work is reported complete, while Reviewed means someone independently checked it.

1. Open the correct drawing revision and save a working copy if your document-control procedure requires one.
2. Add a cloud, callout, text, shape, photo stamp, or other markup at the exact issue location. Keep one independently closeable issue per markup or logical group.
3. Set a specific Subject. Put the requested decision, observed condition, dimension, or acceptance criterion in Comments.
4. Open the Markup Table from the footer control, Window > Panels > Markup Table, or the sidebar context menu.
5. Select a row to reveal its associated page markup. Use the Status control in the row to apply the agreed review state.
6. Sort a column by its heading. Use the funnel controls on supported columns to keep only the values relevant to the current review.
7. Review the visible rows against the page, then choose a full-detail export or a filtered summary for the receiving workflow.

The table can also update comments and subjects inline. Multi-selection can support consistent bulk status changes, but scope those changes carefully: a convenient batch edit is not a substitute for verifying each location.

Use the table as a review window, not a second drawing. A superintendent might filter to one page or workspace, an architect might inspect a specific subject family, and a closeout reviewer might focus on rows whose current status still requires action. PolyPDF keeps the visible row connected to the page so the reviewer can inspect geometry and context before changing the state.

• Filter Page when the meeting is reviewing one sheet or area.
• Filter Subject or Comments for a known issue prefix, discipline, room, or tag.
• Filter Author, Layer, or Workspace when responsibility or drawing organization carries the scope.
• Sort Status to group the lifecycle states, then inspect every row before a bulk update.
• Clear filters before final reconciliation so an unresolved row is not omitted merely because it was hidden.

A filtered count is only the visible subset. Summary exports record that scope, but detailed CSV, JSON, and copied-text exports still include every markup. Compare visible and total counts before distributing either output.

The Markup Table export menu offers detailed CSV, summary CSV, summary PDF, JSON, and copied text. Detailed rows include the built-in fields shown in the table and configured custom-column values. The summary formats aggregate the visible scope, which is useful for a meeting record or progress snapshot.

Attach the reviewed PDF or summary to the formal RFI or punch record according to project procedure. If the official platform assigns a different identifier, update the PolyPDF subject or maintain an explicit cross-reference rather than allowing two numbering systems to drift.

• Verify the PDF file name, revision, and sheet identity before adding or closing issues.
• Require a comment that explains why a status changed when the change is not self-evident.
• Distinguish reported completion from independent review in the team's status rules.
• Reopen the saved PDF and inspect representative rows, page links, comments, and appearances.
• Export after filters are intentionally set, and label the export with its scope and date.
• Keep the authoritative RFI, punch, response, approval, and due-date history in the designated project system.

This separation makes the workflow stronger: PolyPDF remains the direct visual review record, while the project system remains the place where contractual communication and closure are controlled.