Observations

An observation is the general-purpose tracker for anything on the job that somebody has to do something about: a hazard, a defect, a missing handrail, an item that failed an inspection. It carries who is responsible, by when, and the evidence that it was actually fixed.

Its job in Teralo is broader than its own register. Half the tools on the project raise observations rather than growing a follow-up mechanism of their own, so an inspection failure, an incident, a permit, a method statement, a piece of equipment or a location can all put work on somebody's list without any of them needing to know how a close-out works. Learning observations once is how you learn the follow-up half of six other tools.

Raising one

Choose New Observation and fill in five things: the type, a priority of critical, high, medium or low, a description, the location from the project's location tree, and a due date. Then assign it, to an organisation and optionally to a named person in it, and attach the photographs that show what you are talking about.

Types can carry custom fields, so a project's own observation form may ask for more than that. A field can be free text, a number, a date, a set of radio options or a dropdown, and whichever it is, it becomes a column you can filter and report on rather than a sentence buried in a description.

Saving as a draft records the observation and does nothing else. Raising it is the event that matters: the observation takes its number, moves to Open, and its workflow starts.

Raised from somewhere else

Where an observation comes from another tool it keeps a link back to what raised it, and that link does real work rather than being a breadcrumb. An inspection cannot close itself while an observation raised from one of its items is still open, and a passive fire installation cannot pass review while a defect raised against it is unresolved. So the observation is not a note about the problem, it is the thing holding the parent open.

Open, resolved, verified, closed

The lifecycle is a loop rather than a line, and that is the point of it:

1. Open, raised and waiting on the assignee
2. In progress, once they have started
3. Resolved, when they say the work is done, with resolution photographs and a note
4. Verified, once whoever is checking agrees
5. Closed, the terminal state

Between resolved and verified sits the step everything else depends on. If the verifier is not satisfied, rejecting sends the observation back to Assigned and the assignee starts again. That status only ever arrives that way, so an observation sitting on Assigned is one that has been bounced, which is worth knowing when you are reading a register rather than working through it.

Resolution photographs are kept separately from the evidence photographs taken when it was raised, so the before and after stay distinguishable however many are attached.

Whatever is waiting on you appears in My Items, and the count of open observations sits on the Observations item in the sidebar, so an unattended list is visible without opening it.

What a guest sees

Observations are scoped, and they are one of the few tools that genuinely are. If your organisation is the project host, you see all of them. If it is not, you see the observations you raised, the ones assigned to you personally and the ones assigned to your organisation, and nothing else. Another subcontractor's defect list is not hidden behind a permission you could ask for, it is not in the data the page loads.

The exception is Can manage observations, which grants the full project view. Granting it to a subcontractor is a real decision rather than a formality, since it is the difference between seeing your own work and seeing everybody's.

SettingsHost only

Tools, then Observations, at either organisation level or project level, holds the observation types. A type is a name, the custom fields that come with it, and the workflow bound to it.

Write types at organisation level and activate them per project. Two projects using differently named types for the same thing is what stops observation data being worth anything across a portfolio, and the activation step means a project still only offers the handful it actually uses. See Organisation level and project level and The tools catalogue.

Custom fields belong to the type, so add them before the type is in use. Adding one later leaves every existing observation of that type with the field empty, which is fine, but reporting across the two halves will not be.

PermissionsHost only

Five permissions, and the third is the one that makes this tool work across organisations:

• Can view observations shows the register, subject to the scoping above
• Can create observations allows raising them
• Can resolve observations allows acting on the ones assigned to your own organisation, and only those
• Can manage observations allows editing any observation, configuring the tool, and seeing the whole project's
• Can permanently delete observations is separate and is not implied by managing

Verification is the one that is not in that list. The verify and close-out decisions are gated on the inspections execute permission rather than an observations one, because verifying somebody else's corrective work is the same act as signing off an inspection, and the same small group of people should be doing both. If a verification step is waiting and nobody can act on it, that is the permission to check. See How permissions work.

WorkflowsHost only

Every observation type must have a workflow bound to it, and an observation of that type cannot be raised until one does. A draft with no binding saves; raising it returns an error naming the type.

The default shape is worth understanding before you change it, because it is the one graph in Teralo that loops a step back onto itself. The assignee starts work, does it, and marks it resolved; a verifier either accepts, which moves it to verified and on to close-out, or rejects, which sets the status back to Assigned and returns the observation to the same start-work step it came from. That loop is what lets an observation go round twice without anybody raising a second one.

Both decisions can reject, so a close-out can send work back just as a verification can. Build the variations in the workflow builder and attach them as described in Binding a workflow to a tool.