Sphere Inspection Gets Its Own Workflow: What's New for Spheres and Beyond

Sphere equipment setup screen showing the dedicated sphere workflow and equipment-family selector for piping, pressure vessels, heat exchangers, storage tanks, STI, Appendix M, and spheres

Spherical pressure vessels have never fit neatly into a generic inspection template.

The equipment is different. The inspection views are different. Welds, manways, nozzles, CMLs, access points, and NDE locations need to be understood in relation to the sphere: not forced into a vessel or tank workflow that was designed for another geometry.

That is why sphere inspection support is becoming a dedicated part of NDT Integrity API/NDE 2.0.

The update adds a structured workflow for spheres while continuing to connect sphere inspections with the same project, field, engineering, assignment, approval, and reporting system used across tanks, vessels, exchangers, and piping.

The result is a more practical way to manage sphere work from setup through final report:

Create the project once. Assign the work by scope. Collect verified field data. Review it in context. Generate the report from the approved inspection record.

Spheres are now treated as their own equipment family

A sphere is not simply a round pressure vessel in a different orientation.

Its inspection documentation often depends on multiple views and sheets. The inspector may need to distinguish upper and lower areas, equatorial and meridional welds, manways, nozzles, attachments, support structures, and specific CML locations. The drawing must provide enough context for another inspector or reviewer to understand exactly where a finding or reading belongs.

The dedicated sphere workflow establishes that equipment-specific structure inside the inspection platform.

The equipment setup screen now shows Sphere as its own workflow option inside the broader equipment-family selector, alongside piping, pressure vessels, heat exchangers, storage tanks, STI, and Appendix M. That matters because it makes sphere work a defined inspection path at the moment the asset is created, not a workaround inside another equipment type.

Instead of starting with a generic form and manually adapting it, the project can be configured around the sphere as the inspected asset. Equipment data, components, inspection locations, assignments, drawings, and report content remain connected to the same sphere identity.

That connection matters during review. A CML placed on a sphere drawing should not become an unrelated line in a spreadsheet. A weld finding should not lose its location when the report is assembled. A manway inspection should remain associated with the correct component and view.

NDT Integrity is building the workflow so those relationships are preserved.

Sphere-specific assignments keep field work organized

Large inspections are rarely completed by one person working through one uninterrupted checklist.

One technician may complete the visual inspection. Another may collect thickness readings. A third may handle weld or NDE work. A supervisor or responsible inspector may review the results and complete the final engineering assessment.

API/NDE 2.0 supports this type of controlled collaboration by assigning work by equipment, scope, task, or technician while keeping every assignment tied to the same authoritative project.

Sphere inspections can be divided without creating disconnected projects or duplicate asset records. The team can send the appropriate sphere inspection scope to the right Android device, receive the completed work, and stage it for review before merging approved contributions into the project.

This gives project managers visibility into practical questions:

  • Which sphere inspection scopes have been assigned?
  • Which technician is responsible for each part of the work?
  • What has returned from the field?
  • What is waiting for quality review?
  • Which findings or readings have been approved?
  • What remains before the report is ready?

The process does not rely on sending separate spreadsheets, PDFs, or renamed drawing files between offices and field crews. Assignments remain tied to the equipment and inspection record they belong to.

Multi-view and multi-sheet drawings provide the right inspection context

A single static drawing is often not enough for a sphere inspection.

Different inspection tasks may require different views. A general elevation may show the overall equipment arrangement. Another sheet may provide detail around a manway or nozzle. A separate view may be needed for weld mapping, CML placement, or NDE callouts.

The new workflow establishes a foundation for multi-view and multi-sheet sphere drawings. This allows the inspection record to include the views needed to document the work without forcing every detail onto one crowded page.

Sphere drawing screen showing dedicated sphere views, multi-view drawing support, and handling for welds, manways, CMLs, and components

This is important for both field execution and final reporting.

In the field, the technician can work from the drawing context that matches the inspection task. In the office, reviewers can trace the data back to the correct view instead of trying to interpret a list of location descriptions with no visual reference.

The drawing is not treated as decoration added at the end of the report. It becomes part of the inspection data.

Through the SketchMapp workflow, inspectors can work with CMLs, openings, findings, and NDE locations on equipment drawings. The same inspection object can move through the workflow from desktop setup to assignment, Android field collection, QC, approval, and reporting.

That continuity eliminates repeated sketching and reduces the need to reconcile field notes with office drawings after the inspection is complete.

Better handling for welds, manways, CMLs, and components

Sphere inspection documentation depends on more than a list of thickness readings.

The project must also identify the equipment components and inspection objects that make the data meaningful. Welds, manways, nozzles, CMLs, NDE locations, attachments, and findings need consistent identities and locations.

The expanded workflow improves the way these objects are handled within the inspection project.

