Managing your fault reports

Once faults are landing in your team's queue, someone needs to triage them, decide who's picking them up, keep the reporter informed, and mark them done. This article walks through the day-to-day of working faults inside Fault Reporting.

In a nutshell: Open Fault Reporting, filter to your team's queue, open a fault, assign it, move it through its statuses (Start Work → Mark Done), and use comments to keep everyone in the loop.

Who this is for

Members of the team that owns a fault. If you reported a fault but another team is handling it, you can still open it, follow progress, and comment — but you can't triage or resolve it.

Finding faults

Open Fault Reporting from the main navigation. Use the filters at the top to focus:

• Scope — Team (everything your team owns), Assigned to me (just your faults), or Reported by me (faults you raised).
• Status — Active by default (hides completed faults), or All Statuses, or a single status.
• Priority — narrow to a single priority.

Each fault shows its title, category, priority, status, and who it's assigned to. Click one to open the fault detail.

Understanding a fault at a glance

The fault detail shows:

• Category and Priority badges, and the current Status.
• Location — where in the building the problem is, if recorded.
• Managed by — the team currently responsible (shown as the organisation's name).
• Reporter — who raised it.
• Assignee — the individual working it, or Unassigned.
• Activity — a full timeline of everything that's happened, newest changes at the bottom.

Assigning a fault to someone

Faults arrive Unassigned — they belong to the team, not a person, until someone picks them up.

1. On the Assignee row, click Assign (or Reassign to change it).
2. Choose a member of the team. You can only assign to people in the team that owns the fault.
3. Click Save.

The person you assign is notified that the fault is now theirs. Assigning is about sharing the load within the team — it doesn't change which team owns the fault.

Moving a fault through its statuses

Faults follow a simple lifecycle. The buttons available depend on the current status.

The action buttons:

• Start Work — move an Open (or Awaiting Info) fault to In Progress.
• Awaiting Info — mark that you're blocked waiting on the reporter. Add a comment saying what you need; the reporter is notified.
• Mark Done — the work is finished.
• Close — the fault won't be actioned. You'll be asked to pick a reason: Duplicate, Invalid, No Longer Needed, or Out of Scope — then click Confirm Close.

Done and Closed are final — a fault can't be reopened, so use them when you're sure.

Tip: "Waiting for parts" is still In Progress. If you're waiting on a delivery or an external contractor, the fault stays In Progress — you're still handling it. Only use Awaiting Info when you genuinely can't proceed until the reporter comes back to you.

Editing the details

If a fault is miscategorised, needs a different priority, or the reporter didn't say where the problem is:

1. Click the edit (pencil) icon at the top of the fault.
2. Update the Title, Description, Category, Priority, or Location (pick the area from your building's space list).
3. Click Save Changes.

Changes to priority and category are recorded in the Activity timeline, so the history stays clear.

Comments and keeping people informed

Use comments to add context, ask questions, and record what you did.

1. Scroll to Activity and find Add comment.
2. Write your comment and click Post Comment.

Who sees your comments: everyone involved in the fault — your team, any team it has previously passed through, and the person who reported it. Write with that in mind.

Notifications are handled for you:

• Whoever reported a fault is kept up to date on its progress automatically.
• When you assign a fault to someone, they're notified.
• Commenting on a fault means you'll be notified of later updates to it.

The activity timeline

Every fault keeps a complete, unchangeable history under Activity: when it was created, each status change, assignments, priority and category changes, transfers between teams (and why), and comments. It's the single source of truth for what happened and when — useful for handovers and for answering "what's going on with this?".

When it's not yours to fix

Sometimes a fault turns out to be a building issue rather than something your team handles — a shared-area light, a problem with the fabric of the building. In that case you transfer it to the organisation that should own it (typically your landlord). See Escalating a fault to another organisation.

Related articles

• Managing the team that receives your fault reports
• Escalating a fault to another organisation

Updated on: 15/07/2026