Print Diagnostics Behaviors

The Print Diagnostics (SAC::PRINT-DX) area covers API-level capabilities for inspecting and troubleshooting print operations. These behaviors are exercised by the Customer Support persona through direct API calls (via Coda dashboards, Postman, or curl) — they do not have a dedicated frontend UI.

Feature reference: Print Diagnostics

---

SAC::PRINT-DX::0001 — Inspect Print Payload

The Customer Support Specialist investigates a print issue by inspecting the payload that the system constructs for Documint, without necessarily triggering a production render. Three diagnostic parameters — dry-run, debug, and live-print — can be combined on any print endpoint to control what the system does and what it returns.

Persona	Charlie Supportson (Customer Support Specialist)
Depends	SAC::PRINT::0001
Status	New

SAC::PRINT-DX::0001::0001.UC — Dry-Run Print Request

Charlie calls a print endpoint with ?dry-run=true for a specific item or card. The system resolves the template, constructs the full Documint payload (field mapping, grid layout), and returns the payload in the API response without calling the Documint API. No PDF is generated, no print status is updated, and no side effects occur.

Charlie uses the returned payload to verify that the correct template is resolved, the field values match the item data, and the notes mapping is correct — all without consuming Documint quota or producing a physical print artifact.

Precondition: Charlie has API access to the customer’s tenant.

Postcondition: The API response contains the constructed Documint payload (template ID, template configuration, grid JSON). No Documint call is made. No state changes occur.

SAC::PRINT-DX::0001::0002.UC — Debug Production Print

Charlie calls a print endpoint with ?debug=true (without dry-run). The system executes the full print workflow — template resolution, payload construction, Documint API call — and returns the normal result (PDF URL or error) plus the constructed Documint payload in the response.

Charlie compares the payload against the customer’s item data to identify field mapping issues. If the print failed, the payload that caused the failure is still available for inspection.

Precondition: Charlie has API access to the customer’s tenant.

Postcondition: The API response contains both the normal print result (PDF URL or error) and the Documint payload. The print executes normally — print status is updated for cards, and the Documint call counts against quota.

SAC::PRINT-DX::0001::0003.UC — Test Print with Watermark

Charlie calls a print endpoint with ?live-print=false. The system executes the full print workflow but tells Documint to treat it as a test render. The resulting PDF contains a watermark overlay and does not count against the service quota.

Charlie uses this to produce a visual proof of the printed output without consuming production quota — useful for verifying template layout, data placement, and overall print appearance before asking the customer to reprint.

Precondition: Charlie has API access to the customer’s tenant.

Postcondition: A watermarked PDF is generated and returned. The Documint quota is not affected. Print status updates proceed normally (the system does not distinguish test prints from production prints for status tracking purposes).

SAC::PRINT-DX::0001::0004.FS — Combined Diagnostic Parameters

Charlie calls a print endpoint with multiple diagnostic parameters combined (e.g., ?live-print=false&debug=true). The system applies all parameters:

• dry-run=true takes precedence: no Documint call, payload returned, live-print and debug are ignored.
• debug=true + live-print=false: test print with watermark + payload in response.
• debug=true + live-print=true: production print + payload in response.

Postcondition: The system behavior matches the parameter combination table defined in the Print Diagnostics feature.

---

Summary

Use Case	Scenarios	US	UC	FS
SAC::PRINT-DX::0001 Inspect Print Payload	4	0	3	1
Total	4	0	3	1

---