Twinview: an office board

What it puts on the wall

Three tiles, which compose into the board a facilities office actually wants: how much is open, what is open, and how it breaks down.

• Board numbers — open tickets, issues and jobs as figures readable across a room, plus the longest anything has been waiting.
• Board list — what is open, longest-waiting first, with its Twinview reference, priority and owner. Can be narrowed to only what is late.
• Board breakdown — a bar chart split by priority, status, category, owner, service level, or how long things have waited.

Mirra only ever reads. Nothing in this integration can close a ticket or move a job, which is the property that makes it safe to hang a board in a corridor.

Connecting

1. Find your project's API address

   Twinview does not publish one — its own documentation ships the field blank — so it is whatever your installation lives at. Leave off any trailing /project; Mirra adds that itself.

2. Get a project API key

   From your Twinview project's own settings. It is a project key, not a personal login.

3. Enter both on Integrations, then Twinview

   Mirra dials the project before saving. A key that does not work is refused here rather than becoming a board that is silently empty on Monday morning.

4. Press Read again whenever you want fresh figures

   The board is drawn from a cached copy, refreshed by this button. Paging a large project every time a wall display redraws would put hundreds of requests an hour on your API.

Changing the key later does not mean disconnecting. Press Change key — the new one is checked before it replaces the old, so a typo leaves the board working on the key it already had.

Only open work, and only some of it

Mirra keeps the open tickets, issues and jobs. Closed work drops out of the cache rather than being counted, which is what makes "closed today" impossible to show and is worth knowing before somebody asks for it.

A very large project is read in pages, and there is a limit to how many Mirra will fetch in one go. When that limit is reached the connection says so — "400 jobs open — showing the first pages of 1681 jobs" — rather than quietly showing you part of your project as though it were all of it.

If your board is showing a truncated count, the numbers on the wall are a floor and not a total. The connection page is the only place that admits it, so it is worth a look after the first sync of a big project.

What "this week" means

Every period on the board — today, this week, this month, this quarter — goes by when work was raised, not when it is scheduled. That is not a preference; it is the only date a Twinview project reliably returns. No ticket, issue or job carries a due date, and the planned duration on a job came back as zero on every one of eighty sampled from a live project.

Tickets and issues appear in every period regardless. One raised in March is still open today, and a queue that emptied itself every Monday morning would be lying about the work outstanding.

The arithmetic for scheduled spans is written and tested, so the moment a project starts returning planned dates the board uses them with nothing to reconfigure.

What counts as late

Nothing in Twinview is inherently late. Out of the box Mirra shows how long work has been waiting and never calls anything overdue.

That is a deliberate default, and it replaced a version that computed deadlines anyway — with no duration to work from, a job's end date fell back to its start date, and 177 jobs were reported overdue against commitments that existed nowhere. Lateness is now something you turn on, having been shown what it will be measured against.

Nothing is late

The board shows how long work has been waiting and flags nothing.Default: This is the default

A service level in your own field

Reads a target out of one of your project's custom properties and counts from when the work was raised. See below.

A time limit you set

Your own house rule: work open longer than this many days is late, set per priority. Twinview supplied no deadline here — you did, and the interface says so.

Twinview's own planned dates

Only flags work with a genuine planned end date. Correct by construction, and silent on a project that leaves those fields empty.

Whichever you pick, the settings page shows how many records it would flag before you save it — and breaks that number down, so a zero tells you whether nothing is late or the field you named is not on any of these records.

Service levels, and what the parser will and will not accept

If your project records service levels in a custom property, Mirra can read them. The convention it understands is a bracket containing one or two durations at the end of a label:

P5 - Pipeline (10d/15d) respond in 10 days, resolve in 15 P2 - High (4h/1d) hours and days both work PPM planned maintenance — no bracket, never late

The deadline is the raised date plus the chosen target. That is a commitment somebody actually made, which is the whole difference between this and a date invented from a start time.

• Anything ambiguous is refused rather than guessed. `(10/15)` has no units — days and hours are a coin flip, and one reading is five days out on every job — so it produces no deadline at all.
• `(10d/urgent)` is refused; there is no partial credit for half a promise.
• `(01/02/2026)` is refused. Three slash-separated parts is not a convention this knows, which is what stops a date becoming a pair of durations.
• A value with no readable bracket, like `PPM`, is never late. On the project this was built against that is most of the open work, and it is the correct answer rather than a failure.
• A label may carry its own bracket on either side of the targets — `P3 - Minor Works (non-urgent) (5d/10d)` reads correctly.

Mirra reads what is in the field. Whether those targets are contractual or somebody's test data is a question only your project's owners can answer, and the settings page says the deadline came from your field rather than that Twinview supplied it.

A note on priority

On the project this integration was built against, Twinview's own priority field carries almost no information: 480 jobs marked Low held a P5 service code and 40 marked Low held P2. The urgency was entirely in the service-level field, and a chart of priority said nothing.

That is why the breakdown widget can group by service level as well as by priority. If your board looks flat when split by priority, try splitting it by service level before concluding the work really is all the same.

When something is not working

• The board is blank. Check the connection page first — it reports the last read, the row counts and any truncation. Every widget draws from Mirra's cache, so a stale board means the sync failed, not the widget.
• "Key rejected." Use Change key rather than Disconnect; disconnecting deletes the cached board and takes every widget with it to change one field.
• Nothing is ever late. That is the default. Choose a policy on the Twinview page, and read the breakdown it shows you before saving.
• The late count looks low. Under a service-level policy, only records carrying a readable service level can be late — tickets and issues usually carry none, so a board mixing all three will flag jobs and little else.