Administration
For instance and organization admins: managing people, access, authentication, and accountability. Everything here lives under Settings, whose left nav is grouped by why you can see each section — Account (everyone), Organization (you administer an org), Instance admin (you run the instance).
Instance admin
Visible only to instance admins, under Settings → Instance admin:
| Section | What it's for |
|---|---|
| Insights | The instance-analytics dashboard: active users (DAU/WAU/MAU), growth, activity trends, top pages / contributors / spaces, AI answer-rate, and knowledge-health signals — over the last 30 days. |
| Users | Every account on the instance as a sortable table — see People table below. Also where you create users, reset passwords, grant/revoke instance-admin, deactivate sign-ins, and set a plan tier inline (no self-serve billing). |
| Organizations | Index of all orgs (create new, open one to manage) plus the instance-wide auto-join domain map. See Organizations below. |
| Usage | Instance-wide overview: totals (users, orgs, spaces, pages, attachments, AI calls/mo, asks/mo, answer rate), top AI consumers this month, and top unanswered questions over 30 days — each with a Draft page action that turns the gap into a new page. |
| Feedback | Inbox for feedback users send via the in-app form or an agent's submit_feedback tool. Emails admins and shows an unread badge. |
| Events | The firehose — every sign-in (and failed sign-in), page view, edit, access change, ask, API request, and billing step (plans viewed, checkout, payment, trial started / ending / expired), newest first. Filter by type, search, scope to a date. |
| Errors | Errors reported from users' browsers, grouped by signature with a count, affected-user count, and recent occurrences — the triage companion to Events. |
| Audit | The focused access-control slice of Events: org membership, grants, domain mappings. Kept indefinitely. |
| Instance | Instance-wide runtime config. See [[Self-Hosting]]. |
[!NOTE] Admin activity is hidden by default. Insights, Events, Errors, and Audit exclude actions by instance admins out of the box — an operator's own views, edits, asks, and error reports would otherwise drown the real signal. Flip Include admins on any of those screens to fold it back in. (System actions and anonymous activity are always shown.)
[!NOTE] AI kill-switch & maintenance notice — under Settings → Instance admin → Instance, you can pause every AI feature (Ask, semantic search, and background indexing) with one switch while the embedder/LLM is under maintenance, and post an instance-wide maintenance banner. tela also flips Ask to "AI temporarily unavailable" on its own when the model is unreachable (see [[Search & ask your docs]]) — the switch is the manual override for a planned window.
People table
Settings → Users answers "who actually uses this" without leaving the app. One row per account, every column sortable, opening on the most active people.
Lifecycle
Each person carries a status, and the bar above the table is both a census and a filter — click Churned to get exactly that list:
| Status | Means |
|---|---|
| Power | 12+ active days in the last 30 |
| Regular | 4–11 active days |
| Dabbler | 1–3 active days |
| Churned | was active once, silent for 30+ days |
| Never started | signed up and never did anything |
Two rules make this useful rather than decorative. Status always reads the last 30 days, whatever window you've selected — it describes the person, not the view. And recency beats volume: someone who wrote 200 pages and hasn't appeared in six weeks is Churned, not Power. That's the row worth a message.
Columns
| Column | What it counts |
|---|---|
| Trend | Active days per week over the last 12 weeks, plus the change from the previous 4 weeks to the last 4. Sort by it to see who's ramping up — or slipping away. |
| Edits | Revisions they wrote. Agent and sync shares are called out separately: a synced vault posts thousands of revisions nobody typed, and lumping them in makes a file sync look like your best author. |
| Pages | Pages they created (they wrote the page's first revision) |
| Views · Asks · AI | Pages opened, questions put to Ask, metered AI calls. AI is counted per calendar month, so it follows month boundaries rather than the exact window. |
| Days | Distinct days with any activity — an event or an authored revision, so people who write over file sync are counted too |
| Last seen, Storage, Plan | Last authenticated request; owned spaces + attachment bytes against the plan's limits (over-limit is flagged red); the plan tier, changeable inline |
Click any Edits, Views or Asks number to open exactly those rows in Events. Click the row itself for the person's detail sheet: spaces, orgs, AI calls, MCP status, sign-ins, when they joined, and their recent edits across the whole instance.
The rest of the screen
- Window switch (last 30 days / 3 months / all time) frames every activity column at once.
- Totals above the table cover whatever rows are in view, so filtering to Admins or MCP set up answers "how much does this group actually do".
- People / Teams / Spaces switches what the table is a list of. A team's activity is its members' activity wherever they did it (someone in two teams counts toward both); a space's activity is what happened to its pages, whoever did it.
- Signup cohorts at the bottom: each row is the people who joined that week, each column how many were still active that many weeks later. The view that answers "do they stay".
- Export downloads the rows in view as CSV, and the whole view — window, status filter, search, sort, grouping — lives in the URL, so a finding can be bookmarked or sent to someone.
[!NOTE] All time means "as far back as the log goes" for Views, Sign-ins and Days active — they come from the activity feed, which is pruned (see the retention note at the end of this page). The table prints the actual horizon when it clips your selected window, and the cohort grid reaches back 26 weeks at most. Edits and Pages come from page history, which is never pruned, so those really are all-time.
Users & registration
tela is email-first: open self-registration with email confirmation, then login by email or username. Close self-registration from the Instance settings. New sign-ups whose verified email domain matches an auto-join domain are enrolled into that org as a member automatically.
Organizations
Organizations group people so a whole team can be granted access to a space at once. Each org is managed on its own page (a left-nav with room to grow), reached from Settings → Organizations → Manage:
- Overview — plan tier + live usage (members, AI calls/mo, attachments, spaces) against the org plan's caps.
- Members — add or remove people and set admin/member role, and invite teammates by email: they get a link to join and land in the org once they accept or sign up — even without an existing tela account. Pending invites are listed until accepted, and can be revoked.
- Groups — sub-teams within the org; share a space with a group to grant just part of the org.
- Single sign-on (instance admin only) — connect the org's OIDC provider. See [[Single Sign-On (SSO)]].
- Custom domains (org admin too) — serve the app on your own address with your branding + login methods. See [[Custom domains]].
- Activity — this org's access-change history (the audit log, scoped to the org). Available to org admins.
[!NOTE] Auto-join domains (mapped in Settings → Organizations) map an email domain like
acme.comto an org for automatic membership and to route those users to the org's SSO. Don't confuse them with [[Custom domains]] — a web address the app is served on. Different things.
On telawiki.com anyone can create a team themselves — Settings → Plan & Usage → Create a team — become its admin, invite teammates by email, and upgrade to the Team plan in place (see [[How to upgrade]]). A self-hosted instance keeps org creation to instance admins by default; an operator can enable self-serve. An org admin who isn't an instance admin sees a scoped Settings → Organization section: only the orgs they administer, with no instance-wide domain mapping.
Authentication
- Passwords — the default, with email verification and self-service reset.
- [[Single Sign-On (SSO)]] — connect a company OIDC provider (Microsoft Entra, Okta, Google Workspace, …) so people sign in with their work account; optionally enforce it per org.
- Social login — instance-wide Google / Microsoft / GitHub buttons (configured by the operator — see [[Self-Hosting]]).
Accountability
- Events and Audit — see Instance admin above. Events is the firehose; Audit is the access-control slice (also surfaced per-org as Activity). Both hide instance-admin activity by default — use Include admins to see it.
- Billing trail — on telawiki.com, the Billing filter in Events shows each account's subscription history in order: plans viewed, checkout started, how that checkout ended, subscription changes, payments, and trial started / ending / expired. It's the record of what an account was offered and what came of it.
- Access model — space membership, organizations, and groups combine to decide who sees what.
- Plans & usage — every account (personal and each org) carries a plan tier. See your own under Settings → Account → Plan & Usage; admins see every account's usage in the People table and per-org usage in an org's Overview.
[!NOTE] Page views and sign-ins are recorded for logged-in users. The activity feed is retained for ~180 days (configurable), with two exceptions kept for good: the access-control audit log, and billing events — a subscription's history is only useful whole.