Broa

Sign in

You are currently signed out, please sign in for access to Broa.

State

Reading . This table shows the messages that response contained and the fields it carried — nothing about what has not arrived.

Import a mail file

Loads .eml files through the same admission pipeline as any other message (ING-FIL-001). Use it to bring existing correspondence in — an archive, a client's forwarded mail — rather than to relay something that has just arrived. For that, use Compose.

What is this correspondence?

This decides whether the platform may ever answer it, so it is asked before the files rather than after.

Evaluation — real mail being used to judge how the system behaves. The platform can never reply to it. Backfill — history being loaded so the record is complete. The platform can never reply to it. Sandbox replay — messages replayed into a sandbox. The platform can never reply to it.

There is no option here for live mail, and that is deliberate. An imported message is admitted with a non-live origin (ING-FIL-003) and the run token minted for it carries no capability to send (ING-FIL-004) — so importing a customer's old question cannot result in them being emailed about it weeks later. The service refuses origin=live outright; this list is not what enforces it.

Files

No files chosen.

Ingestion — Manage

Intake limits

What this tenant's intake accepts. Enforced by ingestion-svc before a request is buffered or parsed (ING-LIM-002), and owned here as configuration (CFG-COV-016) so a change is versioned, revertible and audited.

A tenant may set a limit below the platform ceiling and never above it (ING-LIM-003). A value of zero is refused: stopping intake is a tenant lifecycle action, not a limit.

Reading the configured limits…

Intake paths and publication

Not reported by this deployment. CON-ADM-014 requires the intake-path and publication flags shown here, and ingestion-svc exposes no endpoint that carries them. This panel shows nothing rather than an all-clear it cannot support: an operator looking at a stalled queue would otherwise read "no problems" from a page that never asked.

Of the five intake paths, two accept anything today — file import and the submission endpoint behind Compose. Publication to the event bus is not wired, so nothing downstream is notified of an admitted message.

Runs

Parties

Who this tenant corresponds with — accounts and prospects, and the people, systems and agents acting for them. An index, not a customer store (PTY-MOD-007a): identity and the association graph only. Orders, invoices and prices stay in the tenant's own system, reached live through external_ref.

Hide system and test

A party added here is created confirmed: you asserted it, so it does not appear in the unconfirmed queue above. Parties may also reach this list by other routes — this console is told what exists, not how it got here.

This table is what party-svc returned for your tenant. The unconfirmed count is a field on that response; it means a party is awaiting review, not that anything is or is not currently running.

Identity administration

Tenants are platform-plane (CON-IDN-002). Everything inside a tenant is tenant-plane. There is no identity directory — members are added by exact issuer and subject, because a searchable one would disclose which addresses exist in other tenants (CON-IDN-004).

Tenants platform plane

Hide system and test

Name	Status

One action, not four — IDN-TEN-005 makes the tenant, its default workspace, the first membership and the first admin role atomic.

Workspaces

Memberships and roles

Identity	Status	Roles

Adding a member grants no role — membership and role assignment are separate acts with different blast radii (CON-IDN-005). Disable suspends and is reversible; Remove from tenant cascades (CON-IDN-007).

Our senders

Which mail is your own. Broa records a message from one of these senders on its thread and never drafts a reply to it, so it does not answer your own staff. A website enquiry relayed from one of your form addresses is the opposite: it is still answered, addressed to the customer the form names. Nothing here is guessed — only what you list counts. Changes take effect only when published.

Configuration — Advanced, read only

