What a reliability engineer needs from your report portal at 2am
A client portal for inspection reports must answer one question: what is the current, approved report for this asset, and what is its status. That requires reports indexed by equipment identifier rather than by delivery date, an explicit revision state so superseded issues are visibly superseded, and per-contact access control so a contractor sees only their scope.
Most inspection portals are built as delivery mechanisms — somewhere to put the PDF instead of attaching it to an email — when what the client needs is a retrieval mechanism organised the way they think about their plant. The difference between the two is not a feature list. It is the index. A client never searches for a filename; they search for an asset, a date range, or an open finding, because that is how a regulator, an insurer, a turnaround planner or a failure investigation frames the question. The fields that make asset-first retrieval possible already exist inside every compliant report. API 510, Eleventh Edition, October 2022, clause 7.8.2(b) requires the equipment identifier, the inspection date, the next scheduled inspection date, the examiner's name, a description of what was performed and the results. Making those structured fields rather than text on page one is what converts a document into a queryable record.
Source: Clause references verified August 2026 against: API 510, Pressure Vessel Inspection Code, Eleventh Edition, October 2022 — clause 4.5.3 (examiner's employer shall maintain certification records including dates and results of personnel qualifications, available to the inspector); clause 7.8.1 (owner-operators shall maintain permanent and progressive records, permanent throughout the service life of each equipment item); clause 7.8.2(b) (inspection reports shall document the date of each inspection or examination, the date of the next scheduled inspection, the name of the person who performed it, the serial number or other identifier of the equipment inspected, a description of the inspection or examination performed and the results, and shall indicate the disposition of each inspection recommendation including why a recommendation was not implemented); clause 7.8.4 (documented results shall be approved by the responsible owner-operator inspector, engineer or qualified designee and should be posted into the appropriate inspection data management system within 90 days of completion of the inspection or startup). API 653, Tank Inspection, Repair, Alteration, and Reconstruction, Fifth Edition, November 2014, with Addendum 3, November 2023 — clause 6.8 (owner-operator shall maintain a complete record file of construction records, inspection history and repair/alteration history) and clause 6.9.1 (inspection reports, inspector recommendations and documentation of disposition shall be maintained by the owner/operator for the life of the tank). 29 CFR 1910.119(j)(4)(iv), as published on eCFR — the employer shall document each inspection and test performed on process equipment, recording the date, the name of the person who performed it, the serial number or other identifier of the equipment, a description of the inspection or test performed, and the results.
| The client's real question | What a document dump returns | What a structured portal returns | Record field that makes it possible |
|---|---|---|---|
| What is the current report for vessel V-1204? | A filename search across folders | The approved current revision, with every earlier issue marked superseded | Serial number or other identifier of the equipment — API 510 7.8.2(b); 29 CFR 1910.119(j)(4)(iv) |
| When is this vessel next due? | Nothing — the date is buried in the PDF body | A due date on the asset record, driven from the report | Date of the next scheduled inspection — API 510 7.8.2(b) |
| Who performed the examination, and were they qualified? | A name in a signature block | The name plus that technician's method certification as it stood on the examination date | Name of the person who performed, plus employer certification records — API 510 4.5.3 |
| Has this recommendation been closed out? | Manual cross-reference across report revisions | Each recommendation tracked as its own item with a status and a disposition | Disposition of each recommendation, including why it was not implemented — API 510 7.8.2(b) |
| Is the copy I downloaded last month still valid? | No way to tell without opening both files | A superseded banner and a link straight to the current revision | Revision number and approval state |
| Can our insurer's engineer see only the tank reports? | Send a second folder link and hope | Scoped access by asset group, with an expiry, set by the client's administrator | Contact-level permission on the asset, not on the folder |
| Where is the report from last week's shutdown? | An email at 9am and a wait | Its live state — under review, issued for comment, or approved | Approval and posting state; API 510 7.8.4 expects posting within 90 days |
The client's question is never "send me the file"
A reliability engineer opens your portal for one of four reasons: a regulator, insurer or auditor has asked for evidence on a specific piece of equipment; a turnaround is being planned and they need the last inspection across a list of assets; something failed and they need the history; or finance is querying an invoice. Every one of those starts from an asset, a date range or a finding. None of them starts from a filename or a job number.
That is the entire design brief, and it explains why so many portals disappoint the people who paid for them. They are built as delivery mechanisms — a place to put the PDF instead of attaching it to an email — when the client needs a retrieval mechanism organised the way they think about their plant. The gap between the two is not a feature list. It is the index the whole thing is built on.
The client is also working to their own recordkeeping obligation, not to yours. Under API 510, Eleventh Edition, October 2022, clause 7.8.1, pressure vessel owner-operators shall maintain permanent and progressive records — permanent throughout the service life of each item, progressive so new information is added as it arrives. Your portal either feeds that obligation cleanly or creates fresh work for the client every single time you deliver something.
The document dump, and why the shared folder fails
The default portal is a folder tree: client, year, month, job number, PDF. It fails on the first real query. Asked for the current report on vessel V-1204, the engineer must already know which job number covered that vessel, which month the work was performed, and whether a revision was issued afterwards under a different job. None of that lives in the folder structure, so retrieval collapses into a filename search — which works only if your naming convention has never changed.
The second failure is status. A folder shows what has been delivered. It does not show what is in progress, what is awaiting Level III review, what has been issued pending client comment, and what has been superseded. The client compensates by emailing to ask, which is precisely the traffic the portal was bought to eliminate. The portal then costs you a licence fee and saves you nothing at all.
The third is that a folder has one permission set. Real client accounts have a maintenance planner, a reliability engineer, a corrosion specialist, a plant manager, an insurer's engineer and sometimes a third-party repair contractor, with different scopes and different rights to see commercial information. One shared link serves none of them correctly, and the usual workaround is a second folder, then a third, and then a reconciliation problem nobody owns.
Index by asset, not by delivery date
The highest-value design decision available is to make the equipment identifier the primary key of the portal. Reports hang off assets; jobs become a secondary view. The client navigates to V-1204 and sees its inspection history in date order, current status, next due date, open recommendations, and every report ever issued against it — including reports produced by other contractors, if the client chooses to load them alongside yours.
The identifier is not something you have to invent. API 510 clause 7.8.2(b) requires inspection reports to document the serial number or other identifier of the equipment inspected, alongside the date of the inspection, the date of the next scheduled inspection, the name of the person who performed it, a description of what was performed and the results. Those fields already have to exist. Making them structured data rather than text on page one is what turns a document into a queryable record.
The same five elements appear in OSHA's process safety management standard. 29 CFR 1910.119(j)(4)(iv) requires the employer to document each inspection and test performed on process equipment with the date, the name of the person who performed it, the serial number or other identifier of the equipment, a description of the inspection or test, and the results. Build the data model on those five fields and the portal satisfies the client's mechanical integrity retrieval need by construction rather than by luck.
Status is a field, not a phone call
Clients ask "where is my report" more often than they ask for the report itself, because the answer determines whether they can close a work order or release equipment back to service. A portal that exposes an explicit state — field work complete, data under reduction, technical review by Level III, issued for client comment, approved, superseded — answers that question every time without consuming a human on either side of the relationship.
There is a published expectation attached to this. API 510 clause 7.8.4 states that documented inspection results shall be approved by the responsible owner-operator inspector, engineer or qualified designee, and should be posted into the appropriate inspection data management system within ninety days of completion of the inspection or startup. The owner-operator carries that duty, and they cannot meet it if your report lands on day eighty-five with findings that need discussion.
Exposing your own state is uncomfortable and useful in equal measure. Firms that publish status discover the queue is almost never in the field — it sits in review. That is a resourcing conversation about Level III review capacity, and it is far better had with data from your own status field than with an angry client on the phone quoting a date you promised three weeks ago.
Revision handling: the client must never open a superseded report by accident
Reports get revised. A transcription error is found, a client comment lands, a recommendation is reworded after an engineering assessment, a thickness reading is corrected. The dangerous failure mode is not the revision itself. It is the client who downloaded revision 0 in March, saved it to their own drive, and makes a fitness-for-service decision from it in September without ever knowing revision 1 exists.
The portal has to make superseded status impossible to miss and current status one click away. That means a revision chain held on one record rather than separate files, a visible superseded marker on every earlier issue, a link from any superseded revision straight to the current one, and — where the client's own system pulled a copy — a notification to the specific contacts who accessed the earlier version.
Retention makes this a permanent requirement rather than a temporary one. API 653, Fifth Edition, November 2014 with Addendum 3, November 2023, clause 6.9.1 requires inspection reports along with inspector recommendations and documentation of disposition to be maintained by the owner/operator for the life of the tank. A revision chain that is legible in year one and ambiguous in year twelve has failed at exactly the moment it was built for.
Recommendations are objects, not paragraphs
The most valuable content in an inspection report is the recommendation, and it is the content a PDF handles worst. Buried in section seven of a forty-page document, a recommendation has no status, no owner, no due date and no closure record. The client's follow-up lives in a separate spreadsheet maintained by one person, and the link between that spreadsheet and your report is a human memory that leaves when they do.
API 510 clause 7.8.2(b) is explicit that the records should indicate the disposition of each inspection recommendation, including the reason why a recommendation was not implemented. That is a lifecycle, and lifecycles belong in a database rather than in prose. A portal carrying recommendations as tracked items — open, accepted, deferred with justification, closed, closed by repair — hands the client the exact artefact their auditor asks for, already assembled.
It also changes your commercial position. Open recommendations are the client's forward work list, and the contractor whose portal holds that list is present at the moment the next scope is defined. This is the quiet reason portals repay their cost, and it is the same reason digital twin context beside a report shifts the conversation from document delivery to asset condition, where the next job actually comes from.
Access control across many contacts on one account
Client organisations are not single users. A workable permission model has three axes: who the person is, which assets or units they may see, and what they may do — view, download, comment, approve, or see commercial information such as rates and invoices. Collapsing that to one shared login guarantees either over-exposure or constant manual gatekeeping, and both are worse than the email traffic they replaced.
Two cases break naive designs. The first is the third party: an insurer's engineer, an authorised inspector, or a consultant retained by the client, who needs scoped read access for a defined period and no commercial visibility whatsoever. The second is the client's own repair contractor, who needs the inspection findings for the work they are quoting but has no business seeing the rest of the plant's records.
Both are solved by scoping access to asset groups with an expiry date, granted by the client's administrator rather than by your project manager. That puts the gatekeeping decision with the person who actually knows the answer, and it removes your firm from a judgement you should never be making — which of your client's people, and which of your client's other vendors, are entitled to see which of your client's records.
Who performed it, and were they qualified
The question arrives during audits, insurance reviews and disputes: who performed this examination, and were they certified in that method on that date. A portal showing a signature block answers half of it. API 510 clause 4.5.3 places the duty on the examiner's employer to maintain certification records of the examiners employed, including dates and results of personnel qualifications, and to make those records available to the inspector.
Meeting that from a filing cabinet takes a day of somebody's time. Meeting it from the same system that dispatched the technician takes a click, because the certification record and the report are joined by the person and the date. Firms that can produce this on demand shorten audits materially, and audit friction is a real unbudgeted cost that nobody quotes for. It is also the strongest answer available when a report is challenged.
Exposing certification evidence through the portal is a choice rather than a requirement, and the firms that make it convert a compliance burden into a differentiator no competitor can match on a proposal. Where the client's own review process is the concern, the distinction between reviewing a report and re-running the examination is set out in third-party review versus re-inspection. The portal is where that review starts.
The 2am effect: what self-service does to your admin load
The commercial argument for a portal is usually made on client satisfaction. The larger effect lands on your own overhead. Every report request arriving by email consumes a coordinator's time twice — once to find the file, once to reply — and it arrives during your working hours regardless of when the client actually needed it. A client who retrieves the report themselves at 2am consumes none of it, and gets a better answer faster.
The volume is not trivial. Report requests, status enquiries, "is this the latest version", re-sends to a new contact, and "can you send everything for this unit" make up the bulk of an inspection coordinator's inbox. Structuring the portal around asset, status and revision removes the categories generating the most traffic, and that coordinator's time moves to work that is billable rather than work that is apologetic.
The retention argument closes it. Your client must hold these records for the service life of the equipment, and a portal keeping the current, approved, correctly indexed version available is doing part of their compliance job for them. Atlantis builds this on Odoo as part of the inspection ERP — affordable, accessible, fully customisable to your report formats and your clients' asset hierarchies. Ask for a demo against one unit of a real client's plant, or request a quote.
What do clients actually search for in a report portal?
An asset, a date range, or an open finding — never a filename. The four recurring triggers are an auditor or insurer asking for evidence on specific equipment, turnaround planning across a list of assets, a failure investigation needing history, and an invoice query. Every one of those starts from the plant's structure, which is why an index built on your job numbers and delivery dates fails on the first real question.
Why does a shared drive fail as a client portal?
Three reasons. Its index is the folder tree, which encodes your job numbering rather than the client's asset register. It carries no status, so the client emails to ask what is in progress and what has been superseded. And it has one permission set, while a real client account has a planner, a reliability engineer, a plant manager, an insurer's engineer and sometimes a repair contractor, all with different scopes.
How should revisions be handled so the client always sees current?
As a revision chain on one record, not as separate files in a folder. Every superseded issue carries a visible superseded marker and a link to the current revision, and contacts who downloaded an earlier version are notified when it is replaced. The failure to design against is a client making an engineering decision in September from a revision that was corrected in March.
How does access control work across multiple client contacts?
On three axes: identity, asset scope, and permitted actions — view, download, comment, approve, and whether commercial information is visible at all. Third parties such as an insurer's engineer or a repair contractor receive scoped read access to an asset group with an expiry date. Grant is administered by the client's own administrator, so your project manager never decides who inside the client may see what.
What does a client portal do to your admin workload?
It removes the highest-volume categories from the coordinator's inbox: report requests, status enquiries, version checks, re-sends to a new contact, and bulk requests for everything on a unit. Those arrive during your working hours regardless of when the client actually needed them, and each consumes time twice — once finding the file, once replying. Self-service moves that time to billable work.
How long does the client have to keep inspection reports?
Long. API 510, Eleventh Edition, October 2022, clause 7.8.1 requires pressure vessel owner-operators to maintain permanent and progressive records, permanent throughout the service life of each equipment item. API 653, Fifth Edition with Addendum 3, November 2023, clause 6.9.1 requires inspection reports, inspector recommendations and documentation of disposition to be maintained for the life of the tank.
Built for any business that runs on operations
Most companies do not fail at their craft. They lose time, margin and goodwill in the gaps between the tools they use to run the place — a quoting spreadsheet that does not talk to the job sheet, a job sheet that does not reach accounts, and a compliance folder nobody can search when a client asks. Atlantis closes those gaps by putting the whole operation on one platform, so information is entered once and everything downstream stays in step.
What you can run on it
- Sales and CRM — leads, quotes, follow-ups and the pipeline that tells you what next month looks like.
- Projects and job costing — plan the work, track the hours and materials against it, and see the margin while the job is still live rather than at final account.
- Field and service teams — dispatch, schedules, mobile capture that works with no signal, and sign-off from site.
- Inventory and purchasing — stock, suppliers, reorder points and goods receipt, joined to the jobs that consume them.
- People — records, qualifications and licences with renewal reminders, timesheets, leave and payroll.
- Quality and documents — procedures and forms under revision control, with the audit trail an inspection or accreditation body actually asks for.
- Accounts — invoicing, expenses, multi-currency and the reporting your accountant stops chasing you for.
Affordable, accessible, fully customizable — and we mean each word
Affordable because the whole suite is included rather than sold to you a module at a time, and because implementation is done by people who have run operations rather than by a chain of subcontractors. Accessible because it runs in a browser and on a phone, works for a small team on day one, and does not need a specialist on staff to keep it alive. Fully customizable because your process is the thing that makes you competitive — the software should bend to it, not the other way round.
Industries we configure for
Service businesses and contractors, manufacturing and fabrication, trading and distribution, laboratories and testing houses, engineering consultancies, construction and facilities, and asset owners across energy, marine, aerospace and infrastructure. Inspection and testing is where we started, and it remains the sector we go deepest in — but the platform underneath is general-purpose, and most of what it does has nothing to do with inspection at all.
What happens when you get in touch
A short conversation, not a sales sequence. We ask how the business runs today and where it hurts, show you the platform doing that work, and send a written quote shaped to your region, your team size and the scope you actually need. No obligation, nothing to install first, and no pressure to decide on the call. Reach out and tell us what you are trying to fix.
Related: business management platform · inspection management software · choosing the right category of software · modules · by industry · asset integrity platform. Book a free consultation.