Delete a Saved NDT Draft While Keeping Open Work

An unwanted draft can be a duplicate trial, an abandoned preparation or a saved copy that should not continue through review. Those situations differ from a report that merely needs a corrected title or an additional observation. Before deleting, state why the saved record is no longer needed and whether any part of its content must remain available. If the existing tracked identity is still useful, editing the draft may be the simpler and clearer action.

Do not use deletion to conceal an unresolved technical issue or to make an inconvenient record disappear from a project's history. Follow the retention and document-control arrangements that apply to the work. The software offers deletion for saved drafts, but that capability does not decide which records your organization should retain. Resolve the record decision first, then use the application to carry it out accurately.

The saved library and the editor are related but separate views. A library row describes a retained version, while the workspace can contain additional local changes that have not been saved. Compare the report number, revision, title, client and status before choosing Delete draft. If several rows have similar titles, do not rely on position in the list or on a remembered search result from an earlier session.

Also identify which report is currently open. Deleting a different draft from the library does not make that row the active workspace. If you intend to preserve content from the draft you are deleting, first ensure that you actually have that content open or retained in an appropriate backup. A visible title in the list is not an editable copy of its tables, notes and client fields.

If the report belongs to another account, stop and resolve authorized access rather than using a similarly named local copy as evidence of ownership. Deleting your own draft does not remove a separate record held by another owner, even when the company and client fields are identical.

The digital NDT reporting tool displays Delete draft only for saved drafts. Issued versions are preserved and use the draft-revision workflow when supported changes are needed. Do not interpret the absence of a delete button as a reason to restore an issued backup under a new identity and pretend the original no longer exists. The issued history and any delivered copies remain separate records.

A draft status does not mean the content is disposable. It may contain unique examination notes, an important review disposition or work that has not yet been captured elsewhere. Review the record's purpose and evidence before removing it. Conversely, an issued status is a document state rather than independent technical approval. Neither label replaces the user's responsibility to determine the appropriate record action for the project.

If any part of the current workspace is worth retaining, download an editable backup before confirming deletion. Check that the download completed and that you can distinguish it from older copies. A draft PDF can provide a readable reference, but it is not the same as an editable recovery file. Choose both outputs when your intended recovery requires editable tables and a visual comparison of the report's current appearance.

CISA's backup and recovery guidance recommends testing recovery from backups. For this deletion workflow, the useful lesson is to establish that your intended retained content exists somewhere other than the soon-to-be-removed library record. Do not postpone that check until after the browser tab is closed. A local workspace can remain visible after deletion without becoming a durable saved copy.

Selecting Delete draft opens an explicit confirmation naming the report number and revision. Read those details against your deletion decision. The confirmation is the point to catch a similar title, a different revision or a row that moved after a refreshed search. If anything is uncertain, cancel and inspect the record. Cancelling leaves the saved draft in place and lets you resolve the uncertainty before taking the action.

While a confirmation is pending, complete or cancel it before attempting other workspace changes. Treat the dialog as one focused decision rather than a background task while you edit results. This reduces the chance of believing that a new change has been included in a backup made earlier. If your intention changes during the pause, cancel, preserve the updated content and start the deletion check again.

When the deleted saved draft is the report currently open, the editor keeps its content in the workspace but clears the connection to the deleted saved identity. The remaining copy is marked as unsaved work. This allows you to continue using the content deliberately, but it does not undo the deletion or keep the former report number reserved for that workspace. Read the new state before making the next decision.

The distinction matters when you are removing a trial record but want to reuse a table layout or corrected narrative. You can inspect and edit the remaining local content, then save it as a new tracked report when ready. If you close or refresh without a new save or usable backup, the visible open copy should not be assumed recoverable. The application does not provide automatic browser-tab persistence for that unsaved state.

A first save of the remaining unsaved workspace creates a new record and assigns a new report number from the account's sequence. The deleted number is not reused. Do not promise a client or coworker that the next record will keep the old identifier simply because the text and tables look the same. Confirm the new number after saving and update any external references that were intentionally tied to the replacement.

Gaps in the account sequence can therefore reflect deleted drafts or other allocation events. Do not alter inspection dates, method names or numbering patterns merely to disguise a gap. The number identifies a saved record; it is not a count of accepted inspections or evidence that every allocated number remains in the library. Keep the administrative explanation where your record process needs it without changing the factual report content.

An editable backup restores report content as a new unsaved draft. It does not recreate the deleted library record with its former identifier, revision history or status. This is useful when you decide to recover content later, but it should be described accurately. A restored copy can become a new report after review and saving; it is not a reversal that makes the deletion disappear from the sequence of decisions.

