OxalisAdmin

One link, many people, one shared sandbox. Post it on LinkedIn or WhatsApp and anyone who clicks gets a time-limited account inside the shared Trial org with viewer-only access. Nobody gets a workspace of their own, and nothing here is billable.

These are not Offer links. Use a Demo Link to let strangers look around. To put a named prospect on a real plan in their own workspace, use Billing → Offer links instead.

Logins by user

Who's actually using it, how often, from where. Trial users get a chip; device column is the (OS · browser) mix seen across their sessions; acquisition is where they came from (newsletter / direct / referrer).

Org adoption

Per-organisation activity. lonely seat = paid for >1 user but only one has logged in. no logins = seat exists but nobody's ever signed in. Trial orgs flagged with a chip.

Acquisition

Where sessions came from. Built from the ref= URL param on newsletter links, UTM tags on share URLs, and the bare HTTP Referer host as a fallback.

Top pages

Raw user activity (legacy)

Inventory counters for the entity-event graph. These were moved off the front-of-house FSI dashboard so it reads as an editorial intelligence brief rather than a bulk-extract preview.

Stripe wiring status. Set STRIPE_SECRET_KEY + STRIPE_WEBHOOK_SECRET, point the Stripe Dashboard webhook at /api/billing/webhook, then bind each plan's Stripe price below. Prices & amounts live in Stripe — here you set the price binding, trial length, and what happens when a trial ends.

Plans & packaging

Each row is one sellable plan, and the columns work together. A plan becomes self-serve sellable once it is active and has a Stripe price ID — that price is what the customer actually gets charged. Trial d and Trial end on the same row are that plan's defaults: with Trial d > 0, a self-serve checkout against that price begins as a free trial of that many days, after which auto_renew charges the price (so a card is required up front) or cancel simply ends access with no charge.

These apply to the self-serve path only — someone subscribing through the site. An Offer link below carries its own trial length and card setting, which override whatever is on the plan.

Offer links (real workspaces)

One link, one deal, a workspace each. Encodes fixed seats, trial length and whether a card is required at sign-up. Paste it into outreach: a cold prospect gets a brand-new workspace of their own, and a signed-in customer can apply it to theirs. e.g. "5 seats, 14-day trial, auto-bill" vs "10 seats, 30-day trial, no card".

These are not Demo Links. An Offer link provisions a real workspace with real entitlements; a Demo Link drops everyone into one shared, viewer-only sandbox.

Mind the two defaults. "Card at start?" is ticked and "Trial end" is auto_renew — together those bill the customer when the trial ends. For a try-it-and-walk-away link, untick the card and set Trial end to cancel.

Curate which of the ~41k FCA firms are in scope. target_tier1 + target_tier2 appear in the newsletter and refresh weekly; passive is the default for unknown firms; excluded is dropped from the pipelines entirely. Manual overrides always win over auto-rules. The DB is now the source of truth — target_firms.json is a bootstrap seed only; use Export for snapshots, version control, or restoring a fresh instance.

Backfill from curated list

Reads data/target_firms.json and stamps every matching firm with the right tier. Matches on firm name directly; tier-1 always wins over tier-2. Idempotent. Skips rows where you've set a manual override.

Bulk exclude

Mark a set of firms as excluded so they stop appearing in the newsletter and refresh queues. Always shows a preview first.

Triage queue — biggest untriaged firms first

Firms with no priority row (or computed status of passive) ordered by headcount. Click a button to mark each one in place. The list refreshes after every action so you can rip through the long tail.

Manual overrides

Firms where you've manually set include / exclude. These always win over the auto-rules.

Daily Postgres operational dump (04:00 UTC) and weekly DuckDB snapshot (Mondays 04:15 UTC). Both are GPG-encrypted on the server and rsync'd to the Synology NAS, which POSTs to /api/backups/checkin after each successful pull. A green pulled badge means the off-site copy is fresh; red means the server has the encrypted dump but the NAS hasn't fetched it yet. Read-only view.

Recent runs — newest first

Every server-side 5xx and every client-side JS error lands here, regardless of whether the Discord webhook succeeded. The Discord column shows whether an alert was scheduled (yes = sent or deduped; no = no webhook configured or scheduling failed). Top errors lets you spot the single hot loop causing most of the noise. Auto-pruned after 90 days.

Top errors (by count)

Recent (newest first)

ready.