For example, a technician can work with a sphere drawing that distinguishes:

  • Shell CML locations
  • Weld seams and weld-related findings
  • Manways and openings
  • Nozzles and other components
  • NDE callouts and examination areas
  • Photos and comments attached to specific inspection items
  • Findings connected to the correct equipment view

The provided sphere screenshot makes that structure visible. It shows the dedicated sphere workflow in practice with multiple drawing views and inspection objects organized around the asset, so welds, manways, CMLs, and components stay tied to the right location instead of being flattened into disconnected notes.

This helps prevent a common reporting problem: technically correct data that loses its context during documentation.

A thickness value without a reliable location is incomplete. A weld indication without a connected drawing reference requires interpretation. A photograph stored in a general folder may be difficult to associate with the finding it supports.

The connected workflow keeps the evidence with the inspection object.

That means the system supplies what the data says rather than asking the report writer to reconstruct what probably happened from scattered files.

The same workflow foundation extends across equipment families

Sphere support is a dedicated workflow, but it is not an isolated product branch.

NDT Integrity is continuing to develop a common inspection environment across:

  • Tanks
  • Vessels
  • Spheres
  • Heat exchangers
  • Piping

Each equipment family can have its own inspection structure and drawing requirements while using a consistent project, assignment, field-transfer, review, and reporting model.

The equipment-family selector now makes that expansion clear during setup. In addition to Sphere, the workflow covers piping, pressure vessels, heat exchangers, storage tanks, STI, and Appendix M, so teams can start with the right equipment family instead of forcing different asset types through one generic path.

This consistency reduces the operational burden for companies that inspect more than one type of asset. Teams do not need to create a completely different process every time the equipment changes.

The same folder-based project setup, field-to-office transfer, controlled review process, and reporting approach can support different equipment workflows. Existing component codes can also remain consistent when organizations integrate legacy inspection information, making historical imports, exports, and trending easier to manage.

For companies with mixed inspection programs, that continuity is practical. The software can reflect the differences between a storage tank and a sphere without forcing the organization to manage unrelated systems.

Engineering and setup data transfer consistently between desktop and Android

Field mobility is useful only when the field device receives the right project information.

An Android checklist without the correct equipment setup still leaves the technician dependent on paper notes, separate drawings, or office clarification. The inspection becomes digital at the surface but remains disconnected underneath.

API/NDE 2.0 is designed to transfer the relevant engineering and setup data between desktop and Android as part of the assignment workflow.

That includes the equipment identity, inspection scope, configured components, drawing context, CML structure, and other project information required to complete the assigned work.

The technician can use the tablet as a field inspection tool rather than as a blank form.

Where the project requires engineering assessments: such as settlement, localized depression, or plumbness: the results can remain part of the same inspection record instead of being calculated in a separate file and manually re-entered later. The objective is straightforward: capture the verified field readings, apply the built-in calculation workflow, and carry the resulting information into review and reporting without duplicate transcription.

Automated calculations do not replace inspection expertise. They remove avoidable guesswork from the calculation and documentation steps. The inspector provides the readings and technical inputs; the software applies the configured calculation logic and reports the resulting values.

One sphere project, from setup to report

The sphere workflow fits into the broader NDT Integrity operating model:

  1. Set up the project using the equipment structure, documents, components, drawings, and inspection scope.
  2. Configure sphere views and sheets for the work being performed.
  3. Assign inspection scopes to the appropriate technicians or Android devices.
  4. Collect readings, findings, photos, and comments in the field.
  5. Place or update CMLs, welds, manways, components, and NDE callouts in the correct drawing context.
  6. Complete engineering assessments and automated calculations using the verified project data.
  7. Review and approve returned assignments before merging them into the authoritative project.
  8. Generate the professional report from the approved inspection record.

This workflow is consistent with NDT Integrity’s broader API inspection software, pipeline and integrity assessment tools, and connected NDE and C-scan analysis capabilities.

Digital inspection data represented as a connected point-cloud and reporting environment

The report is not rebuilt from scratch after the field work ends. It is the final projection of the data already collected, reviewed, and approved.

Built for the way sphere inspections actually happen

Dedicated sphere support is not about adding another generic template to a software menu.

It is about recognizing that equipment geometry, inspection scope, field assignments, drawings, components, engineering data, and reporting all need to work together.

With API/NDE 2.0, spheres receive their own workflow while remaining part of a common inspection platform. Teams can organize sphere-specific work, use multi-view and multi-sheet drawings, manage welds and manways with better context, and move engineering and setup data between desktop and Android.

The practical outcome is a cleaner inspection record with fewer disconnected handoffs.

You do not have to redraw the equipment because the inspection moved to the field. You do not have to re-key readings because the report needs a different format. You do not have to guess which finding belongs to which component when the drawing and data remain connected.

NDT Integrity supplies the structure. Your team supplies the verified inspection data. The system carries that information through the workflow and shows what the data supports: without adding speculation.

Learn more about the connected NDT Integrity inspection platform and the API/NDE 2.0 direction in One Platform. One Project. One Source of Truth..