Presence & Activity settings

The Analytics dashboard’s live band can show a count of who is in the app right now, a roster naming them, and which part of the product each one is reading. This page’s setting controls which of those three an org actually publishes, and to whom.

What you see

Open Org Settings, then the Presence & Activity section. You’ll find a card of the same name, with the description:

“Who can see that a member is currently active. Follows the same per-field model as Alumni privacy settings.”

The three fields

Each gets its own row with a dropdown offering Hidden, Officers and All members.

All three are enforced on the server, on every read — not merely respected by the page that draws them. Setting the aggregate count to Hidden makes the API stop producing it, for admins too, and the Adoption tab says “Hidden” rather than the em dash it shows when presence genuinely cannot be read. Those are different states and the product never conflates them: one is a setting, the other is an outage.

The three are also gated independently. An org can withhold the count while still letting officers see the roster, or the reverse — a count and a named list are different products, so one key never implies another.

Hiding the aggregate count also withholds the device and module breakdowns, because those are the same number sliced: “web 8 · native 4” is a count of 12 spelled differently. Percentages without counts were considered and rejected — a percentage alongside a visible roster reconstructs the count exactly.

The defaults are graded rather than uniform, and that grading is the substance of this page. A count identifies nobody, so it is a fine thing for members to see. An indicator names someone, so it starts with officers. What a named person is reading right now is the strongest of the three, so it starts off entirely and an admin has to turn it on deliberately.

The presence window

Below the three fields, a fourth control: Presence window — 2 minutes, 5 minutes (the default) or 15 minutes. It sets how recently a member must have been seen to count as active.

The window is a read-side setting. Presence itself is stored once, platform-wide, and each org’s figures are computed by intersecting that store with its own memberships over its own window — so an org narrowing this to 2 minutes changes only what its own admins see. It cannot shorten what another org keeps, and it does not reduce what is stored.

Every surface that reports a presence count also reports the window it used, so the Adoption tab’s card reads “Active · last 15 min” for an org that chose fifteen. A caption that hardcoded one window would be wrong for two thirds of orgs, and a count of “active” people under the wrong window is a wrong number, not a cosmetic slip.

The per-minute sampler behind the Concurrent Users chart uses this window too, so the chart’s own caption describes the measurement it is drawing. Changing the window changes what future samples measure; it does not rewrite the ones already taken.

What presence is, and is not

• Presence records that a request arrived from a member inside the window. It is not a claim that they are at their desk or free to answer one. Nothing in the product is ever labelled “Online”.
• Presence is not written to the database. It lives in Redis and expires. The one exception is a per-minute sample of the aggregate count behind the Concurrent Users chart, which is also Redis-only, on a 48-hour horizon.
• If presence cannot be read, every surface shows an em dash, never a zero. A confident zero reads as “nobody is using the platform”.

Related

• Analytics dashboard (org & region) — where these settings take effect
• Member Analytics Visibility settings — the same three-way control over chapter statistics, with the weaker reading of Hidden

Added 2026-09-02.