Add or Replace an Imported NDT Report Table Safely

A new template file can mean several different things. It may introduce an additional examination table, provide a better structure for the same results, or replace an obsolete form. Those intentions should lead to different actions in the reporting workspace. Before opening the import controls, describe the intended change in one sentence. For example, you may want to add a separate table for a second examination area while preserving the first area's entries. Another task may require replacing an empty starter table with a reviewed customer format. The correct action follows that intention, not the fact that a file is newer.

The free digital NDT reporting workspace first reads a supported template and presents candidates for review. Reading the file does not itself replace the current result tables. After selecting a candidate and its header row, the author can add that table or choose to replace the current result tables. That separation gives you an opportunity to inspect what is about to enter the draft. Use it to compare the candidate with the open report and confirm whether the new information is additional, substitutive or still too uncertain to apply.

Look at the report that is already open. Note its title, saved identity if any, revision, current table names and the approximate purpose of each table. Identify where actual observations have been entered and where only blank starter rows remain. Also check whether there are unsaved changes. A saved record can differ from the current workspace, so the fact that a report number appears on screen does not prove that the latest results are safely retained in the account. Understand which content is current before choosing an operation that changes its structure.

Make a short inventory of valuable work outside the tables as well. The client, project, technical references, equipment description, observations and conclusion may depend on the existing table content. Even when a table operation leaves those fields present, their wording may no longer be accurate after the results change. An observation saying all listed items were examined can become misleading if an added table contains unexamined items. Inventorying the draft is therefore more than counting tables. It establishes the relationships that need to be rechecked when you add or replace part of the report.

Download an editable JSON backup before a consequential change when the open draft contains work you need to preserve. A PDF is useful for reading and comparing the current document, but it is not the reporting tool's editable restoration format. Keep the backup in an appropriate location and make its purpose recognizable. If the source and backup contain client information, handle them according to your existing record controls. A casually named file in a shared download folder may create confusion about which project it belongs to and who should have access to its contents.

A backup is useful only if you understand how to use it. CISA's Cyber Essentials backup guidance recommends periodically testing recovery, a general principle that also applies to protecting working documents. Here, restoring a report backup creates a new unsaved draft rather than reconstructing the original tracked identity. Do not use a restoration experiment to overwrite valuable open work. Prepare a separate practice context, retain the original saved record where relevant and verify the restored contents before relying on the file as your only editable checkpoint.

A file called Revised Report Template may contain several worksheets or Word tables. Select the actual candidate that serves the intended report purpose and choose its meaningful header row. Read the preview warnings. Confirm that the columns describe the values below them and that any rows above the selected header contain context you must retain elsewhere. A filename does not establish the correctness of the selected table, and a recent modification date does not show that the client has accepted the template. Use the project evidence that identifies the intended revision and keep unresolved questions visible.

Compare the candidate's structure with the current tables. Does it add a genuinely new type of record, rename existing columns, combine previously separate information or remove a field that the report still needs? If you cannot explain the difference, pause before applying it. Write a source-to-destination mapping for any results that will be transferred manually. Be especially careful when two columns have similar labels but different units or meanings. The add and replace controls operate on table structures; they do not decide that one technical field is equivalent to another.

Adding a result table preserves the existing table collection and appends the reviewed candidate. This is useful when the report needs a distinct additional record set, such as another identified examination area with its own meaningful rows. Give the new table a clear title and ensure readers can tell which scope belongs to it. Do not append a duplicate of the original table merely to avoid deciding which version is correct. Two near-identical grids with different values can create more uncertainty than one unresolved draft, particularly if both appear to describe the same item and examination event.

After addition, inspect the total structure. Confirm that the old table remains unchanged, the new table has the expected headers and rows, and the report's narrative explains their relationship. Check whether common context is genuinely shared or needs to be stated separately. If the tables concern different procedures or conditions, make that difference explicit in the appropriate fields and references. The software does not infer those boundaries from the order of the tables. Addition is a preservation-friendly action, but the resulting report still needs one coherent explanation of what was examined and what each table records.

The replacement control does not mean replace whichever single table you last looked at. It confirms replacing the current result-table collection with the selected reviewed candidate. That distinction matters when the open report contains more than one useful table. Read the confirmation and compare it with your intention before proceeding. If you need to retain one existing table while replacing another, plan the resulting collection deliberately rather than assuming the tool will choose for you. Keep the editable checkpoint so an incorrect structural decision does not become an unrecoverable loss of entered work.

