Planner guide

The operating reference for the shipped 6.7.0 application. It describes what the screens do today. Anything not built yet is marked planned; do not rely on it. Search with the box below or use the contents.

What changed in 6.13.0

Reports open much faster: all drawings are read in one request and only what changed since your last visit travels; the result is kept for 2 minutes while you switch report tabs.
My profile (⋯ menu, or “My profile” in the top menu of every page): your full name, job title and mobile. Your name is shown everywhere instead of your e-mail.
Technical and Procurement are now their own pages in the top menu; Quality (QA/QC) holds WIRs, material submittals, MIRs and documents.
Registers: “which drawings does it cover?” lists networks (DU, LV, Storm…), not every stage drawing. Import your existing logs (Shop Drawing Log, Material Submittal Log) directly — the layout with the header on row 14, status A/B/C/D or UNDER REVIEW, revision, transmittal, discipline, sub-contractor, short / long lead.
The “newer version” message is a card at the bottom of the screen and no longer covers the top bar.

What changed in 6.12.1 (kept for reference)

Admin and the section menus show with ad blockers: the side menus used names that ad blockers hide; renamed.
Database: every table uses one text collation and existing tables are converted on start (fixes “Could not load drawings: server error” on MariaDB 11 / Hostinger).

This guide is updated in every release; the release build refuses to complete if the guide does not carry the release number and its “What changed” section.

Contents 1. First-time setup 2. Daily planner routine 3. Roles and permissions 4. Where to find things 5. Bulk drawing import and publication 6. Road stages and network organisation 7. Marking, corrections, inspection protection, work dates 8. Held progress and drawing revisions 9. WIRs: setup, statuses, QA/QC 9b. The WIR process (who does what)10. Programme and the Project pulse dashboard 11. Reports and cut-offs 12. Offline work, pending operations, phone recovery 13. Backup, restore, maintenance, upgrade, rollback 14. QS — what exists and its limits 15. FAQ 16. Implemented and planned 17. A tour of every screen 18. Productivity Analysis 18b. Today’s Crew 18c. Verification 22. Forgotten password 23. Quota exceeded (Firebase)24. Server and backups 25. Shop drawings 26. Technical · Procurement · QA/QC · Subcontractors 19. Glossary 20. Security and data protection 21. Relocation and precast scope

1. First-time setup

Who

The planner (the first planner is fixed in the configuration; others are given the role in Admin → Users).

Before you start

A company e-mail account, the 22 drawing packages (JSON files) and, if available, the WIR log (Excel) and the P6 export (.xer).

Steps

Open Admin and sign in. The tab bar is grouped: Daily (Drawings on site, Import drawings, Held progress, Programme, Users, WIR setup) and Maintenance (Backup & recovery, Test-data clean-up, Start fresh).
Import drawings: select all packages together (see section 5).
Users: engineers sign themselves up; give each person their role.
WIR setup: load your WIR log once so numbering continues from it.
Programme (optional): load the P6 export.
On a real phone, sign in as an engineer, open a drawing and mark one stretch; check that the planner sees it (Reports → Activity).

Expected

Drawings on site lists every network; the next-action strip at the top of Admin says Nothing is waiting for you.

If it fails

See the FAQ (section 15). Take a backup (section 13) before anything unusual.

2. Daily planner routine

Who

Planner.

Steps

Open Admin and read the next-action strip at the top — it names the one thing waiting (held progress, drawings ready to publish, or a failed publication).
If progress is held, open Held progress and decide each item (section 8).
Open Project pulse (dashboard) for the workfront picture: movement, obstructions, WIR queues (section 10).
Check Reports → Activity for the day's marks.
Once a week: both backups (section 13). Check Reports → Drawing comments (the draftsman is e-mailed automatically when notification is on).

3. Roles and permissions

Roles are stored on the server and set in Admin → Users. Permissions are enforced by the security rules as well as by the screens; a hidden button is not the protection.

Role	Can	Cannot
Planner	Everything in Admin; mark; correct protected work; open the dashboard; QS page	—
Site engineer, Construction Manager, Foreman	Mark (Done / WIP / Look-ahead / Erase / Undo), raise and cancel their own WIR before it is submitted, Blocked work, drawing comments, reports	Admin, QS, dashboard, lowering marks inside an inspected stretch
Document controller	Records the official submission to the Engineer and the Engineer’s decision; QA/QC console; WIR register	Admin
QA/QC	QA/QC console, WIR register, submit and decide WIRs, WIR documents	Admin, change a decided WIR
QS	QS page (provisional), reports	Mark, Admin
Management	Read-only reports and registers	Mark, Admin, dashboard (planner only for now)
Draftsman	Read-only; sees Blocked work and drawing comments and can resolve them	Mark, Admin

Dashboard policy. Project pulse is for the planner only. Management is refused by the page and by the server rule. To give management access later, the rules and page must be changed together and tested; do not give management the planner role to let them view it.

4. Where to find things

I want to…	Planner	Others
Mark progress	Drawing app	Drawing app (engineers)
Import / revise drawings, users, backups	Admin (header link, or ⋯ menu)	—
WIR register, documents	QA/QC (⋯ menu → QA/QC console, or the QA/QC link in any header)	QA/QC: the QA/QC console; engineers: WIR button in the drawing app
QS	QS button in the header / ⋯ menu	QS role: opens automatically
Project pulse	⋯ menu → Project pulse; Admin and QS headers	not available
This guide	Guide link in the Admin, QS and QA/QC headers	same

Drawing app — The drawing app: drawing and stage selectors, tools, Reports, WIR, work date and the ⋯ menu.

5. Bulk drawing import and publication

Who

Planner.

Prerequisites

Package JSON files (each contains the drawing data and its issued PDF). Rules published.

Steps

Admin → Import drawings. Drop or select all package files together.
Wait for each row to be checked. The line above the table must read: N selected = unchanged + ready + revised + invalid + in progress + published + failed. If it says the counts do not reconcile, do not publish; reload the page.
New drawings show ready: press Publish new drawings. All stage drawings of one network become visible together or not at all.
Revised drawings show revised with a plain explanation (geometry, type, specification, scale or the issued PDF changed). Press Update revised drawings after reading it.

Expected

Published rows say Published; an identical package says identical and is not offered again.

Partial success

If some networks fail and others publish, the published ones stay published; only the failed rows need another try, and already-published drawings are skipped. The next-action strip says so.

If it fails

The reason appears on the row and at the top of the Import panel. A failed group publishes nothing and releases its lock. If a publication was interrupted and the drawing stays "Updating — marking paused", use Release stuck lock on Drawings on site (FAQ). Another action running at the same time is refused with a message, not silently.

Import with reconciling counts — Bulk import with the reconciling count line.

A changed PDF with the same geometry is treated as a revision: marks carry over unchanged and the new PDF is published.

6. Road stages and network organisation

