Portal Domain Glossary (personal, untracked)

Ubiquitous language for portal + portalBackend. Glossary only - no implementation detail.

Sources: ts-polaris repo rules/docs, Confluence (PD, TMODM, MACE, HDS spaces). Started 2026-09-16.

Product

Portal (DNO Portal) - LotusFlare's SaaS web console, the single point of entry into LotusFlare products (DNO, CDP, CEP...). Used by external operator staff and internal LotusFlare staff to operate an operator's deployment. Not used by subscribers (clients of our clients).
DNO Cloud - LotusFlare's core commerce/monetization stack (BSS). The Portal sits in front of it; DNO backend is the source of truth for product, customer, billing data and knows nothing about Portal users or permissions.
Operator - a telco customer of LotusFlare (e.g. T-Mobile, Globe, PNCC, DT). Each gets its own deployment (DC) of the stack including its own Portal instance.
MVNE/MVNO - virtual-operator flavor of customer; same Portal, different scale/config.
Tenant - the unit inside one Portal deployment that Views (modules) are enabled for; roles and permissions are configured per tenant.
Experience service - upstream microservice shaped for Portal consumption (*-experience-service, TMF-style); one of ~115 services the Portal reaches through its backend.

Operator staff - external users: care agents, catalog/marketing managers, ops engineers of the operator. The primary paying audience.
Solution Architect (SA) - internal LotusFlare role that configures and supports operator deployments through the Portal itself: tenant setup, OAuth/SSO integration, operator configuration, Power User Mode. Default read access to all operators except T-Mobile. This is why SAs "also use it".
Delivery PM / PMO / Support (HDS) - internal roles with scoped per-operator access (read-write / read / triage respectively) per Portal Access Protections.

View - a Portal module switch; enabling a View for a tenant makes its permissions assignable.
Permission Key - Read/Write string (e.g. OffersRead) assigned to roles; checked independently at menu, route guard, widget, and API-proxy layers, OR-semantics everywhere, no inheritance between layers.
Role - named bundle of permission keys assigned to users per tenant.
Power User Mode - elevated Portal mode SAs use for configuration tasks.

DC (data center) - one deployment environment, named dcNN-N (staging: dc02-2, dc09-1, dc22-2... ; production examples: dc07-1, dc43, dc72, dc86, dc95-Globe). Portal is reachable per-DC (portal-xx.lotusflare.com, or operator domains like portal-globe-vpn.globetel.com).
Custom image (snapshot image) - a feature-branch Portal build (custom-<user>-... tag) temporarily deployed to chosen staging DCs with an expiry; reverted to master automatically, and alarmed if it lingers.
BFF (portalBackend) - the Portal's own backend: authentication/sessions, permission-gated reverse proxy to upstream services, and system of record for Portal-local state (tenants, views, roles, settings).

Staging release - merged master auto-builds master-<ts> and updates staging DCs; a feature branch can ship a custom image to chosen staging DCs with a UTC expiry, after which it auto-reverts (team runbook: deploy-custom-image skill; rollout verified via the mgmt Prometheus/VictoriaMetrics kube_pod_container_info query).
Production release - never automatic. An engineer PRs the new ECR tag into the DC's env/<dc>/kubernetes/helm/lf-portal-express/version.yaml (ts-polaris/cm), codeowners approve, deploy happens in a scheduled deployment window (out-of-band needs Slack approval in #deployment / #production_issues), the engineer takes temporary Okta privilege elevation for that DC's ArgoCD and clicks Sync; ArgoCD runs the presync migration Job, then rolls pods.
Alert triage - 24x7 Platform Support (HDS) does first-line triage of portal-team alerts (logs in VictoriaLogs/OpenSearch, checks downstream DNO health), then pages the owning on-call via OpsGenie; production incidents tracked as PI tickets in #production_issues.
Infra ownership - AWS resources per DC (Portal MySQL on RDS, Redis) are provisioned by the Infrastructure/DevOps team via Terraform; app teams own their services and alerts.

Who asks for DATAP portal work - users of our own pages request fixes/features, and the team lead requests improvements and new features; no formal external stakeholder pipeline.

DATAP (Data Platform) - my team; owns the Portal's Dataflows, DataHub (sink configs, event composition), and Reports feature areas, shipped into unified/app/ as DATAP-* tickets. Our upstream services (dataflow-manager, reports daemons, OSP) live in lfscala, owned by the platform backend team.
platform-portal - the Portal core team ("portal-team" alert owner); owns the shared Portal platform: BFF, permissions machinery, build/deploy plumbing, portal-team alerts.
Upstream service owners - the ~115 proxied services belong to many teams: billing, charging, party management, platform backend (lfscala), and more; the proxy route's service name is the pointer to its owner.
No formal on-call rotations on our side; HDS/Platform Support triages production alerts and pages the owning team through OpsGenie when code is needed.

Production: dc11 Avantel; dc16 Ooredoo; dc20 Tapp; dc21 Digicel Panama; dc23 Globe GPFiber; dc84 MVNE cluster (Roccstar, Smartless, T-Mobile, test MVNOs); dc90 Pilot Fiber + DevEdge; dc95/dc96 Globe + GOMO; dc37/dc43 cloud DCs.
Staging/preprod: dc02 primary multi-tenant staging (lotusflaretelecom, dtmace); dc03 T-Mobile testing; dc22 US staging (Pilot Fiber, Intrepid, Tillman, Charter); dc30 Mojo; dc33 A1 Slovenia; dc71/dc72 Deutsche Telekom EU.
dataflow-manager is referenced in ~26 DC envs - DATAP's Dataflows is a platform-wide capability, gated per tenant by Views, not a niche per-operator feature.
The vue-flow-dataflow-diagrams rollout left no committed operator list: enablement was a Tenant Editor edit of the featureFlags array in the operator row's configuration JSON; the flag registry is portalBackend/config/featureFlags.json; the flag has since been removed and Vue Flow is unconditional.

T-Portal (DT MACE) and TMO DevEdge are not ours - adjacent portal-flavored products owned by other teams; the model excludes them (2026-09-16).
Agreed follow-up: a hands-on Kubernetes primer session anchored to lf-portal-express (chart walk, Prometheus rollout query, one staging deploy end to end).

open Portal versions: what were V1/V2/V3 ("Container App", per-team deployments, Periscope) and what of that survives today?
open lf-portal helm chart vs lf-portal-express - legacy vs current?
open lfscala common/portal + mysql-portal - what Scala side owns for Portal; which repo serves com-*-experience-service.