Inspections
An inspection is a checklist carried out at a place on the job, by whoever is responsible for that work, with a record of what passed, what failed and what was done about it. Teralo keeps the checklist, the schedule, the evidence and the follow-up in one place, so the completed inspection is the record rather than something typed up afterwards.
Three things sit behind every inspection, and it helps to know them in order. A template is the checklist itself, written once at organisation level and activated on the projects that need it. A location is where the inspection happens, from a building down to a single room. A plan puts the two together and says when: once, on a date, or on a repeat.
The register
Inspections open on a register, the same screen shape every tool in Teralo uses: rows you can filter, group and save a view of. See The register screen for the parts that work the same everywhere.
What is specific to inspections is the split down the top of the page. My inspections is the short list of what is waiting on you. All inspections is the project's full record, which is what you want when you are looking for something that happened rather than something to do. Issues collects the failures that turned into work, and is covered further down.
Anything assigned to you also appears in My Items alongside the rest of your outstanding work, so an inspection is not a separate inbox to remember to check.
Carrying out an inspection
Open the inspection from My inspections and choose Start. Teralo records who started it and when, which is why an inspection opened by mistake is worth closing rather than leaving part done.
Work down the checklist one item at a time. Each item takes a result, and what a result looks like depends on how the template was written: a pass or a fail, a yes or a no, a measurement, or free text where the reading needs describing. Items the template marks as required have to be answered before the inspection can be finished. Every item takes photos and a note whether it needs them or not, and both are worth adding on anything that is close to the line.
When an item fails
A failure is the point of the exercise, not an exception to handle. Mark the item as failed, attach the photographs, and write a note that says what was found rather than what needs doing. The note is read later by somebody who was not standing there.
A failed item goes to the inspector for review. They either accept it, at which point it is part of the record, or send it back with a comment, at which point it returns to you to revise and resubmit. That review loop is why a failed inspection is not a dead end: the item moves until both sides agree what it says.
Turning a failure into tracked work
Where a failure needs work rather than just a record, it becomes an observation, which carries its own assignee, due date and close-out. The observation keeps a link back to the inspection item it came from, so the history stays joined up and nobody has to remember which inspection first raised it.
Issues and close-out
The Issues tab is every open failure across the project in one list, filtered the way any register is. An issue moves from open, to in progress once somebody is doing something about it, to resolved when the work is done, to closed when it has been verified. Closed means somebody checked, not that the fix was reported.
An inspection is complete when every required item has been answered and every submitted item has been accepted. Nothing further happens automatically: the record is the point.
What a guest sees
A guest carries out the inspections their own organisation has been assigned and sees nothing else. Items belonging to another subcontractor are not hidden behind a permission they could ask for, they are not in the data the page loads at all.
A guest cannot create templates, locations or plans, and cannot reassign an inspection to somebody else. If an inspection has landed with the wrong organisation, the fix is to ask the host to reassign it. See Hosts and guests for the wider picture.
SettingsHost only
Inspections is configured in two places, and which one you want depends on whether you are changing the checklist or changing the job.
Organisation, then Tools, then Inspections holds the templates. A template has sections, and sections have items; the section is what makes a long checklist readable on a phone at seven in the morning. Give each item a response type and mark the ones that are genuinely required, because required items are the only thing standing between a rushed inspection and an empty one. Templates written here are available to every project in the organisation, which is the whole reason to write them here: two projects running slightly different versions of the same checklist is the failure this prevents. See The tools catalogue.
Project, then Tools, then Inspections activates the templates this project uses and sets up the rest. Locations are a tree, typically building, then level, then room or area, and they are worth getting right early because plans and reporting both hang off them. Plans then pair a template with locations and a schedule, either a one-off date or a repeat, and generate the due dates that fill everyone's My inspections.
PermissionsHost only
Access to inspections is granted per organisation on the project, under Project, then Permissions. The useful distinction is between carrying out an inspection and reviewing one: a subcontractor completing their own work needs the first, and the party signing it off needs the second. Granting both to the same organisation means nobody independent is checking.
Permissions are set from the templates described in How permissions work, so the usual advice applies: grant against a role rather than against a person, and let the template carry the detail.
WorkflowsHost only
An inspection can be bound to a workflow, which is what turns "the inspection is finished" into a sequence somebody has to act on: a review, an approval, a notification to the client, a hold point that stops the next activity until it clears.
Workflows are built once and reused, so the shape of the approval lives in the workflow builder rather than in this tool's settings. Binding one to inspections is covered in Binding a workflow to a tool. If you only need the review loop on failed items, you already have it: that is built in and needs no workflow at all.