A network with construction stages (for example Excavation → Laying → Backfilling) is published as one drawing per stage with the same geometry (stage drawings share the network name). Roads are one group with five layer drawings (Subgrade, Subbase, Base, Binder, Wearing). Choose the stage with the stage buttons in the drawing app. Marking a later stage as Done also completes the earlier stages of the same stretch; one Undo reverses what that mark did. The stage percentages in the guide's earlier versions are not financial weights; financial weightage is set on the QS page.

7. Marking, corrections, inspection protection, work dates

Who

Engineers, Construction Managers, Foremen, planner.

Steps

Zoom in until marking is enabled. Choose Done, WIP or Look-ahead and drag along the stretch (lines), tap an item (chambers/points) or tap an area tile (roads).
Long runs: double-tap to select a whole run segment as supported by the tool.
Choose the work date in the header (today by default). It records when the work was done; a date in the future is refused.
Undo reverses your last mark (the label says what it will undo and survives closing the app).

How a mark looks

Marked stretch on a line — Green = done, amber = in progress, drawn exactly on the drawing line.

Inspection protection

Work inside a stretch covered by an active WIR cannot be erased or lowered by an engineer: the app refuses it and keeps the change for the planner to review; the server rule refuses it too. The planner can correct it. Marking Done inside the stretch is always allowed. Cancelling or rejecting the WIR releases the stretch.

Two engineers

Both marks are recorded as separate operations in order; neither overwrites the other. A correction that conflicts with a later change is kept for the planner (Held progress), not applied.

Expected

Immediate colour change on the drawing (local), then confirmation by the server (section 12). Marked work is drawn exactly on the drawing line: one straight stroke along the stretch you marked (green = done, amber = in progress, a wider pale band = look-ahead), square-ended at the exact start and end, and thinner when you zoom out so it never hides the drawing.

If it fails

A refused change is kept, never discarded: ⋯ → Unsent changes shows it; the planner sees held items in Admin.

8. Held progress and drawing revisions

Who

Planner (decides); engineers see only that work is held.

Why work is held

When a drawing is revised, marks on lines that did not change move with them automatically. A mark whose line changed (moved, re-shaped, different specification or scale, a road area whose polygon changed) is not guessed into a new position: it is kept as evidence in Held progress. Marks that arrive late for an older revision, and corrections that conflict with later work, are held too.

Steps

Admin → Held progress (the count is on the tab and in the next-action strip).
Read the item: where it was, what it was, the suggested new place if any.
Accept the suggestion, place it yourself, or leave it held. Nothing is deleted.

Expected

The count falls as you decide; carried progress plus held evidence always reconciles to the original records.

8b. Drawing comments and the draftsman’s e-mail

Who

Anyone who can mark raises a comment; the draftsman fixes it; the engineer verifies; the planner sets up the e-mail.

Raise

Comment tool → tap the place → choose the category and write what is wrong. It stays on the drawing until the draftsman fixes it and you verify.

E-mail to the draftsman

When notification is on, a new or reopened comment e-mails the draftsman immediately; fixed, closed or removed comments are taken off his list; every morning at 08:00 one e-mail lists everything still open; the e-mail has a link that opens Reports → Drawing comments. In Drawing comments, E-mail the draftsman about the open comments sends a reminder on demand (if the relay is not set up it opens your mail program with the list). If the phone is offline the notification is kept and sent when it reconnects.

Set-up (planner, once, about 10 minutes)

Open script.google.com → New project → paste the file Code.gs from the folder 9-Email-notification.
Project Settings → Script properties: TOKEN (a long random secret), TO (the draftsman’s e-mail), optional CC, SITE (the tool’s web address).
Deploy → New deployment → Web app → Execute as Me, access Anyone → copy the web-app URL.
Run setupDaily once (accept the permissions): this creates the 08:00 reminder.
In the tool: Admin → Users → Draftsman e-mail notification: tick on, paste the URL and the same TOKEN, Save, then Send a test e-mail.

Limits

The relay runs under the planner’s Google account, sends at most 60 e-mails an hour, ignores requests with a wrong secret, and decides the recipients itself. The tool cannot confirm that an e-mail was delivered (check the inbox and spam folder after the test). Google may add a footer to e-mails sent from a consumer account.

9. WIRs: setup, statuses, QA/QC

Setup (planner): Admin → WIR setup: choose your WIR log (Excel) once; the next number continues from it. Rebuild the coverage index after an upgrade or a restore.
Statuses: Draft → Ready for QA/QC → Submitted to the Engineer → Decided (A or B approved; C or D rejected). Cancelled WIRs keep their number. A rejected or cancelled WIR releases its stretch.
Engineer: Raises the WIR from completed work; can cancel it while draft or ready.
QA/QC (Office console): Submits, records the decision, can cancel or return a WIR; a decided WIR cannot be changed.
Coverage: Each raised WIR reserves its stretch (up to 8 inspections per asset are tracked); two WIRs cannot cover the same work.
Attachments: Open a WIR → Attachments → Add an attachment… (PDF, image, Excel or Word, up to 4 MB each) for test reports and sheets. Attachments can be added but not changed or removed; each keeps its checksum, who added it and when, and can be downloaded again. They are listed and downloaded in the tool; they are not merged into the WIR PDF.
Engineer’s signature: The site engineer draws a signature once (Draw my signature) and then presses Sign this WIR: a snapshot is copied onto that WIR (it cannot be changed afterwards) and printed in the Site Engineer signature box of the WIR PDF.
Evidence: A WIR remembers the drawing revision and the geometry fingerprint of its assets. WIR approval is an inspection result, not a payment certificate.

9b. The WIR process — who does what, so nobody conflicts

One WIR number, one owner at a time. The tool always shows who the WIR is waiting for (WIR detail → WIR process), and each person sees a “Waiting for you” banner at the top of the WIR list.

#	Owner	What they do in the tool	Done when	Next owner is told by
1	Site engineer	Marks the completed work on the drawing; creates the WIR from the marked work (the approved shop-drawing sheets are found automatically from where the work lies, with the location highlighted); fills the location, ITP/MS and checklist references; signs as ready (and signs with the signature image)	Status Ready for QA/QC	Hand-off e-mail to QA/QC
2	QA/QC	WIR → WIR process → QA/QC: compile: ticks the mandatory checks (shop drawing identified, ITP/MS reference, signed checklist) and the applicable ones (material approval, survey, test reports, photos, previous layer), adds references; adds attachments (test reports, photos). Can return to the site engineer with a reason	Compiled (name and time recorded)	E-mail to the QS
3	QS	QS → WIRs → Confirm BOQ codes…: the tool proposes the codes and quantities from the assets inspected and the BOQ items linked to them (units kept apart); the QS corrects, adds or removes lines and confirms. Can send back to QA/QC with a reason	BOQ lines saved on the WIR	E-mail to the document controller
4	Document controller (DC)	WIR detail → Download WIR (PDF) (one file: first page with the confirmed BOQ codes, checklist, shop drawings, attachments, signatures) → Record official submission: transmittal number, system/e-mail reference. The WIR moves to Submitted to the Engineer	Status Submitted	Closed in the pipeline (no more notices)
5	Engineer (client) / DC	The DC records the Engineer’s decision (A/B approved, C/D returned) when it comes back; a C/D WIR is resubmitted as a new revision by the site engineer	Status Decided	—

