What each screen is, who can see it, and what every project switch actually does.
Every account has one access level. It decides which parts of the site exist for that person, before any project switch is considered.
| Access level | What they get |
|---|---|
| Admin | Everything, on every project, including the Administration screen. |
| Manager | The same as an admin, including Administration. |
| Engineer | Full working access, but only to the projects they are assigned to. No Administration screen. |
| Client | Read-only. They see the project's dashboard and whichever sections are switched on. They cannot test devices or import a snapshot. |
Two phrases are used below. Someone can work on a project if they are an admin, a manager, or an engineer assigned to it. Everyone else is a reader.
Open Administration → Projects, choose a project, and find the Portal features box. Tick or untick, then press Save project.
The Administration button appears in the top bar for an admin or a manager only. An engineer or a client never sees it.
The same project form contains Driver applicability. A template-wide rule means modules of that template do not require DALI drivers on any project. Administrators can change these global rules. A manager or administrator can also exclude one zero-driver module without changing the rule for the rest of its template.
This setting affects driver addressing only. Presence, photocell, switch and scene-set devices found on the graphics still require testing and still count towards progress and module completion.
Each switch belongs to one project. Changing it affects every person who uses that project.
| Switch | Default | What it controls |
|---|---|---|
| Dashboard | On | The four figures across the top, Progress over time, Floor commissioning score and Module tracker. It does not control the other cards — each of those has its own switch below. |
| Device testing | On | The Device testing tab, where an engineer records a device as Pass, Pending or Not installed. Only people who can work on the project ever see this tab. |
| Emergency | On | The Emergency lighting card, the outstanding-failures table, and the Emergency results figure at the top. Switch it off on a project with no emergency fittings and all three disappear together. |
| Timing schedules | On | The Lighting schedules card, and the matching section of the progress report. |
| Parts | On | The Installed parts & product codes card, and its report section. |
| Inspectly snags | On | The snag card, the snag figure at the top, and the snag section of the report. The project must also be linked to an Inspectly project for numbers to appear. |
| Reports | Off | Gives clients the progress report button. Anyone who can work on the project already has it, switch or no switch. So this one only decides whether the client may produce the report themselves. |
| Portable snapshot import | Off | The Snapshot tab: uploading a snapshot by hand, pairing a workstation, and the automatic restore route that sends snapshots in on its own. With this off, no snapshot can reach the project at all. |
| Emergency drawings | On | The emergency drawing for each floor, showing every sensor coloured by its last test. It only appears when Emergency and Progress drawings are both on as well, so this switch narrows and never widens. Use it to give a client the emergency figures without the floor-by-floor map of which fitting failed. |
| Progress drawings | Off | The Progress drawings panel: viewing a floor PDF, and the drawing ZIP. With this off the drawings are still made and still kept on the site workstation; they simply are not shown here. |
| Issues (engineering evidence) | Off | The engineer-only workbench for drawing and databasing checks. Clients cannot see its navigation, counts, findings or decisions. Its findings never change commissioning progress or handover. |
| Project Intelligence | On | The evidence-backed Project Update, freshness, change, limitations, Project Journal and update export. Project members can read it. Engineers can add journal entries. Managers can correct or archive another author's human entry. |
The one that surprises people. Unticking Dashboard does not empty the page. It removes the top figures, the trend, the floor scores and the module tracker. Emergency, timing, parts, snags and drawings each keep their own switch and stay where they are.
There are two separate layers, and they are easy to confuse.
They are linked in one direction only. If Timing schedules is off as a project switch, the report tick box cannot bring it back.
The main report keeps emergency totals and failure causes concise. When recorded emergency failures exist, an Emergency failures appendix starts on a new page near the end. It lists only affected sensors, with the floor, functional result, duration result and plain-language reason. Passed sensors are not repeated as rows.
If every other recorded test passed, the appendix says so. If any sensor has no result, the appendix instead says that no-result sensors are included in the earlier summary. The existing module list follows as the final appendix when it is selected.
The progress report toolbar has a Draft email button. Choose the report and drawing packs you plan to attach. The draft uses the current project figures and explains the selected files in a short email.
Review the text before you send it. The button copies text only. It does not send an email, add recipients or attach files.
Every driver and every control device counts once. A floor's score is simply how many of them are finished, divided by how many there are.
The overall figure at the top of the dashboard is the same sum taken across the whole project, not an average of the floor percentages. A floor with 400 drivers therefore moves it more than a floor with nine, which is what people expect when they look at a site.
Why there are no weightings. The score used to give driver addressing a fixed 70% and each device category 10%. That meant a single presence detector counted as much as three hundred drivers, and every time a new category was added the weights quietly shifted for everyone. Counting items keeps the same intent — addressing still dominates, because there are far more drivers than anything else — without any figures to maintain.
Emergency lighting does not affect the score or Modules complete. An emergency result records the condition of an emergency fitting. A valid failure shows that the system reported the fault correctly; it does not mean that Delmatic commissioning is incomplete. Emergency results stay visible on their own card, drawings and report section.
The Emergency failure code guide explains every documented Lightscape result code. It explains the reported result but does not yet prescribe corrective work.
The emergency failures table on the website shows the sensor, drawing floor, functional result and duration result. Selecting its floor opens one focused sensor on the emergency drawing. The general emergency drawing is different: it keeps Lightscape's own colours for every sensor and is not changed by the website marker layer.
What the recorded count means. The emergency graphic is added only after the fitting has been addressed and its short address has been calculated. The portal can therefore count the addressed emergency devices that have been recorded. It cannot count emergency devices that have not yet been added, so it does not show an emergency addressing percentage.
The Issues page helps engineers find source errors without opening every drawing. It checks duplicate ordinary and emergency addresses, missing or repeated module graphics, repeated local controls and, after a controlled Lightscape proof, module group arrays.
Current issue is the default view. The side card names the check, module, short address and affected graphics. A static red exclamation marker identifies each proved drawing position for the selected fault.
Show markers starts on. Turn it off to inspect the original drawing under every marker, then turn it on to restore the same locations. The side card stays visible. Opening another issue or reopening the viewer turns the markers on again. Markers do not pulse.
What changed? is optional. It compares compatible Collector Snapshots to explain what changed before the issue appeared. It does not replace or resolve the current issue. For example, Unassigned → Short address 12 means that the graphic previously had no recorded short address and now has short address 12. It does not mean that an outstanding issue was fixed.
Two different questions. Current issue shows where the fault is now. What changed explains the earlier evidence that may have caused it. Snapshot history remains separate from the current fault.
| Marker | Meaning |
|---|---|
| Teal + | New progress. A recorded state moved forward, such as Unassigned to Short address 12. |
| Red ! | Fault location in Current issue. In What changed?, it means New fault: a fault appeared, or a previously good result became a fault. |
| Green check | Fault resolved. A fault shown in the earlier evidence is no longer present. |
| Blue dot | Tested again. A new test was recorded, but the result stayed the same. |
| Purple diamond | Drawing changed. A graphic was added, removed, renamed, or moved. This is not a pass or fail result. |
The phone navigation keeps Overview, Test, Issues and More close to your thumb. Destinations you cannot use are absent. Reports can be a primary destination for reporting roles. More groups End Visit, Closeout, Snapshot imports, Administration, help and account actions.
The portal remembers the last valid project, page and Test filters for each signed-in user. If access or source options change, it returns safely to the Overview. Reset remembered context removes preferences only; it never removes cached project data or results waiting to synchronize.
A result is held on this device for at least five seconds before upload. Choose Undo during that grace period to restore the exact previous state. After synchronization, make a correction by recording another result; synchronized history is never deleted. Next pending moves through the current floor, module and search scope without making the row under your finger jump away.
More on a device offers an optional quick reason, note and the existing online-only Reassign action. Queues belong to the signed-in user and project. A legacy queue is quarantined and needs explicit ownership confirmation before recovery.
Needs Attention is a bounded summary. Action Centre loads the detailed authorized worklist only when opened and groups or filters the same source evidence. Inspectly remains a summary link: the portal does not invent snag records it does not own. Zero, stale, unavailable, disabled and summary-only are deliberately different states.
Open Project Intelligence from the top navigation or from More. The page uses an immutable Project Update made from one successful synchronization. It shows the current value, change from the previous comparable synchronization, a seven-day comparison when one is available, evidence freshness, and known limitations. A baseline means that no earlier comparable update exists. It is not a zero change.
The Project Journal keeps site notes, decisions, risks and handovers beside system-generated update entries. Use search or the type, author, date, floor, module and linked-work filters to find an entry. A correction creates a new audit revision. Archiving hides a human entry from the normal list but does not delete its history.
Select human journal entries before you use Copy update, Download Markdown, or Print or save as PDF. All three outputs use the same authorized Project Update. Each output names its update, sync, scope, calculation version, freshness and limitations. A connection is required for journal changes and for a new export authorization check.
Reports offer Daily progress, Client progress, Engineering findings and Final handover presets. A copied link is live and authenticated: it grants no membership and contains no report data, notes, signed URLs or credentials. Browser Print / Save as PDF remains the supported PDF route. Direct PDF is deferred because the static browser implementation has not proved every parity, privacy, authorization, accessibility and reliability gate.
End Visit computes a dated draft from current authorized evidence. It never sends or stores a visit record automatically, and it says clearly when local results are waiting. Closeout checks current evidence without changing it. Its package includes a manifest and README, records omissions honestly, and fetches private drawings only through the existing authenticated no-store path. Print-only reports remain a separate explicit step.