The Community module's user-profile system is built on default-private. The consumer default of "everything public, opt-out available" doesn't apply on a B2B partner-portal. Instead: everything private, opt-in available.
Default visibility
A new user's profile is visible by default only to their tenant peers and Netorigo staff. An engineer registering at a logistics tenant does not automatically appear to a finance tenant's peer, and rightly so. If they want cross-company visibility (for example to mention in a tough NAV-rule thread that they have years of experience on the topic), they opt in per-post.
The per-post opt-in is not a global toggle. Each post individually chooses whether to expose author attribution ("Anna K., logistics tenant") to cross-tenant peers. This prevents the failure mode where a user once flips "public" and forgets that their next post sits in a sensitive edge-case topic.
GDPR consent
We ask for two separate consents at signup:
- Product T&Cs consent. Netorigo platform base licence, audit, contract terms.
- Community-profile consent. A separate explicit consent that the data stored there (post content, peer attribution, Helpful Answer count, thank-you token flow) may be used for the community platform's purposes.
The two consents are intentionally separate. A user can decline the community consent and still use the Netorigo platform (admin, finance, logistics). They just won't get access to the community module - an acceptable outcome.
The 5 fields we store
The community profile stores the following 5 fields:
- Display name. User-chosen name (default: surname + first-name initial, e.g. "Anna K.").
- Tenant identifier. Which tenant they're affiliated with (the tenant name, not their personal employer if those differ).
- Job role. Optional free-text field ("Finance controller", "Warehouse manager"). Empty by default.
- Tags-of-interest. User-chosen tag set they subscribe to for the weekly digest.
- Helpful Answer + thank-you-token aggregate counts. Aggregates only, not the individual trail.
The 7 fields we deliberately do NOT store
- Long-term IP retention. Only on the request, in the audit log for 30 days, hashed after that.
- Behavioural fingerprinting (browser fingerprint, click trail, mouse movement). None.
- Geo-location. Neither auto-detected nor manually entered.
- Profile picture. Debated. Decided against: peer attribution is enough, and a profile picture would just add another opt-in decision.
- External social-profile links. LinkedIn, X, etc. Debated, decided against (reduces opt-in pressure to "complete" the profile).
- Bio / about text. Free-text means GDPR-sensitive data risk.
- Phone number or email on the profile. Stored on the base Netorigo account, but the community profile does not surface them to peers (no DM either, see the earlier post).
Right-to-erasure flow
GDPR Article 17 (right to erasure) is fairly concrete for the community module. The flow:
- The user files an "Account deletion" request on Settings > Privacy.
- A 14-day soft-delete period starts. During it the profile is inactive but posts remain visible. The user can cancel deletion.
- After 14 days, hard-delete: the profile record is removed, posts remain, but author attribution flips to "[deleted user]".
Keeping the posts is deliberate: if a single reply suddenly vanished from a 30-post-long thread, that would break the discussion context of the other 29 posts and disadvantage the untouched peer users (whose own answers stay).
The pseudonymisation layer for KB training
When we train the LLM on tenant content for KB + auto-FAQ generation, a pseudonymisation layer runs: all user names, company identifiers, account numbers, phone, email are swapped for placeholders (<USER_42>, <COMPANY_7>, <INVOICE_xx>). The LLM only sees the pseudonymised form. The pseudonym map sits in a separate encrypted store and never leaves vendor infrastructure.