Rules that prevent confusion

Each step is written only by its role and only in order (enforced by the security rules: the DC cannot record a submission before the QS confirmed; QA/QC cannot confirm BOQ codes).
Sent-back WIRs show who sent them back and why; the earlier steps are cleared so they are done again.
A planner can always override (for example to submit urgently); every action is recorded with name and time.
Only one record per WIR: do not create the same WIR on paper and in the tool. Imported paper WIRs are marked paper.

Switching it on

Admin → Users → WIR process. Off (default): the steps are optional and the old direct submission by QA/QC still works — use this while the team learns it. On: the direct submit buttons are disabled until QA/QC and QS have done their steps (planner excepted). Tell the team the date it goes on. The enforcement of order for the three steps is in the security rules; the “must complete before submitting” is enforced by the screens.

Set-up

Create the document controller user in Admin → Users with the role Document controller (same access as QA/QC for WIRs). Add the e-mails of QA/QC, QS and DC to the relay script (TO_QAQC, TO_QS, TO_DC) so each gets a notice when a WIR reaches them, and a morning list of what is still waiting (older than 24 h marked overdue).

Suggested service levels

QA/QC compile: same working day · QS confirm: within one working day · DC submit: same day. The morning list shows what is overdue.

10. Programme and the Project pulse dashboard

Programme (Admin): load the P6 export (.xer); activities are linked to networks and stages. Project pulse (planner only) is a read-only snapshot: stage quantities by unit (metres, square metres and points are never added together), recorded movement over 7/14/28 days (current revision only), open obstructions by age, WIR queues, held-progress counts, and the next 14 days of linked baseline activities. It shows INCOMPLETE / STALE and withholds totals if any read failed. It is not a forecast, an overall percentage, SPI or a financial figure.

11. Reports and cut-offs

Who: Planner, managers, QA/QC and QS (tabs depend on the role).
Where: Drawing app → Reports. Tabs are grouped with icons: Progress (This drawing, All drawings, Activity, Area, Weekly report), Quality & site (WIR, Blocked work, Drawing comments), Commercial (QS).
Period: Choose Today / 7 / 14 / 30 days / This month / All time / Custom with the buttons, or type dates in From and To (typing a date switches to Custom). Period figures are by work date and count the current drawing revision.
Fresh data: Nothing reloads by itself while you read. Opening a report shows data read in the last 20 seconds, otherwise it reads again. The line at the top says when the data was read; after 5 minutes it turns red and asks you to press Refresh. Marks still unsent on phones are not in any report.
Engineer activity: Summary cards, completed per day, by drawing, then what each person recorded: person, drawing, stage, completed and in-progress quantities in their own units (raw, never weighted, never added across stages). Use Person to filter and Download Excel for the same rows. Click a row for the operation history: work date, recording time, asset, range, action (completed / in progress / erased / look-ahead set or cleared / migration placement), revision, who entered it. In-progress and look-ahead actions are listed separately and are not completed production. The stage-weighted summary is labelled as such.
Kerbs: In All drawings, below the kerbstones table, Kerbstones by type lists every recorded kerb type with quantity, completed, in progress, look-ahead and remaining, adding up to the kerb drawing.
Area: The map comes first; the quantities are in a collapsible table below it. Filters: Area (whole project, phase/stage, or a junction with a radius), Networks (tick the networks to show, All / None; the map, table, legend, Excel and PDF all follow), Stage (Overall, or one stage), and Look-ahead / Chambers / Road base on-off. Colours: line colour = network; band under the line: light green = completed, light orange = in progress, pale blue = look-ahead; road areas are filled the same way with thin boundaries. Overall view: completed = every stage of that network is done, in progress = at least one stage started or done. A single-stage view shows that stage only (for roads, each road layer — subgrade, subbase, base, binder, wearing — is its own row with its own geometry). Positions are real-world coordinates. Precision: progress ranges are exact (a 1.5 m mark inside a 2.5 m piece counts 1.5 m); the area boundary and junction radius are applied per piece of about 2.5 m by its middle point. Progress drawing (PDF) is the same map with the same legend and the per-drawing table.
Tables: Click a column heading to sort, drag the right edge of a heading to resize (double-click fits the content), Columns shows or hides columns, the filter box searches long tables. While a filter is active the total rows are hidden (they would not match the rows shown). Text wraps by default; it is only cut short in a column you have narrowed yourself. Your widths are remembered on this device; Reset widths and columns restores the default.
Limits: A report that cannot be calculated is shown in red, never as zero. A historical cut-off is applied by the server receive time.

12. Offline work, pending operations, phone recovery

What happens

Every mark is written to the phone's storage first (shown on the drawing at once), then sent. The red number on the ⋯ button counts changes not yet confirmed by the server. When the phone reconnects they are sent in order; each carries its own ID, so a retry or a lost acknowledgement cannot duplicate it.

Steps (phone)

Work as normal offline. Do not sign out and do not clear the browser's site data while the red number is above zero.
When connected, wait for the number to disappear.
If it does not: ⋯ → Unsent changes shows each item and why it is waiting (for example the drawing was revised, or the work is inside an inspection).
To rescue work from a phone: ⋯ → Unsent changes → export a recovery file; on another device sign in as the same person and use ⋯ → Restore a recovery file.

Limits

Storage on a phone can be cleared by the user, the browser or the operating system (low space, private mode, uninstall). The application cannot promise that offline data survives every device condition: keep the phone signed in, connect at least daily, and export a recovery file before anything unusual.

13. Backup, restore, maintenance, upgrade, rollback

Who: Planner.
Two backups, together: Admin → Backup & recovery: (1) Download backup — drawings, all revisions, marks, history, review items; (2) Download application data — WIRs and numbers, WIR log and Excel master, shop files, BOQ, rates, programme, obstructions, comments, QS data and audit. Neither contains user accounts (held by Firebase Authentication).
Restore application data: Choose the file; the tool compares it with the server by content and type, lists what differs, and writes only that. Issued and audit records are immutable: if the server's version differs from the file the restore is refused and nothing is overwritten. Counters are never lowered. It then re-reads and verifies. Pressing Restore again after an interruption continues safely. While it runs, non-planner WIR actions are blocked; if a restore is abandoned, press Release maintenance lock. Then rebuild the WIR coverage index.
Maintenance area: Test-data clean-up (needs Test mode; permanent) and Start fresh (removes drawings and marks) are in the red Maintenance group on purpose. Never use them on the live project.
Upgrade: See Deployment-and-Rollback-6.7.0.md: backups → website → rules → coverage rebuild → smoke test. The new version activates by itself once its files are verified; open tabs keep their own release until they are reloaded and are offered a reload; unsent marks are not touched.
Rollback: Redeploy the previous website build (and, if needed, the previous rules). Open pages are offered the change as an update. Data written by 6.7 stays valid; the previous rules refuse the 6.7 coverage format, so roll the rules back only together with the website.

