One Consistent Workflow Across Every Equipment Type: UI and Navigation in API/NDE 2.0
When an inspection company works across tanks, vessels, spheres, exchangers, and piping, the equipment changes: but the work still follows a familiar pattern.
You set up the project. Assign the inspection scope. Collect readings, photos, sketches, and findings. Review the data. Complete the calculations. Build the report.
The problem is that many software systems make each equipment type feel like a separate application. Controls move. Menus change. Terminology is inconsistent. A technician who knows how to complete a vessel inspection has to relearn the workflow when the next job involves a tank or piping circuit.
API/NDE 2.0 continues to address that problem by consolidating common controls, navigation, themes, and equipment workflows into one consistent experience.
The result is not a generic interface forced onto every inspection. Equipment-specific requirements remain in place. What changes is the way you move through the application.
The same workflow, regardless of equipment type
Tanks, vessels, spheres, exchangers, and piping have different inspection requirements. Their drawings, CML layouts, calculations, and reporting sections are not interchangeable.
The work process around them, however, has a consistent structure.
In API/NDE 2.0, that structure is organized around the project and the equipment inside it:
- Create or open the project.
- Select the equipment and inspection scope.
- Assign work to the appropriate technician or team.
- Collect field data, drawings, photos, and NDE results.
- Review returned work through QC and approval.
- Apply automated calculations and engineering assessments.
- Generate the final report from the approved project data.
The common navigation pattern means you do not have to hunt through a different menu system for every asset class. The equipment-specific tools appear within the same broader workflow.
That matters during busy inspection programs, where a technician may move from a vessel inspection to a tank inspection and then support piping work later in the same week. Less time is spent learning where controls are located, and more time is spent entering verified inspection data.
Common controls without removing equipment-specific detail
UI cleanup is not about making every screen identical. A tank is not a pressure vessel, and an exchanger is not a piping circuit.
The goal is to make the controls that perform common tasks behave consistently across modules.
The provided screens make that point clearly. Whether you are looking at Equipment Type selection, the main Dashboard, Exchanger Setup, STI 2, or Appendix M, the broader structure stays familiar. Navigation remains organized in a predictable way, and the common workflow controls appear where users expect them.
That consistency matters because it reduces interface friction without flattening the equipment-specific work. You still get the setup and documentation views required for each module, but you are not starting over with a different operating pattern every time you move between equipment families.
Project navigation, equipment selection, assignment handling, review steps, report access, and status tracking should not require a different mental model for each equipment type. When the same type of action uses the same control and appears in a predictable location, users can work from experience instead of relying on trial and error.
This is especially important for teams with multiple roles:
- Inspectors need direct access to checklists, CMLs, readings, photos, and findings.
- Supervisors need to see assignments, returned work, and approval status.
- QC reviewers need to compare submitted data against the project record.
- Report coordinators need access to approved content, drawings, calculations, and branding controls.
- Managers need a clear view of what is complete and what remains open.
A consistent interface gives each role the same project context while exposing the tools relevant to the work in front of them.
One project folder instead of disconnected report paths
The folder-based project setup is part of this consistency.
You place the project documents in the appropriate folder, upload them with one click, and begin with a report that is up to 98% complete. From there, you can add inspection data, comments, drawings, and supporting documentation rather than rebuilding the report from a blank template.
That approach reduces the number of separate starting points in the application. A tank report, vessel report, piping report, or NDE report begins from the same project-centered process.
It also keeps supporting evidence connected to the equipment record. Photo comments can be added directly, and the completed report can be printed from the same workflow.
This removes a common source of rework: collecting documents in one location, entering field data in another, and then manually assembling the report at the end.
Field tools that follow the same equipment record
The consistent workflow continues on the tablet.
Technicians can use tablet checklists, capture direct Bluetooth UT gauge readings, and work with SketchMapp to create or update equipment drawings in the field. CMLs, sketches, and NDT callouts remain tied to the equipment and project instead of becoming isolated images or handwritten references.
The same field approach applies whether the technician is documenting:
- A tank shell and roof
- A pressure vessel and its openings
- A sphere inspection
- An exchanger component
- A piping circuit and its CML locations
The drawing itself becomes part of the inspection record. That is different from creating a separate sketch, attaching it to an email, and asking an office team to interpret and recreate it later.
With SketchMapp, the inspector can place the relevant inspection objects where they belong while the asset is in front of them. This helps eliminate the CAD revision cycle caused by unclear field notes, missing locations, or drawings recreated by someone who was not present during the inspection.
The workflow remains inspector-level rather than CAD-heavy. You use the tools needed to document the inspection without introducing a separate drafting process.
Learn more about the SketchMapp workflow.
Navigation that keeps calculations connected to readings
A consistent interface is only useful when the underlying data remains connected.
API/NDE 2.0 is designed to keep readings, CMLs, findings, drawings, and calculations within the same inspection workflow. This is important because an inspection conclusion should come from verified readings and controlled calculations: not from manually copying values between unrelated screens or spreadsheets.
For applicable equipment and inspection scopes, built-in engineering assessments support work such as:
- Settlement assessment
- Localized depression assessment
- Plumbness assessment
- Thickness and CML evaluation
- Corrosion-rate and remaining-life calculations
- Other equipment-specific integrity calculations
The software supplies the calculation from the data entered into the project. It does not ask the inspector to guess which result belongs in the report or manually rework the same values in a separate spreadsheet.
That connection helps remove speculation from the process. You enter the verified field readings. The system applies the relevant calculation workflow. The resulting information moves into review and reporting.
Legacy data stays usable
Consistency also matters when a company is moving between systems or importing historical inspection records.
NDT Integrity uses the same component codes across the workflow, making legacy system integration more practical. Historical data can be imported and exported without forcing the inspection team to create a new naming system for every equipment type.
That supports trending across inspection intervals.
A component that has an established history should remain identifiable as the project moves from an older system into the current workflow. The goal is to preserve the connection between the component, its location, its previous readings, and its current inspection results.
This is particularly important for CML and thickness-management programs. Changing software should not require the company to abandon the terminology that makes historical comparison possible.
A consistent report workflow with controlled branding
The same navigation improvements extend into report production.
Once inspection data, calculations, drawings, photos, and NDE results have passed through review, the report should be a direct output of the approved project record. It should not require a second manual reconstruction.
NDT Integrity supports user-controlled branding so companies can apply custom cover sheets, colors, and report presentation without creating a separate design workflow for every equipment type.
A tank report can retain the company’s branding. A vessel report can use the same visual identity. Piping, exchanger, sphere, and NDE deliverables can follow the same standard without forcing the report coordinator to rebuild the appearance each time.
That consistency is useful for clients, too. They receive reports that look like they came from one controlled inspection program, even when the work covers multiple equipment classes and several field technicians.
Less interface friction means fewer workflow mistakes
UI and navigation cleanup may sound like a minor release detail. In the field, it is not.
When controls move from one module to another, users can miss steps. When terminology changes between equipment types, data can be entered in the wrong place. When report workflows are separated, the same information may be typed more than once.
Those problems create calculation reworks, CAD revisions, delayed approvals, and reports that require unnecessary correction.
API/NDE 2.0 is being organized around a simpler operating principle:
The equipment changes. The workflow should remain recognizable.
You should be able to move from tanks to vessels, spheres, exchangers, and piping while retaining the same project-centered approach to assignments, field collection, review, calculations, and reporting.
The system still provides the equipment-specific tools required for the inspection. It simply places those tools inside a more predictable framework.
The Appendix M screen follows that same pattern. It gives users the module-specific content they need without breaking the broader navigation model established throughout the platform.
Built for inspectors who work across the real asset mix
Inspection companies rarely work with one equipment type all year. A single client program may include storage tanks, pressure vessels, piping circuits, exchangers, and specialty equipment.
Your software needs to support that variety without making every job feel like a new application.
That is the purpose of the UI and workflow cleanup in API/NDE 2.0: consolidate the common experience, preserve equipment-specific requirements, and keep the inspection record connected from the field through the final report.
With a consistent navigation model, direct field tools, integrated calculations, legacy component codes, and controlled report branding, NDT Integrity is building a workflow that supplies only what the data says.
No unnecessary reconstruction. No disconnected report paths. No repeated relearning of the interface for every asset class.
Explore the API inspection workflow or review the API/NDE 2.0 platform overview to see how the connected project workflow extends across inspection and integrity work.