Before restoring, preserve any different unsaved work already in the editor. Restoration replaces the active workspace after confirmation. Check the backup's client, project, method, tables and narrative against the content you intended to recover, then review the numbering pattern and inspection date before its first save. A familiar file name does not prove that the backup contains the final changes you made before deletion.

Consider a fictional inspector who saves a practice report while testing an imported worksheet. The saved draft contains invented client data and a useful table arrangement. After confirming that the practice record should be removed, the inspector opens it, downloads an editable backup and checks the Delete draft confirmation against the practice number. Deletion removes that saved row while the current table and fields remain in the open workspace.

The inspector now chooses to prepare a different practice exercise. They replace the fictional client and scope, review every reused row and save the result. It receives a new number, and the previous number is not reused. This example demonstrates the software transition only. Reusing a table arrangement does not justify carrying real observations, qualifications or acceptance statements into a different inspection without the actual supporting evidence.

Deletion uses the version shown in the library so that a stale view does not silently remove a record changed since it was loaded. If the application reports a conflict, preserve your current workspace and refresh the saved-library view deliberately. Inspect the latest draft before deciding whether it is still the record you intended to remove. A new change may contain work that was not part of your original deletion decision.

Do not treat the conflict as an obstacle to bypass by repeating the same action rapidly. It is evidence that the state you reviewed no longer matches the current saved state. Compare the relevant changes, confirm the owner and purpose of the record, then make a fresh decision using the current information. If another tab is editing that draft, stop using competing editing sessions while you resolve which copy should be retained.

A deletion can succeed even when a subsequent library refresh is interrupted. The interface can report that the saved draft was removed while preserving the open workspace and asking you to search again. Read the message carefully instead of assuming that every network error means the deletion failed. Keep the local backup and use a fresh search when the connection is available to confirm the saved row's state.

Pagination can also change after removal. The application adjusts the visible page when the last entry on a page disappears, so a different set of rows may appear after a successful deletion. Check the number rather than expecting the list to retain the same visual arrangement. If the result is still ambiguous, pause before creating replacements or deleting another similarly named draft. Establish the retained content and the saved-library state separately.

The account limit applies to saved report versions, including drafts and issued revisions. Removing genuinely unwanted drafts can free saved-record capacity, but the need for space does not determine which records are safe to remove. Start with clearly identified test or abandoned drafts and review their purpose. Do not mass-delete similar titles on the assumption that only the latest-looking row matters; different revisions can represent different document decisions.

The current interface provides individual draft deletion with confirmation, not an automatic retention policy or bulk cleanup system. Plan a small review session in which each decision is understandable. Keep any required external record of discarded trials or replaced preparation. If capacity is dominated by issued versions, the draft deletion action is not a path to remove that issued history. Consider your record workflow rather than trying to transform issued records into disposable drafts.

Deleting a saved draft does not remove PDFs or editable backups already downloaded to a device. It also does not retract files sent through email, copied to a project repository or delivered through another approved channel. If a discarded draft was distributed, address those copies through the process used to distribute them. Identify the correct replacement or withdrawal message rather than assuming a library action updates every recipient's files.

Handle retained backups as report data. The file may include contact details, logos and observations even if its extension looks less familiar than a PDF. Decide which copies remain necessary, who may access them and where they should be kept under your established arrangements. Avoid describing application deletion as comprehensive data erasure or a legal retention decision. It removes the selected saved draft record from this workflow, with the separate copies requiring their own management.

If you continue from the local copy after deletion, review more than the title and client name. Check the inspection date, location, procedure references, acceptance statement, personnel, equipment and every result row. Reused content can carry a plausible but incorrect reference from the former draft. A clean table layout is useful; inherited facts should be retained only when they genuinely belong to the new report and are supported by its evidence.

Pay particular attention to conclusions and limitations. A conclusion copied from a previous preparation can sound complete while describing a different scope. Reset or rewrite those sections based on the actual new work. The same applies to logos: their presence is a document identity choice, not proof that a company reviewed or endorsed the replacement. Save only after the new document has been reconciled with its intended purpose.

At the end of the workflow, identify which of three outcomes you intended: no retained content, a private editable backup for later use, or a newly saved replacement record. Confirm that outcome directly. If a replacement was saved, check its new identity and retrieve it from the library. If only a backup remains, locate the file and make clear that it is not a current issued report. If nothing should remain in active use, follow through on the separate copies you control.

Use the worksheet to keep the deletion decision proportionate and repeatable. It should explain which draft was removed, why removal was appropriate, what content was preserved and what identity now applies. This makes cleanup a deliberate record-management action rather than an attempt to tidy a list without understanding its contents. The useful result is fewer unwanted saved drafts and no accidental loss or misidentification of the work that still matters.