14. QS — what exists and its limits

The QS page is provisional. Its figures are for discussion with the QS. They are not certified payment value and not the finished scope-to-BOQ workflow. Retention and deductions are not calculated.

QS page tabs: Estimates, BOQ (the tender BOQ in its own structure of parts, headings and items; Import BOQ… / Update BOQ… at the top; search, collapse headings, see what is linked to each item, and Link assets… from any item), WIRs (the inspection register by full reference and revision, with status filters, units kept apart, every BOQ component, evidence and a detail view), (A: work done and approved by WIR; B: work done not approved — WIR pending, rejected, no WIR), Assets & BOQ codes (code by size, type and level; measured quantity; further components), Tracker, Measurement sheets (copy / .xls / .xlsx / print), Unit rates (with reasons), Stage weightage (templates, request sheet, upload). Value = quantity × rate × stage weightage × share of the stage marked. A + B includes rejected work and is not accepted value.

Importing the BOQ (QS or planner): QS → BOQ → Import BOQ… (or Update BOQ…), choose the priced tender Excel (the “Part-…” sheets). The tool reads every priced line (numbered items, lettered sub-items (a), (b)…, items such as 10.15(A).1, provisional sums, the Dayworks section with its overhead additions, and priced lines without an item number), validates it and shows items, priced items, the contract total to two decimals, the totals by part reconciled with the workbook’s own General Summary (✓ per part and for the grand total), items without rates, and — when a BOQ already exists — new / removed / changed items, the money difference and which drawing links would be affected. Nothing is written until you press Replace the BOQ with this file; the replacement is all or nothing (one atomic step), so a failure leaves the current BOQ untouched. Drawing links, marks and WIRs are not changed. Management sees the BOQ read-only.

WIRs tab: each request is identified by discipline-number and revision (latest revision by default; tick include earlier revisions). “Covers” keeps units apart (for example 10.0 m · 1 nr; overlapping ranges counted once). “BOQ (current QS links)” shows every component currently linked to the inspected assets; “BOQ on the inspection” shows what was written on the WIR itself. Evidence is “all verified” only when every inspected item resolves on the drawing with matching geometry; items that no longer exist show as missing. A WIR whose decision is missing is shown as Decision missing, never as rejected. Click a row for scope, evidence per item, history and a link to the QA/QC console.