This page is a read-only history view. Settings are changed on Platform › Settings (Broa's platform administrators): one setting at a time, with the change shown before it is saved and everything else kept in force.

A revision is immutable and publication is a separate act (CFG-VER-001, CFG-VER-005). Every row below says which state it is in.

Effective configuration

Workspace Intent

Domain	Effective value	Came from	Revision

"Came from" is provenance (CFG-RES-002) — which scope in the chain supplied the value. It is how you answer why a workspace behaves differently from its tenant.

Configured objects

Name	Domain	Scope

Revisions —

Revision	State	Comment	Author	Created

Publication history — every set in this tenant, not just this object

Version	State	Comment	Actor	Published

A set is the unit of publication and spans objects (CFG-VER-006). Rollback produces a new published set (CFG-VER-007), and superseded sets are hidden here, never deleted — they are what a rollback restores, and what says which configuration produced a past response (CFG-VER-003, CFG-RES-004).

Clients

Every client, where each one is in Get started, and what is stuck — so a client who stopped halfway is noticed before they give up. Every step is computed, never ticked. A step we cannot see is shown as ?, never as “not yet”. Clicking a client offers borrowed access and nothing else.

Show Hide system and test New client

Client	Get startedR1–R7: ✓ done · · not yet · → blocked · ? cannot see · – set aside	Last mail	Spend ceilingBroa’s model cost, per calendar month	Trial	Stuck	Paused, exported, removed§3h — the way out

? (cannot see): The service that answers this step has no read for it on this plane yet, so nobody can say. It is not counted as something the client has left to do, and it never appears under Stuck. The list above the table names what is missing.
– (set aside): The client chose not to do this step for now. Never done, never to do, never stuck.
Spend ceiling: A monthly limit on what the client’s work costs Broa in model charges. The client sees only that a limit exists, and is warned as they near it and reach it — never the amount. Reaching it stops new runs: Broa writes no more replies that month, new email is handed to people instead, and email keeps arriving. Its state is metering’s to say, and metering has no read of it here, so it is shown as unknown rather than worked out from the weekly spend beside it.
Trial: A client provisioned on the starting ceiling that nobody has raised yet: the ceiling is raised when they go live. It keeps answering — the flag is for a conversation. A trial lasts until we raise the ceiling (the owner’s answer to O10, 2026-09-21): there is no clock, so the day count has no end.
Ours / Theirs: Ours: provisioning did not finish, and New client finishes it. Theirs: a step the client has not done, for as long as the client has existed.
Paused: Broa stops answering for the client and nobody can sign in. Questions from their website widget and enquiries are kept and answered in order on resume; a connected mailbox is not read and mail forwarded to their fallback address is refused at the door, and the original stays in the client’s own mailbox. Nothing is deleted.
Remove: Offered only for a paused client whose export was completed after the pause, and it asks for the client’s name typed and a reason. Today it marks the client as being removed (“deletion in progress”); nothing is erased in any service yet — what removal erases, and when, waits on the owner. The audit trail is always kept.

New client

One action creates the client: their tenant, the first administrator’s account, the starter pack for their business, their spend ceiling, and a fallback forwarding address for their mail. If anything stops halfway, call again — the same attempt finishes what is missing and never makes a second client.

The company Company name

Business type — chooses the starter pack they begin with. It is theirs to change afterwards.

The first administrator Email

First name (optional) Last name (optional)

A Broa person takes the first seat instead of the client

Normally the client is the first administrator. The account is made active with a one-time password, shown to you once when it is created; they change it at first sign-in. A Broa person taking the seat must use an identity that holds no platform authority.

Their mail Fallback forwarding address @in.broa.terazul.com

The client normally connects their own mailbox in Get started and Broa reads it, so most clients never use this address. It is the fallback for a mail system Broa cannot read: they forward their shared mailbox to . It is reserved now and stays inert — mail to it is refused, not held — until they accept the terms. An address is never given to another client.

Terms and DPA versions (optional)

Which documents they will be asked to accept. Leave both empty if none are published yet.

Terms version DPA version

Spend ceiling

$100.00 a month

A limit on what their work costs Broa in model charges each calendar month. The client sees that a limit exists and is warned as they near it and when they reach it — never the amount. Reaching it stops new runs: Broa writes no more replies that month and hands new email to people instead. Every new client starts here; raise it on the Clients screen when they go live.

Attempt —

Tenant mailboxes

Mailboxes used to send approved replies, and whether Broa is reading them.

Show Search

								Action

ERP connections

Each company's ERP: whether Broa can read it, when it last did, the last thing that went wrong, and the request limits in force ("(own)" where the company chose its own). A company connects or replaces its key, and changes its limits, on Company settings → Connections; with borrowed access you can help there.

Client Usage

How much each client is using Broa, per ISO week (Monday to Sunday, UTC). Counts only: no message, no customer, no person’s name — people are counted per role. Seeing what is behind a number means borrowing access to that client, which is recorded and visible to them.

Weeks shown Week

Per client

Client	Approvedbilling unit	Messages	Runs	Edited before approval	Closed without reply	Knowledge changeditems moved, not work done	ERP readscalls to the client's ERP	Active peopleon the busiest day	Model spendthis week	Widget spendmonth to date	Trendapproved, per week	Completeness

Approved: Replies approved — by a person, or by Broa itself where the client chose to let it reply by itself to a kind of question (the line under the number says “of which N automatic”; an automatic reply is billed as an approval). This is the billing unit, and it counts the approval: Broa hands an approved reply back to be sent and does not see it delivered.
Knowledge changed: How much of what Broa knows moved — not how much work people did. Importing 700 products counts as 700; a week spent correcting prices can count as 0. Both are right: the number measures knowledge, not effort.
ERP reads: Calls Broa made to the client's ERP (method.me) — order lookups and the customer sync — with the sync's runs and the customers it read under the number. The sync runs every hour whether or not anyone is at work, so these never make a client count as active. A dash means this week's figure was not reported, not that it was zero.
Screens opened: How many times a screen was opened — not time spent and not work done. Re-opening a screen counts again: there is no session to collapse opens onto, by design. No figure here is a billing input; the billing unit is Approved, above.
Different screens: How many distinct screens were opened at all — the breadth figure. Two clients with the same number of opens and a different breadth are using Broa differently, and only this tells them apart. A screen this console has no name for is shown as the id metering reported it under, because a screen added last week is still a fact.
Actions taken: How often one of six product actions happened: marked as spam, page added, rule changed, price changed, test drive run, export taken. Replies approved, replies edited and widget questions have columns of their own above and are deliberately not counted again here.
Active people: Per role, on the week’s busiest day for that role — “3 on Wednesday”, not “3 this week”. A distinct weekly headcount cannot be worked out from daily counts that name nobody.
Widget spend: The one figure on this screen that is not for the week. It is the calendar month to date, because the widget’s spending ceiling is monthly.
≥ before a number: Some usage is known to be missing for that client that week, so the true figure is at least this much.
Went quiet: A client that used Broa and then counted nothing at all — no message, run, approval, knowledge change, screen opened or person signed in — for a whole window of complete weeks. It says who and never why. A client that never started is not in it: that one is a supplied zero row in the tables above.
Clicking a client: Offers borrowed access to that client and nothing else: a justification, a time limit, a record, and the client can see it. There is no link from a number to the messages or people behind it.

What they use

Which parts of Broa each client opened this week. A screen opened is a screen opened — not time spent, and not work done. None of these figures is a billing input: the billing unit is Approved, in the table above. People are counted per role and never named.

Client	Screens openedopens, not time	Different screenshow broadly	Busiest screensopens per screen	Actions takenof the seven	Different actions	Which actionstimes each	Per rolecounts, never a person

Trend

Figure

Oldest week on the left. * the figure can still change (the week is open, recently closed, or a figure is not measured); ≥ some usage is known to be missing; not reported means this metering-svc does not send that figure at all, which is not the same as zero.

Clients who went quiet

Nothing at all for

This is a screen and not an alert: nothing here is emailed and nothing is alerted on. It says who and never why — a holiday, a closed showroom and a client who gave up are the same number here — so the only move offered is the one every client offers: asking for borrowed access, with a justification the client can see.

Usage & cost

Consumption for one company. Broa's internal provider cost and margin are not shown here and are not sent to this page (CON-MTR-003).

This period

Budget

On budget exhaustion

A budget does not stop correspondence. If quota state is unavailable the platform keeps processing messages (MTR-QTA-004) — a budget is a spend control, not a kill switch, and treating it as one is how a tenant's customers get ignored.

Budgets are not persisted yet: quota configuration (MTR-QTA-002) has no store behind it, so this control demonstrates the consequence text and saves nothing.

Meters 0 registered live from metering-svc

The published metering vocabulary (MTR-COV-023): what can be measured, in what unit, and which dimensions every event must carry. A meter absent from this list cannot be recorded.

Meter	Unit	Aggregation	Components	Required dimensions

Audit records

Every decision and action, including reads (AUD-COV-001, AUD-COV-002). Reading this page is itself an audited access.

Event type Outcome Actor Action Resource Free text

Event-type registry live from audit-svc

What this platform can record, and which types are critical — AUD-CAP-004 forbids the action from completing until a critical event is durably persisted.

Reading — live, from audit-svc's query API (AUD-QRY-001). The tenant comes from your session, not from this URL: an audit query that took a caller-supplied tenant would be a way to read another tenant's record (BR-API-011). Records only go back 30 days by default and the retention purge removes what is past its period (AUD-RET-003), so an empty table means nothing happened in the window — not that nothing was recorded.

Sign in

Dashboard

Dashboard

Import a mail file

What is this correspondence?

Files

What happened to each message

Compose a message

Ingestion — Manage

Intake limits

Intake paths and publication

Runs

Knowledge

Pricing rules

Rules

Try it

Version history

Discount exceptions