Scoped Permissions and QC: How Field Returns Stay Controlled Before They Reach the Master Project
When several inspectors work on one inspection, the challenge is not simply dividing the workload. The difficult part is controlling what each person can change, verifying what comes back from the field, and keeping one authoritative project record.
Without that control, parallel field work can create duplicate readings, overwritten findings, mismatched equipment references, and uncertainty about which revision belongs in the final report.
API/NDE 2.0 addresses this with two connected controls:
- Scoped assignment permissions, which limit each inspector to the exact equipment area and task assigned to them.
- Pending Import and QC, which stage returned field packages for review before they become part of the master project.
The result is a workflow designed for real inspection teams working across Windows, Android, cloud services, QC review, and final reporting.
The master project remains controlled
In a traditional multi-inspector workflow, the project may exist in several places at once.
The office has one version of the equipment drawing. An inspector has a tablet containing field notes. A second technician has a separate spreadsheet of UT readings. Photos may be stored in a shared folder, while checklists are returned by email.
When those pieces are combined manually, project ownership becomes difficult to establish. A supervisor may know that several people worked on the inspection, but not which data was accepted, which information was changed, or whether two technicians recorded the same location.
API/NDE 2.0 is built around a single authoritative project. Field teams can work in parallel, but their returned packages do not automatically overwrite that project.
The master project remains the controlled record. Returned work enters a reviewable state first. Only after the contribution has been checked and accepted does it become part of the project used for reporting, trending, and final deliverables.
This separation gives the project owner a clear answer to an important question:
What has been submitted, and what has actually been approved?
The dashboard makes that distinction visible at the project level. You can see assignment and project status before anything is treated as final, which helps QC reviewers and project owners track what has been returned, what is still pending, and what is actually ready to move forward into the authoritative project.
Scoped permissions keep assignments precise
A field assignment should not give an inspector unrestricted access to the entire project.
If one technician is assigned the shell of a vessel, that technician should be working on the shell task: not changing roof data, editing another inspector’s findings, or modifying unrelated equipment.
Scoped permissions support that distinction by tying access to the assignment itself. The scope can be defined by:
- Equipment
- Equipment area
- Inspection task
- Inspection discipline
- Assigned contributor
- Project revision
This is more than a user login. It is a practical boundary around the work being performed.
An inspector assigned to shell and openings sees the information needed for that assignment. A technician completing roof and NDE work receives the relevant scope for those tasks. Another contributor may be assigned a settlement assessment or a specific piping circuit.
Each person can complete the work they own without being given unnecessary control over the rest of the project.
That reduces the chance of accidental edits and keeps responsibility visible. When a package returns, the project team can identify the contributor, assignment, equipment area, and task associated with the submission.
The field package carries the evidence with it
A returned assignment is not just a completed form.
The field package can include the data needed to evaluate the work as a complete inspection contribution:
- Contributor identity
- Assigned equipment and task
- UT readings
- Findings
- Photos
- Checklists
- Sketches or inspection locations
- NDE information
- Potential conflicts with existing project data
This matters because QC cannot reliably review a number without its context.
A UT reading needs to remain connected to the correct CML or inspection location. A finding needs to be associated with the equipment area where it was observed. A photograph needs to remain tied to the relevant finding or task. A checklist needs to show what was completed and by whom.
Keeping those items together gives the reviewer a package they can evaluate against the project: not a collection of disconnected files that must be reconstructed manually.
That includes the import details tied to the returned package and the equipment organization it belongs to. The reviewer can see where the work fits in the project structure, confirm that the submission matches the assigned scope, and review the returned content before it is allowed into the master record.
The workflow is designed to preserve the relationship between field observations and the project objects they belong to.
Pending Import creates a review point before merging
When a field assignment returns, it enters the Pending Import workflow.
This is a deliberate staging point between field completion and project acceptance. The returned package is available for review, but it is not yet treated as part of the authoritative master project.
The QC reviewer can examine the submitted information and compare it with the existing project data. That review can include:
- Confirming the contributor and assignment
- Checking that the correct equipment area was inspected
- Reviewing UT readings against the assigned CMLs
- Verifying findings and their locations
- Checking that photos support the submitted observations
- Reviewing completed checklists
- Identifying possible conflicts with existing readings or findings
- Confirming whether the package is ready for import
Potential conflicts are especially important in multi-inspector work. Two packages may contain information for the same location, or a returned reading may not align with an existing project value. The system should not silently decide which information is correct.
Instead, the conflict remains visible for QC review. That matters in the Pending Import stage because returned field packages are still under review at that point. They are not yet part of the authoritative project, and the reviewer can evaluate the import details, assignment status, and submitted evidence before approving the merge.
That removes guesswork from the import decision. The reviewer can investigate the source, compare the submitted evidence, and determine what should become part of the project record.
QC controls what becomes canonical
The purpose of QC is not to slow down field work. It is to protect the integrity of the final project.
Before approval, returned information is a contribution under review. After approval, it becomes part of the canonical project data used by the rest of the workflow.
That distinction creates a clear ownership model:
- The master project defines the authoritative equipment and inspection structure.
- The assignment gives a contributor access to a controlled portion of that structure.
- The Android device collects information within that assigned scope.
- The returned package enters Pending Import.
- QC reviews the contributor, readings, findings, photos, checklists, and conflicts.
- Approved information is imported into the master project.
- The approved project data feeds the final report and project repository.
This structure keeps field productivity and project control working together.
Inspectors can complete their assigned work without waiting for every other contributor. QC reviewers can evaluate returned packages without searching across emails, shared drives, and separate spreadsheets. Project owners can see what has been accepted rather than treating every submitted file as final.
One project identity across Windows, Android, and cloud
Controlled importing only works when the project retains its identity across devices and platforms.
API/NDE 2.0 is designed to connect the project as work moves through the workflow:
Windows project setup → assignment → Android field work → cloud return → Pending Import → QC approval → master project → final report
The equipment, task, and inspection objects remain connected through those stages.
That continuity is important for data such as CMLs, findings, NDE locations, and photos. If the field technician is working from the same equipment structure created in the office, the returned data can be evaluated against known project objects rather than manually matched after the fact.
The CML table supports that review by keeping thickness data connected to the exact locations and records being evaluated during import. QC can review returned CML data in context instead of working from detached notes or separate spreadsheets.
This also supports the use of SketchMapp on Android. Inspectors can work from equipment drawings in the field, place or update CMLs, add findings, and create NDT callouts without creating an unrelated drawing that someone in the office must later interpret.
The field record remains part of the project workflow rather than becoming a separate attachment.
Canonical data prevents duplicate entry
Once a contribution is approved, the goal is to use that data: not retype it.
Approved UT readings should be available to the inspection calculations and report. Accepted findings should carry through to the appropriate report sections. Photos and checklists should remain connected to the inspection record. Equipment and component references should not need to be recreated by an office administrator.
This is the same principle behind NDT Integrity’s broader inspection workflow: perform the inspection once and use the same data through the final report.
The API inspection workflow supports connected inspection reporting, while SketchMapp gives inspectors field tools for drawings, CML layouts, and NDT callouts. These capabilities are designed to reduce the handoffs that create duplicate data entry and calculation rework.
The final report should reflect approved inspection data: not a second version assembled from memory.
What this changes for inspection teams
Scoped permissions and Pending Import provide practical control at the points where multi-inspector projects usually become difficult.
For inspectors, the assignment is clear. You work on the equipment area and task assigned to you.
For QC reviewers, the returned package contains the information needed to make an informed decision, including contributor details, readings, findings, photos, checklists, and possible conflicts.
For project managers, the master project remains protected while work is completed in parallel.
For clients, the final report is built from approved information with a clearer connection between field evidence and reported results.
The system does not ask software to make a subjective decision about conflicting data. It keeps the conflict visible so the responsible reviewer can resolve it. It supplies the information available in the package, preserves the project structure, and makes the acceptance decision traceable.
That is how field returns stay controlled before they reach the master project.
One controlled path from assignment to report
Multi-inspector work does not need to mean multiple disconnected project versions.
With scoped assignment permissions, each contributor works within a defined equipment area and task. With Pending Import and QC, returned packages remain separate until they have been reviewed. With canonical project handling, approved data becomes the source used for calculations, reporting, trending, and final deliverables.
API/NDE 2.0 connects those stages across Windows, Android, cloud workflow, QC, and the final project.
The operating principle is straightforward:
Field teams work in parallel. QC controls what enters the master project. The final report uses the approved data; not a manually reconstructed version of it.
For more on the broader API/NDE 2.0 workflow, read One Platform. One Project. One Source of Truth. You can also explore NDT Integrity’s pipeline integrity tools and workflow videos.