Four ways to link a BOQ item to assets (they never overwrite each other silently): Proposed by size / type / level; By hand (tick assets, assign a code); From a BOQ item (BOQ tab → Link assets…, or the button on the Assets tab: the tool reads the item's size, material and depth band and shows for every asset whether it fits and why not); From the Excel sheet. Every method goes through one check: a different link on an asset that is already linked is shown as a conflict and you choose keep, replace or cancel; the method is shown beside each link and recorded in the audit when you Save.

Held for review (the QS page says so): assignments made before stage-aware fingerprints, assignments whose drawing changed, and WIRs without geometry evidence. They are not valued until the QS reviews them (reason required, audit record). Value can therefore fall after an upgrade or a drawing revision; nothing is lost.

Not built: drawing-scope selection, split stretches / depth bands, quantity conversions, reviewed rates with versioned approval, frozen issued valuations, period earned value, retention and deductions. planned

QS estimates — QS page — Estimates (illustrative data).

17. A tour of every screen

Navigation is the same everywhere: Drawings · Reports · QS · QA/QC · Planner dashboard · Admin · Guide, shown according to your role (the drawing app keeps them in its ⋯ menu). Each destination still checks your role, and the server decides what is allowed.

Drawing app (everyone who works on site)

Header: Network (the drawing you are marking), Phase (limit what you see and work on to a phase), Programme activity filter, the work-date chip (the date your marks will carry; tap to change; a date in the future is refused), Reports, WIR, QS (planner and QS), PDF (progress drawing, or all drawings as a ZIP as of a date) and the ⋯ menu.
Toolbar: Move (pan and zoom), Done (green), In progress (amber), Look-ahead (pale blue: planned next), Erase, Blocked (record an obstruction on a stretch), Comment (a drawing comment) and Undo. Zoom in until marking is enabled.
⋯ menu: Progress drawing (PDF); All drawings as a ZIP as of a date; QS / Valuation; QA/QC console; Admin (planner); Planner guide; Unsent changes (what is stored on this phone and not yet confirmed, with the reason, and the recovery file export); Restore a recovery file; Sign out.
Save status: The red number on ⋯ counts changes not yet confirmed by the server. Marks appear on the drawing at once; confirmation follows.

Reports (drawing app → Reports, or “Reports” in the navigation)

Tab	What it answers	Notes
This drawing	Asset-by-asset progress of the open drawing	Sort, filter, resize, show/hide columns; export
All drawings	Quantity, completed, in progress, look-ahead, remaining, progress bar and chambers for every drawing; kerbs by type	Utilities, road areas and kerbs in separate tables; units never added
Engineer activity	What each person recorded, per drawing and stage; operation history	Raw quantities; the person who entered it, not the crew
Productivity (planner only)	Output per drawing/stage by work date: per active day, per calendar day, best day, 7/28-day rates, trend, target, per person-day	See section 18
Area	Map of any phase or junction: networks, progress bands, look-ahead	Pan with drag, zoom with the wheel (or + −); ticking options keeps your zoom; double-click or Fit to reset; labels appear when zoomed in; Show: Completed / In progress / Look-ahead / Not started filters; Custom area: choose Draw rectangle or Draw circle and drag on the map — the table and PDF follow; the table is split by stage names (for example 1 Excavation → 2 Laying → 3 Backfill; road layers separately)
Weekly report	The week's summary	Uses the same period and cut-off
WIR / Blocked work / Drawing comments	Registers with filters	Decisions are made in the QA/QC console
QS	Opens the QS page	One QS workspace

Tables everywhere

Every report table can be sorted (click a heading; in tables with group headings the rows are sorted inside each group), resized (drag the heading edge), shown/hidden by column, and has Filters (a box under each heading: text, !not, =exact, numbers such as >10 or 5..20), Compact rows, Freeze 1st column, Views (save a set of filters, hidden columns and widths under a name) and Export (the rows and columns shown, as Excel). The line above the table says how many rows are shown and gives the totals of the rows shown (kept apart by unit); the table’s own total rows are hidden while a filter is on, so a total is never misleading.

QS (planner, QS; management read-only)

Estimates (A approved by WIR, B not approved, held items), Assets & BOQ codes (link assets to BOQ items by the four methods; level, measured quantity, further components), BOQ (import/update, structure, linked quantities, Link assets…), WIRs (register), Tracker and Measurement sheets (the QS team's formats), Unit rates (BOQ prices), Stage weightage, How it works. All figures are provisional.

QA/QC console (QA/QC, planner)

Overview (the queue that needs action), WIR register (view and decide permitted requests), Documents (shop drawings, MSS/ITP). Numbering and WIR-log import are planner settings under Admin → WIR setup.

Admin (planner)

Daily: Drawings on site (what engineers can open, revision, review items, stuck-lock release), Import drawings (bulk import and publication with reconciling counts), Held progress (decide held records), Programme (P6 .xer), Users (roles), WIR setup (WIR log, coverage index).
Maintenance: Backup & recovery (both backups, typed restore, maintenance-lock release, QS records inventory), Test-data clean-up and Start fresh (destructive; never on the live project). A strip at the top says the one thing waiting for you.

Planner dashboard (planner only)

Read-only snapshot: movement, obstructions, WIR queues, upcoming baseline activities. It shows INCOMPLETE / STALE when a read failed and never shows a forecast or an overall percentage. Management access is a separate policy decision.

Recovery page

“Recover device changes” (from ⋯ → Unsent changes): explains pending versus blocked operations, lets you export the evidence, retry, or import a recovery file. It is not a project backup.

18. Productivity Analysis (planner only)

Who

Planner only: the screen is hidden from everyone else and the plan, norms, rates and calendar are stored in a place only the planner can read (plannersettings). Site engineers, foremen, the timekeeper and the plant coordinator see only the crew records they need for their own duties (section 18b–c).

How it is organised

Filters at the top (from / data date, network, work area, stage, crew, verification) apply to every tab. Overview: five decision tiles and one compact row per activity (a drawing and stage in one unit): progress with a plan marker, variance, output needed vs doing per day, forecast finish, labour efficiency, share of checked records. Click a row to expand: cumulative plan vs actual, daily output vs needed output, direct man-hours by trade, equipment by type, lost time by reason, crew comparison and key figures — each chart ends with the decision it supports, and a sentence in words says what to do. Other tabs: Crews & resources, Lost time, Data confidence (flags, missing submissions, verification mix), Corrections, Setup, Export.

The rules of the calculation

Output comes from the marks by work date. When several crews are allocated to one activity on the same day the output is shared in proportion to their allocated direct person-hours; nothing is counted twice. Output with no crew record is shown as not attributed, never invented.
Direct and indirect manpower (indirect trades are set in Setup: foreman, chargehand, surveyor, traffic controller…) are kept apart; the norm is compared with direct man-hours only. Shifts of different lengths are respected (hours per crew-day).
Equipment is analysed per type with its own operating hours; different machine types are never added together, and different units (m, m², nr) are never combined.
Lost time = hours × people affected, by reason; it can never exceed the hours available (the record is flagged); a day whose reasons cover the whole shift is a stoppage day, excusable or not by the setting.
One duplicate rule for every report: one record per crew and day (highest revision wins); old 6.7.x cards: one per drawing, day and crew name (latest wins).
Corrections: negative quantities reduce the total and are reported; the Corrections tab lists erasures and back-dated marks, and snapshots show any past day whose quantity changed after the weekly review.
Verification filter: analyse everything reported, only reconciled-or-better, or only supervisor-checked records.

Getting started

The checklist at the top of the Overview shows, in order: baseline programme imported · drawings linked to baseline activities · calendar (from the baseline) · norms (from the baseline resource loading) · crews · daily reports in the last 7 working days · checks by timekeeper / plant / supervisor. Each item opens the place where it is set.

Baseline calendar and resources

Admin → Programme reads, from the .xer, the calendar used by the construction activities (working days, hours, holidays) and every resource with its hours on each activity. Re-import the .xer once after updating to 6.9.0. In Setup → 1 choose Use the baseline calendar (default) and add any extra holidays. In Setup → 2 map each P6 resource to the trade or machine the site reports (a match is suggested); the norm of a line = baseline hours of the mapped resources ÷ baseline quantity. The Norms window shows every resource on the line’s activities, its baseline hours and hours per unit; you can keep the baseline figures or type your own.

Resources — plan vs used

Week by week, the labour (and machine) hours the baseline loads on the activities in the selection, against the hours the crews reported. The decision line tells whether the shortfall is resources (mobilise / re-allocate) or productivity (look at lost time and efficiency).

Setup

Crews (permanent ID, name, direct or subcontractor, supervisor, team who may report, usual activities); plan per activity (budget, start, finish, norms per direct trade); working days (Sunday–Friday by default), hours, tracking date (earlier work and pre-loaded work are the baseline), holidays (button for the UAE public holidays 2026–2027 — Eid dates are estimates), trades, indirect trades, equipment types, fleet, lost-time reasons, excusable reasons, rates per hour. Old crew cards and the old settings are kept: they are read as “legacy” records and migrated into the planner-only settings the first time you open the analysis.

Export

Detailed Excel (activities, crew-days with verification status, trades, equipment by type, lost time, flags, plan and norms, settings) and the daily progress report for a chosen day. Planner only.

Plan from the baseline

Where the drawing and stage are linked to the approved baseline programme, the planned curve is the sum of those activities (each spread over its own working days, with its quantity when the unit matches); the work pre-loaded from the drawings is the opening quantity. Setup shows “baseline (n activities)” per line and lets you switch to typed dates.

Limits

Lines without a baseline link use a straight line between the typed start and finish. Labour utilisation, rework, safety incident rate and planned equipment hours are not calculated. The reported hours of a crew are as accurate as the people who report them: use the verification and the data-confidence tab before relying on a figure. Crew records can be read by site engineers, foremen and the verifiers (they need them for their duties); the plan, norms and rates cannot.

18b. Today’s Crew (site engineers and foremen)

Purpose

Say which crew worked, with whom and what, on which work, for how long — and nothing else. Quantities are taken from the drawing progress; you never enter them and you never recreate a manpower list per drawing.

Steps (phone)

Open Crew (button beside the work date) or ⋯ → Today’s Crew. Tap your crew (a permanent ID such as C-014; you see the crews assigned to you).
The page starts from yesterday’s crew. Nothing counts until you confirm it for today: tap Everything as listed — confirm, or confirm people, equipment and work one by one. Anything different today: tap − / + (more trades and machines are under “Add other…”).
Work and hours: the usual activity and the shift hours (full / half / other). If the crew also worked on another activity tap + Split (or Split 50/50): the hours are shared, never doubled.
Did anything stop work? Open it only if so: reason → hours → who was affected; add as many reasons as applied.
Submit. The page shows Saved ✓, Pending (kept on the phone and sent automatically when there is a signal) or Failed with the reason and a Try again button. Nothing is dropped silently.

Good to know

Yesterday’s verification or approval is never copied — each day is checked afresh. Editing today’s record creates a new revision and needs confirming again; if someone else changed it first you are told instead of overwriting. Unsent records belong to the account that made them: on a shared phone another user cannot send or lose them. A red dot on Crew after 11:00 means a crew has not reported today. Marking progress is completely independent of this page.

Target

An unchanged crew is three taps (crew → confirm → submit), about 15–30 seconds. The tap count and a scripted time were measured on a phone-sized browser; a trial with real foremen on real phones is still to be done (see the review response).

18c. Verification of crew records

Who: Timekeeper checks manpower against the attendance records; plant coordinator checks equipment against the asset and operating records; the crew’s supervisor (foreman or construction manager) reviews the work allocation; the planner can do all three. Create these users with the roles Timekeeper and Plant coordinator in Admin → Users. They can open ⋯ → Verify crews and nothing of the analysis; they cannot mark progress.
Status: Reported = entered on site. Reconciled = manpower (and equipment, if any) checked at the current revision. Supervisor-checked = the allocation was reviewed as well. If the timekeeper or plant coordinator enters different figures, their figures replace the reported ones in the analysis (the reported ones are kept). Editing a checked record (a new revision) sends it back to Reported with a STALE flag until it is checked again. “Return…” sends a record back to the submitter with a reason.
Flags: DUP same activity twice, or two crews reporting exactly the same people on the same activity · HRS allocated hours above the shift · LOST lost time above the available hours · EQ machines of one type reported above the fleet · STALE edited after checking · ALLOC no activity · and the list of crews with no submission for the day.
Independence: These checks never hold up progress marking, and unresolved checks do not stop anyone recording completed work. The analysis can be filtered to checked records only.

22. Forgotten password

First

Firebase’s reset e-mail comes from noreply@a018-ca2fb.firebaseapp.com and is often filtered by company mail. Ask the user to look in Junk / Spam / Quarantine and to search for “firebaseapp”.

Planner tools (Admin → Users → Forgotten password)

E-mail him a reset link: your Google account sends the link, which normally reaches the inbox. Set a temporary password…: the tool generates one, sets it, shows it to you once (give it by phone or message; it is not e-mailed or stored) and marks the user so that he must choose his own password at his next sign-in.

One-time set-up (about 10 minutes)

Update the relay script with the new Code.gs (9-Email-notification) and add the script properties ADMIN_TOKEN (a second long secret that only you know — not the TOKEN, which the staff-readable settings contain), FIREBASE_PROJECT (a018-ca2fb), ALLOW_DOMAIN (agilityecc.com) and optionally PROTECTED (e-mails that can never be reset this way, for example yours).
Project Settings → show appsscript.json and add the oauthScopes listed at the top of the password-help section of Code.gs; deploy a new version. The Google account that owns the script must be an Owner / Firebase Authentication Admin of the Firebase project.
In Admin enter the user’s e-mail and the admin secret (kept in this browser tab only) and press the button.

Everyone

⋯ → Change my password…. If Firebase says the sign-in is too old, sign out, sign in again and retry.

Last resort

Firebase console → Authentication → the user → Reset password (sends the same e-mail), or delete the account and let him register again (his role must then be set again in Admin → Users; his earlier marks stay in the ledger under the old identity).

Limits

These planner tools use Google’s identity API through your mail relay and could not be tried against Google from the build environment: do one test with a spare account before relying on them. A wrong admin secret, an e-mail from another domain, or a protected e-mail is refused; every use is logged in a Google Sheet A018 admin actions in your Drive.

23. “Quota exceeded” — the database’s daily limit

What it is: The project runs on Firebase’s free Spark plan: about 50,000 document reads and 20,000 writes per day for the whole project. When either is used up, every save and every read fails with “Quota exceeded” until the counter resets at midnight Pacific time (around 11:00 UAE time). It is not Cloudflare and not a fault in your data; marks waiting on phones are sent after the reset.
What 6.8.1 changes: Opening Reports or a drawing used to re-read every mark ever made on the drawings. Now each phone and computer keeps the history and asks only for what changed. For the biggest saving, create the composite index once (Firebase console → Firestore → Indexes, or firebase deploy --only firestore:indexes with the supplied firestore.indexes.json): collection = each …_log collection, fields ver ↑, receivedAt ↑. Without it the app still works; it just re-reads a changed drawing completely.
Recommended: Switch the Firebase project to the pay-as-you-go Blaze plan and set a budget alert (for example USD 10 a month). The free allowance stays; beyond it reads cost about USD 0.06 per 100,000 — a busy day on this project is a few cents. Then “Quota exceeded” cannot stop the site.
If it happens: Engineers keep marking (marks wait on the phone). Avoid opening Reports repeatedly; the dashboard and the Productivity Analysis are the heaviest pages. After the reset everything is sent automatically.

24. The server, accounts and backups

Where it runs: On the Hostinger Unlimited plan as a Node.js web app with a MySQL database. The same server serves the pages and the data. Set-up and updates are described step by step in DEPLOY-HOSTINGER.md in the release package.
Accounts: People sign up on the sign-in page with their company e-mail; the planner then gives the role in Admin → Users (as before). Passwords are stored only as salted hashes. A forgotten password is reset by the planner (Admin → Users → Forgotten password); the person must choose his own at the next sign-in.
Backups: The server writes a full backup (all documents and accounts, compressed) every day and keeps the last 21. Hostinger also keeps its own daily backups. Download a copy to your computer or Drive once a week from the File Manager (folder backups) — Hostinger’s terms make you responsible for your own copies.
If something goes wrong: hPanel → Websites → the Node.js app → Restart. The log file shows errors. To go back to a backup, see “Restore a backup” in DEPLOY-HOSTINGER.md.

25. Shop drawings and how they connect

The chain

Shop drawing approved (A/B) → its PDF uploaded and calibrated → the site marks the work on the drawing in the tool → the WIR proposes the approved sheet(s) that cover the marked work and highlights the work on them → QA/QC → QS → document controller → the approved WIR makes the work Estimate A in QS. A drawing still under review, coded C or D, or superseded is never proposed for a WIR.

Who

The technical engineer and the draftsman keep the register and upload approved PDFs; QA/QC can do everything; everybody else sees the status.

Steps

QA/QC → Shop drawings → Register → Import the shop drawing log (Excel) once (columns like Drawing No., Title, Rev, Status/Code, Submitted, Returned, Transmittal), or + New shop drawing. Tick the drawings in the tool that it covers.
Open a row → Record the submission (date, transmittal) → The consultant is reviewing → Record the consultant’s code. C or D: correct it and record the next submission (a new revision is started automatically).
A or B: Upload the approved PDF → then Calibrate its sheets (two known coordinates per sheet) in Approved sheets & calibration.
Approved again in a newer revision: upload that PDF; the older one is marked superseded automatically.

Priority

The register reads the approved baseline: the earliest planned start of the work a shop drawing covers is its needed-by date; with the consultant’s review days (and a week of preparation when not yet submitted) it gives a submit-by date. Critical = work within 14 days or submit-by passed; High = within 45 days. Tick the drawings each shop drawing covers, otherwise it shows “No baseline link”.

Watch

“My queue” lists the critical drawings, reviews that are overdue (after the review days set per drawing, 14 by default), drawings to revise and resubmit, and approved drawings without a PDF (WIRs cannot use them yet).

26. Technical · Procurement · QA/QC · Subcontractors — how they connect

The material chain: QA/QC: material submittal approved (A/B, and by the authority when required; long-lead materials are dated earlier: submit-by = work start − supply lead time − review days − authority time) → Procurement (by Agility or a subcontractor): material line ordered against it (the tool warns if it is not approved), order-by date = start of the first baseline activity on its drawings − lead time − 7 days → delivery → QA/QC: MIR raised and inspected against the approved submittal → accepted quantity counts as material on site; rejected quantity is shown to procurement for replacement.
The drawing chain: Shop drawing approved → PDF calibrated → work marked → WIR proposes the approved sheet → QA/QC → QS → DC → Estimate A.
Readiness: Procurement → Readiness board joins both chains for the next 30 days of the baseline: an activity is Ready when its shop drawings and material submittals are approved and its material is accepted on site; Blocked when it starts within 7 days without approved drawings or material; otherwise At risk, with what is missing. The links come from the drawings ticked on each register line, so tick them.
Subcontractors: 1 · He signs up with his own e-mail. 2 · Planner: Admin → Users → Subcontractor access: choose him, name the company, tick his drawings. 3 · He marks those drawings as usual; each stroke is sent as a claim and shows as purple dashes for him and the engineers. 4 · Site engineer: ⋯ → Subcontractor claims → open the drawing → Confirm (it becomes progress recorded by the engineer, noting the claim) or Reject with a reason. Unconfirmed claims never count in reports, WIRs or QS.

19. Glossary

Term	Meaning
Work date	The date the work was done (set by the engineer); distinct from the time the server received the mark.
Piece	A stretch of about 2.5 m of a line; marking and area boundaries work in pieces. Progress ranges themselves are exact.
Stage	A construction step with its own drawing (utilities: excavation, laying, backfilling; roads: subgrade to wearing course).
Look-ahead	Work planned next; shown in pale blue; never counted as production.
Held progress	Marks kept as evidence when a drawing change cannot be mapped safely; nothing is deleted.
WIR	Work inspection request; A/B approved, C/D rejected. Approval is an inspection result, not a payment certificate.
Coverage	The stretch reserved by an active WIR; work inside it cannot be lowered by an engineer.
Estimate A / B	QS value of work approved by WIR / not approved. Provisional.
Active day	A work date with output on a given drawing and stage.
Fingerprint	A summary of a drawing asset's geometry used to detect that it changed.

20. Security and data protection — what protects the tool, and what does not yet

How it is built

A static website (Cloudflare) plus Firebase Authentication (e-mail and password) and Firestore. The tool has no server code of its own: all protection is Firebase sign-in plus the security rules published in Firestore. The Firebase web key inside the site is public by design; it identifies the project, it is not a password.

In place

Every read and write is checked on the server by role (planner, engineer, QA/QC, QS, management…); disabled accounts lose access; hiding a button is never the protection.
Engineer progress is an append-only ledger (each operation has an id, author, work date and server time). Issued and audit records are immutable. Inspected work is protected from erasure. Restores are verified and never overwrite issued/audit records.
The website is served with release-addressed, hash-verified files, so a tampered or half-deployed release is refused by the phone. Pages send nosniff, frame-deny and a strict referrer policy.
User text is escaped before it is shown; there are no third-party scripts except the fonts.
Unsent marks stay on the phone until confirmed; recovery files are only for the same signed-in user.

Not yet in place (be aware)

The security rules have not been run on an emulator by us. A rules mistake could expose or block data. Run the supplied emulator tests before every rules change.
No multi-factor sign-in for planners/admins in the tool; no App Check (proof that requests come from the real app); no Content-Security-Policy header.
Anyone can create an account; new accounts are engineers by default and can read project data that engineers can read. Check Admin → Users regularly and disable people who left.
Backup files and recovery files are unencrypted files on the planner's or the phone's storage. A lost phone with unsent marks exposes those marks.
The free Firebase plan can be exhausted by heavy use or by an attacker (availability, not confidentiality); there is no automatic alerting.
No independent penetration test, no log monitoring or intrusion alerts, no written retention policy, and the e-mail relay URL and token (comments) are shared secrets stored in the project settings.

Recommended hardening, in order

Run 7-Rules-tests on the Firebase emulator; publish rules only when every case passes.
Protect the accounts that matter: strong unique passwords and 2-step verification on the Google/Firebase console and Cloudflare accounts and on any shared planner mailbox; keep the planner list in the configuration short.
In Firebase: restrict the API key to the site's address, set budget and usage alerts, and turn on App Check when practical.
Store the weekly backups encrypted (for example in a password-protected archive in company storage) and test a restore every quarter.
Offboarding: disable the user in Admin → Users the same day; for a lost phone, disable the account, then re-enable after a password reset.
If you suspect a breach: disable suspicious users, change the planner passwords, rotate the e-mail relay token, take both backups, then review Admin → Users and the audit records; restore only verified content.
Before wider roll-out: an independent security review/penetration test and a written data-retention and access policy.

Honest summary

For a controlled pilot with named users the design is sound (server-side role rules, append-only records, verified releases). It is not yet hardened to the level of a public internet service: do not treat it as breach-proof, and close items 1–3 before the pilot.

21. Relocation and precast scope — how they are treated today

Relocation

The drawing packages contain relocation items as ordinary line elements with a type name: Relocated Cable — reused street-light cable (street lighting, 74 lines) and MV Cable — 22 kV relocated cable (MV, 10 lines). They are marked, reported and valued exactly like any other cable of that network (progress by stage, WIR, BOQ link by type/size). There is no separate relocation workflow yet: no disconnect → relocate → reconnect/energise → utility-owner acceptance sequence, no separation of “existing” from “new”, no owner-approval or outage tracking.

Precast

No precast item is named in the packages. Chambers, boxes and structures are tracked as counted points (nr) on their network and marked done at the network's stage; supply, casting, delivery and installation are not tracked. “Protection slabs” appear as line items (type Protection Slab); whether they are cast in place or precast is not stated.

What I recommend

List the relocation and precast BOQ items and the contract's definitions (what counts as relocated, what is precast).
Keep engineer marking as it is, and add a small status-step register for these items: designed → ordered → manufactured/available → delivered → installed → inspected (WIR) → accepted/energised, with the owner or supplier, planned and actual dates — separate from the progress ledger so nothing about marking changes.
Link the register to the BOQ items and to the dashboard (late deliveries, items blocking installation).

Until then

Use the type name to filter relocation items in the reports and the BOQ linking; track precast delivery outside the tool (supplier schedule).

15. FAQ

Why does a WIR not offer the shop drawing I expect?

Only approved (A/B), current revisions with an uploaded and calibrated PDF are offered. Check its row in QA/QC → Shop drawings → Register: under review, C/D, superseded or “approved without PDF” are not offered.

I cannot sign in after the move to the new server

Use the temporary password the planner gave you; you will be asked to choose your own. If you lost it, the planner sets a new one in Admin → Users → Forgotten password.

Where do the calendar and the norms in Productivity come from?

From the approved baseline: the P6 calendar (work week, hours, holidays) and the resource loading of each activity. Re-import the .xer in Admin → Programme once; Productivity → Setup shows what was read and lets you add holidays or override a norm.

What is “Resources — plan vs used”?

It compares the labour and machine hours the baseline loads on the selected activities with the hours your crews reported each week, and tells you whether you are short of resources or short of productivity.

“Quota exceeded” when saving a WIR or a comment

The project’s free Firebase daily limit was used up. It resets around 11:00 UAE time; switching to the pay-as-you-go plan removes the problem (section 23).

There are small gaps in a finished line

Those pieces run inside a crossing duct and are counted with the crossing. Since 6.8.1 they show the colour of the line on both sides; tapping one explains it.

Where does the planned curve in Productivity come from?

From the approved baseline programme (Admin → Programme) wherever the drawing and stage are linked to it — the activities’ dates and, when the units match, their quantities. Otherwise from the dates typed in Productivity Analysis → Setup.

An engineer forgot his password and the reset e-mail never arrives

The Firebase e-mail is often filtered. Use Admin → Users → Forgotten password: e-mail a reset link from your own Google account, or set a temporary password that he must change at first sign-in (section 22).

Why can’t the foreman just copy yesterday’s crew?

He can start from it, but today’s record needs his confirmation, and yesterday’s verification is never copied: each day is a separate record that is checked on its own.

My crew worked on two activities today

On Today’s Crew tap + Split (or Split 50/50). The shift hours are shared between the activities; the output of each activity comes from the drawing progress.

The page says Pending or Failed

Pending: the record is kept on the phone and sent automatically when there is a signal. Failed: the server refused it — someone else changed the crew’s record, you are not assigned to the crew, or the security rules are not published; open the crew again and review. Nothing is deleted; use “Try again”.

Two crews work on the same activity — is the output counted twice?

No. The day’s output of that activity is shared between the crews in proportion to their allocated direct person-hours.

Why is a figure “not attributed”?

Output was marked for a day on which no crew record allocates hours to that activity. It is shown separately rather than guessed.

I edited a record that was already checked

It becomes a new revision, drops back to “Reported” and shows STALE until the timekeeper, plant coordinator and supervisor check it again.

Who can see the productivity analysis, the plan, norms and rates?

Only the planner. Crew records themselves can be read by site engineers, foremen and the verifiers (they need them for their duties), but they cannot see plans, norms, rates or any analysis.

A past quantity changed — how do I know?

Take a snapshot in Productivity Analysis → Corrections after each weekly review. Later, the same tab lists every past day whose quantity differs from the snapshot, plus erasures and back-dated marks from the ledger.

"Permission denied" or "the server refused this"

Your role does not allow that action, your account is deactivated, or the newest security rules are not yet published. Check Admin → Users. Do not give someone the planner role to get around it.

A drawing is slow to open or unavailable

Unavailable: a planner update is in progress (marking pauses and resumes) or the drawing is not published. Slow: first load of a large drawing on weak signal; the second open is faster. If it never opens, reload; unsent marks stay on the phone.

Some progress is "held" — is it lost?

No. It is kept as evidence because the drawing changed. Open Admin → Held progress and decide each item (section 8).

My marks look missing

Check the work date and stage buttons first (marks belong to a stage drawing and a date). Then ⋯ → Unsent changes (not yet confirmed), then Reports → Activity (confirmed). A drawing revision may have held a mark.

The red number does not go down

Reconnect and wait. ⋯ → Unsent changes says why each item waits. Do not clear site data or sign out. Export a recovery file if in doubt.

An "Update now" bar appeared

A different version of the app is available (a new release or a rollback) and is already active for new pages. (Nothing on a report page reloads by itself.) Finish what you are doing, then reload. Unsent marks are not touched. An already-open tab keeps working on its own version until it is reloaded.

A bulk import was partly successful

Read the reconciling line and the row messages. Published drawings stay published; fix the failed rows and publish again; published ones are skipped.

Restore failed or "NOT VERIFIED"

Press Restore again — only documents that still differ are written. "REFUSED… immutable record" means an issued or audit record on the server differs from the file; do not force it; ask for a review.

A report or the dashboard says INCOMPLETE

A read failed or a drawing changed while loading. Totals are withheld on purpose. Refresh; if it persists, check Admin and connectivity.

QS values changed after an update

Held assignments or WIR evidence are not valued until the QS reviews them (section 14). Review them on the QS page; nothing was deleted.

A drawing says "Updating — marking paused" for a long time

A publication was probably interrupted (page closed, power cut). Check that nobody is publishing, then Admin → Drawings on site → Release stuck lock on that drawing. Nothing half-published becomes visible; marks queued on phones are then sent. A publication that is really still running will stop with an error and publish nothing.

The page shows ERR_FAILED / "This site can’t be reached" unless I force-reload

This was a defect in versions 6.6.2 and 6.7.0 (fixed in 6.7.1). Press Ctrl+Shift+R once (phone: reload twice); the fixed version then replaces the faulty one by itself. Your unsent marks are not affected and nothing needs to be cleared.

The Area map shows each road layer separately

The road layer drawings do not have identical geometry (subgrade and subbase have more areas than base, binder and wearing), so each layer is shown with its own geometry and its own row. Choose Stage to look at one layer.

A WIR says “missing” items

Some assets that the inspection covered no longer exist on the current drawing (for example after a revision). The request is not treated as verified until you review it; nothing is deleted.

Where did “Office” go?

It is called QA/QC everywhere. The old address still works. QS is its own destination.

Admin ignored my click

Another action was still running; Admin says so at the top of the panel. Wait for the working bar to disappear and try again.

16. Implemented and planned

Area	Status
Marking, Undo, offline queue, recovery file	implemented
Held progress for drawing revisions; all-stage atomic publication	implemented
WIR workflow with server-checked coverage; protected corrections	implemented (rules must be verified on your emulator before pilot)
Backup / typed restore / maintenance lock	implemented
WIR pipeline with document controller role, QS-confirmed BOQ codes, hand-off e-mails, attachments merged into the PDF	implemented (WIR-process rules must be published; enforcement is optional)
One-click DC submission package (ZIP + transmittal sheet), checklist templates per discipline, WIR cycle-time dashboard, Aconex integration	planned
Draftsman e-mail for open comments; WIR attachments; engineer signature; quick crew entry; stage-weightage bars; recovery page guidance	implemented (new rules and the e-mail relay must be set up / published first)
Crew card for engineers and foremen; daily progress report from the cards; baseline; custom area on the Area map; dynamic tables	implemented (the crew-card rules must be published)
Productivity report with targets and crew logs; engineer activity; kerbs by type; Area map with pan/zoom	implemented (crew-log rules must be published)
Project pulse (planner only)	implemented
QS page (provisional)	implemented, provisional
QS scope selection, splits, conversions, versioned approvals, issued valuations, retention / deductions	planned
Management read-only dashboard; period production across revisions; reporting cut-off tool	planned