Replacement is often straightforward when the only existing table is an untouched starter grid. It becomes a reconciliation task when existing tables already hold inspection evidence. A new template does not automatically migrate that evidence into differently named columns. You must determine what transfers, what remains relevant and what requires a new review. Do not assume that removing a table removes every dependent statement elsewhere in the document. The old observations and conclusion can still remain and need checking. Replacement changes the table collection; it does not perform a technical reassessment of the entire report.

A template can provide more than a results grid. It may contain recognizable placeholders or ordinary Word paragraphs that are presented for review. Applying a table does not mean every extracted note has been adopted as a report requirement. Review these items separately and choose whether they belong in custom fields, scope, procedure references, limitations or another appropriate location. An instruction to enter a value is different from a statement that the value has been confirmed. Avoid leaving example placeholder text in a report that appears complete, and avoid treating extracted paragraphs as automatically authoritative project instructions.

The tool offers an explicit action for adding recognized template fields, which is separate from table addition or replacement. Check existing field labels before adding more, and make sure similarly worded fields do not collect conflicting versions of the same information. If a custom field duplicates a built-in report field, decide which one will carry the controlling value and whether both are necessary. Keep the resulting report understandable for its reader. A larger field collection does not improve traceability when it leaves two competing client references or two unexplained acceptance statements in different parts of the same document.

Consider a fictional practice report containing a completed five-row table for Area A and an empty starter table intended for Area B. The author receives a revised Area B form and wants to use its clearer columns. Choosing replacement would remove the current result tables, including the useful Area A practice entries, and leave the selected candidate. That is not the author's intended outcome. Instead, the author preserves an editable checkpoint, adds the reviewed Area B candidate and then deliberately removes only the unnecessary empty starter through the table-editing controls after checking which table is which.

Now change the fictional case: the report has only one empty starter and no entered results, while the candidate is the agreed structure for the whole exercise. Replacement is appropriate after its header and field meanings are reviewed. The author confirms the action, checks the resulting table and then enters practice data. These cases use the same import file and controls but have different correct decisions because the existing work differs. The decision is made from the inventory and intended final structure, not from a blanket rule that adding is always safer or that the newest file should always replace everything.

The workspace supports a bounded number of tables, rows and columns. An individual editable table can have up to twelve columns and one hundred data rows, and a report has overall table and row limits. Across the report, the current maximum is ten tables and five hundred data rows. Count proposed additions against what is already present rather than considering each imported file in isolation. Adding a large candidate to a nearly full report may therefore fail validation even if the candidate alone is acceptable. Treat such a message as a prompt to review the report's organization. Do not delete legitimate observations just to make the count smaller. Consider whether the intended deliverable should be separated into clearly related reports or whether decorative and duplicate structures are consuming the available space.

A boundary failure should not persuade you to choose replacement merely because it fits. If replacement would remove required evidence, it does not solve the underlying reporting problem. Preserve the current draft and decide how the information should be structured for the actual project. You may need a more focused table, additional explanatory fields or a separate document managed through the customer's agreed process. The free tool's limits describe its working capacity, not an acceptable sampling percentage or a permission to omit examination results. Keep technical completeness separate from the convenience of a particular table arrangement.

After the table action, compare the result with the planned final collection. Check table names, column meanings, expected item identifiers and row boundaries. Confirm that preserved tables truly remain and that removed tables are the ones you intended to remove. Then revisit narrative fields that depended on the old collection. A scope statement may need a clearer area reference; an equipment paragraph may need to identify a second setup; a conclusion may still refer to the previous result set. Make justified changes from actual evidence and leave unresolved technical decisions for the responsible reviewer.

Save the reviewed draft when appropriate and verify the confirmation. Saving a table change does not issue the report, and issuing does not independently certify the accuracy of the content. The report's saved identity remains stable when editing an existing draft. If the document is already issued, use the supported revision workflow rather than attempting to replace its preserved contents directly. Keep the original issued version available and explain the reason for the revision through the proper record process. Structural editing and document status are connected, but neither should silently stand in for the other.

Download a draft PDF after the restructuring and inspect the pages that contain the changed tables. Check whether a new title identifies the added scope, whether the removed structure has left an unexplained reference, and whether the relationship between multiple tables remains clear across page breaks. Compare the PDF with the editable draft and your source-to-destination note. A table that looks correct on screen can still need clearer wording for a reader who receives only the PDF. Correct the structure or labels deliberately and repeat the relevant proof check rather than relying on the absence of a software error.

Keep a concise change record when the conversion matters to the project. It can state which source template was used, why addition or replacement was chosen, what evidence was preserved and what remained subject to review. This record does not need to repeat every click; its value is explaining the decision. The next author can then understand why two tables coexist or why an old table was removed. That explanation also makes a future template revision easier to assess, because the starting point is an intentional report structure rather than an unexplained accumulation of imported grids.