Confirm your role
Identify whether you operate as CSR, Finance, Network & Usage, Dealer/MVNO, Compliance/Fraud, or Platform Admin.
Telecom Billing App · Official academy
Operate the subscriber lifecycle, charging, and billing with confidence.
Role-based learning, verified operating procedures, live-product walkthroughs, workflow playbooks, data-model reference, and technical guidance for the complete telecom billing lifecycle.
Operator briefing
Start with the controlled operating loop
Review role boundaries, data-entry order, evidence gates, and live-product walkthroughs before you touch a record.
Start here
Getting started
Understand the app, your role, and the safest route to productive work in under 20 minutes.
Before you begin
Use your assigned role, start with the role workspace, and preserve the system of record. Do not work around lifecycle, ownership, or reconciliation controls.
Open the right workspace
Start with Customer 360, Manager Home, Prepaid Customer Balances, Payment Health, or the workspace relevant to your queue.
Learn the service-to-cash lifecycle
Understand subscriber state, effective dates, usage, rating, balance impact, invoicing, payment, and exception ownership.
Complete your academy
Follow the role path, complete guided walkthroughs and live-record labs, submit evidence notes, and pass the applied assessments.
Navigation model
| Surface | Use it for |
|---|---|
| Role workspace | Prioritized assigned work and actions |
| Dashboard view | Operational monitoring and exceptions |
| Table | Authoritative record management |
| Form | Controlled creation and update |
| Workflow | Automated routing and record creation |
First-week checklist
- Open every workspace available to your role
- Locate one assigned subscriber, invoice, payment, or exception
- Trace a usage or payment event to its source
- Review overdue, unbilled, and failed queues
- Complete the shared foundation
- Run one sandbox workflow lab
How to use the app
The standard operator path
Every role follows the same control pattern. The starting table changes, but the evidence and handoff discipline stays constant.
Open the queue or workspace that matches your accountability.
Search by customer, MSISDN, invoice, payment, CDR, alert, or case ID.
Follow references instead of creating shadow notes or duplicate records.
Confirm status, effective dates, owner, SLA, and tenant or customer scope.
Use the approved action, guard, and duplicate check for the scenario.
Record what changed, why, by whom, next action, and due date.
Learning paths
Role academies
Curated learning paths aligned to accountability, system access, and operational outcomes. Select a role to see the exact starting workspace, read/write boundary, course order, and handoff standard before opening a lesson.
CSR / Customer Operations learning path
Resolve billing and service conversations without breaking traceability.
5courses80%pass mark0complete
Start here every day
Customer 360 + Cases
Start with the customer, subscriber, or case number. Confirm identity and current service state before discussing money or making a change.
Default operating loop- Open the role home and set the smallest authorized scope.
- Find the authoritative record using an internal ID or business code.
- Follow the linked records and validate lifecycle, timing, ownership, and exception state.
- Perform only the write scope below, then leave an evidence-backed handoff.
- 01CSR1 · Customer 360 WorkspaceUse a single customer context to answer service and billing questions.
- 02CSR2 · Invoice and Payment ConversationsExplain invoice totals, payment status, and adjustments in customer-friendly language.
- 03CSR3 · Prepaid SupportDiagnose prepaid balance, bundle, recharge, and expiry questions.
- 04CSR4 · Cases and EscalationsCreate complete cases with source references and clear ownership.
- 05CSR5 · CSR CapstoneComplete a multi-channel customer journey from question to verified resolution.
Boundary and handoff
Do not edit source usage, rating, invoice totals, payment outcomes, fraud dispositions, or role permissions. Route those decisions to the accountable owner.
Primary workflow paths: Subscription Suspended Recovery · Invoice Disputed Billing Review · Payment Disputed Chargeback
Evidence required: Customer or subscription ID, conversation summary, affected invoice/payment/usage ID, promised next action, owner, and due date.
Operating model
Role permissions and responsibilities
This is the practical contract for each user: where to start, which tables to read, what can be written, what must be handed off, and which workflow outcomes belong to the role.
Required for everyone
Shared foundation
Six essential courses establish a common operating vocabulary and safe working practices.
Runbooks
Operating procedures
Use these as the controlled reference; open the linked guided lesson for the full click-by-click practice, field checks, evidence rubric, and knowledge check. Each runbook now exposes its pre-checks, exact source tables, stop conditions, and handoff owner.
Procedure 01
Activate a subscriber
Follow the sequence in the system of record and retain the evidence shown below. The lesson adds the actual training context around this runbook.
- KYC and customer status
- Inventory identifiers are unused and in the right tenant/region
- Plan, service, effective dates, consent, and activation channel
Stop condition
Stop on duplicate inventory, unresolved KYC, missing plan/service, or a lifecycle transition that has no supporting history.
Handoff route
Subscriber Operations for provisioning or inventory; Compliance for KYC/fraud; CSR for customer communication.
Operating steps
- Open Customer 360 or the subscriber workspace and confirm customer identity and account status.
- Select the tariff plan, bundle, service eligibility, SIM or eSIM, and MSISDN without creating duplicates.
- Confirm effective dates, activation channel, dealer or tenant, and any required KYC or consent evidence.
- Save and verify that the subscription, balances, and provisioning-related references are present.
- Check the first expected charge or allowance and record any exception before promising service availability.
01Customer verified→
02Plan and SIM linked→
03Subscription active→
04Balance and service checked
01Source CDR→
02Validated and rated→
03Charge applied→
04Invoice line
End-to-end walkthroughs
User journeys
Follow the complete path through the app for the most common operator outcomes. Each journey names the entry record, handoff, finish state, and evidence expected at every step. The expanded route shows the actual preconditions, tables, stop points, and reviewer proof.
Journey 01
New subscriber activation
A verified customer requests a new MSISDN, SIM/eSIM, plan, or service.
- Customer identity and KYC status are resolved
- MSISDN, SIM/ICCID, and IMSI are available and not already active
- Tariff plan, service, tenant, and effective dates are approved
- Customer and subscription record IDs
- Assigned network-identity IDs with masked display values
- Plan/status/effective-date result
- Interaction or case owner and next action
Stop and hand off when
Stop before saving when identity, inventory uniqueness, KYC, or effective-date checks disagree. Route the failed record; do not force Active status.
If identity, provisioning, inventory, or fraud checks fail, create a Case and hand off with the failed record and evidence.
- 01
Open Customers and confirm KYC Status, customer Status, contact details, and Account Hierarchy.
- 02
Open Subscriptions and select an unused MSISDN Pool record, SIM Inventory / ICCID, device context, Tariff Plan, and bundle.
- 03
Validate effective dates, eligibility, distribution-partner or MVNO-tenant ownership, consent, and duplicate service records.
- 04
Save the subscription and verify Subscription Status History, Balances, and the assigned network identity.
- 05
Explain the plan and expected first charge or allowance; record the Customer Interaction and close or route the Case.
Handoff and escalation
If identity, provisioning, inventory, or fraud checks fail, create a Case and hand off with the failed record and evidence.
Live product routes
Product walkthroughs
Each card combines a direct screenshot from the current Telecom Billing App with its verified route, controls, outputs, and operating sequence. The images are shown as captured so learners can recognize the real interface and current UAT data.
Live route 01
Manager Home
The live manager page for case priority, open-case workload, critical escalations, and dealer commission context.
- 1. Cases by Priority establishes the queue shape; open the case before treating a count as an SLA breach.
- 2. Agent Workload is an open-case population, not a productivity verdict.
- 3. Critical Escalations and Top Dealers are investigation queues; open the underlying record before acting.
Live route 02
Customer 360
The live customer selector and context surface for profile/KYC, wallet, service identity, subscription, allowances, sessions, recharges, cases, and lifecycle.
- 1. Select one authorized customer and verify profile/KYC first.
- 2. Match wallet, subscription, plan, MSISDN/IMSI/APN, and allowance context.
- 3. Use sessions, CCR events, recharges, cases, and lifecycle to explain—not replace—the source records.
Live route 03
Prepaid Customer Balances
The live prepaid population page for customer/subscription rows, plan context, remaining allowances, and Diameter usage.
- 1. Refresh and record the observation time.
- 2. Select the customer/subscription row and verify status and plan.
- 3. Reconcile displayed allowances to Balances, Usage Transactions, or Charging Sessions.
Live route 04
CDR Settlement Report
The live settlement report for date/service filters, sessions by service, rating groups, hourly volume, termination causes, and individual CDRs.
- 1. Set Date and Filter by service, then Load.
- 2. Compare Sessions by Service Type, Aggregated by Rating Group, and Hourly Volume.
- 3. Inspect Termination Causes and an Individual CDR before classifying a billing gap.
Live route 05
Payment Health
The live payment summary and failed-payment queue for provider, method, trend, payment code, amount, reason, and initiation time.
- 1. Use the status summaries and 14-day trend to define the population.
- 2. Open Latest Failed Payments and capture the payment Code, Provider, Method, Amount, Failure Reason, and Initiated time.
- 3. Reconcile the source Payment with gateway, invoice, wallet, retry, reversal, dispute, and owner context.
Live route 06
Roaming Operations
The live roaming page for sessions, partners, TAP files, zones, rate cards, and settlement exceptions.
- 1. Start with the session/partner/zone context and observation period.
- 2. Match the effective customer or wholesale rate card.
- 3. Compare the session charge with TAP and settlement evidence before assigning the variance.
Live route 07
Fraud Operations
The live fraud queue for severity, trend, alert code, score, auto action, assignee, fraud rule, and linked evidence.
- 1. Filter Low, Medium, High, or Critical and confirm the review population.
- 2. Open one Alert Code and inspect severity, score, status, auto action, assignee, and rule.
- 3. Preserve the alert and source signals; record disposition and restricted ownership.
Live route 08
Finance Home
The live finance page for headline numbers, revenue trend, commission status, tax calendar, and finance queues.
- 1. Record the reporting date and population before interpreting a headline.
- 2. Open the source invoice, payment, settlement, or tax record behind the number.
- 3. Do not close, write off, retry, or adjust from a headline view.
Live route 09
Customer 360 · detail evidence
A lower-page live capture showing recent sessions, CCR events, recharge evidence, open cases, and lifecycle state for the selected customer. Use it to finish the trace after the profile and subscription checks.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 10
Compliance review workspace
Orient to KYC, AML, risk ownership, and the evidence needed before a restricted decision.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 11
CSR queue and customer service
Use the live queue to connect cases, interactions, customer context, and service-impacting work.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 12
Device and IMEI monitoring
Identify where to inspect blacklist/graylist status, recent IMEI changes, suspicious changes, and device models.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 13
Number portability operations
Follow MNP status, carrier response, SLA, donor/recipient context, and the evidence route for rejection or repair.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 14
Subscriber search
Start a controlled lookup by customer, MSISDN, IMSI, or subscription before opening the authoritative record.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 15
Customer portal view
Understand the customer-facing view of balances, plans, usage, payment status, and support entry points.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 16
Usage pattern heatmap
Use metric, date range, day, and hour to identify concentration; always trace a pattern to usage records before action.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 17
Usage charts
Read service-volume and trend charts as an operational signal, then reconcile the selected population to source usage.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 18
Usage by radio access technology
Compare 4G, 5G, and 3G usage by customer or period without confusing network mix with billing impact.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 19
Corporate account portal
Use account hierarchy, shared pools, employee lines, billing responsibility, and enterprise-level service context together.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 20
Dealer performance
Read activations, revenue, commissions, and quality signals as partner performance evidence—not as a substitute for source records.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 21
Family plan management
Inspect the primary account, member lines, shared allowances, allocations, and plan changes before adjusting a member.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 22
Loyalty and rewards
Use tier, points earned, redemptions, rewards stock, and customer rows to explain the points position.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 23
Commission ledger
Trace partner commission status, qualifying recharge/order, calculation, dispute, and settlement evidence.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 24
Churn cohort analysis
Read cohort, tenure, risk, and revenue signals as analysis; open the customer/subscription source before intervention.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 25
Campaign attribution
Connect campaign, touchpoint, conversion, subscriber, and revenue context without inventing attribution links.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 26
Erasure request queue
Follow privacy-request status, due date, identity evidence, scope, approvals, and completion proof.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 27
Self-service SIM swap
Review identity challenge, old/new SIM, approval state, fraud guard, and activation consequence before completion.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 28
eSIM QR issuance
Check subscription, device compatibility, issuance status, expiry, and secret-handling expectations.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 29
Customer usage dashboard
Use the customer-level usage view to connect allowance, service, period, and source-event evidence.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Live route 30
Dealer portal
Use the dealer-facing workspace to navigate orders, activations, inventory, and commission-owned work.
- 1. Orient to the live controls and current data population.
- 2. Open the named source record or linked queue before interpreting the visual.
- 3. Capture the record ID, state, time, owner, and evidence needed for the handoff.
Verified page directory
Every custom page has a canonical live route
Duplicate names are shown with their exact slug. Use the primary slug for training unless an Admin tells you to use the duplicate variant.
HomeCompliancenew-home-complianceHomeCompliancenew-home-compliance-1HomeCSR Homenew-home-csrHomeCSR Homenew-home-csr-1OvervieweSIM QRnew-esim-qrOverviewSelf SIM Swapnew-self-sim-swapHomeFinance Homenew-home-financeHomeFinance Homenew-home-finance-1HomeManager Homenew-home-managerOperationsDevice & Fraud Monitornew-device-monitorOverviewFraud Operationsnew-fraud-opsOperationsNumber Portability & Auctionsnew-mnp-dashboardOperationsRoaming Operationsnew-roaming-dashboardOverviewCDR Settlement Reportnew-cdr-settlementOverviewPayment Healthnew-payment-healthOverviewPrepaid Customer Balancesnew-prepaid-customer-balancesOverviewDealer Performancenew-dealer-performanceOverviewUsage by RAT (4G/5G/3G)new-usage-by-ratOverviewCustomer Portalnew-customer-portalOverviewSubscriber Searchnew-subscriber-searchOverviewWhite-Label Portalnew-white-label-portalOverviewUsage Patterns Heatmapnew-usage-heatmapOverviewCorporate Portalnew-corporate-portalOverviewCustomer 360new-customer-360DashboardCustomer Usage Dashboardnew-customer-usage-dashboardHomeDealer Portalnew-home-dealerHomeDealer Portalnew-home-dealer-1OverviewErasure Queuenew-erasure-queueOverviewUsage Chartsnew-usage-chartsOverviewFamily Plan Managementnew-family-plan-mgmtOverviewLoyalty Programnew-loyalty-overviewOverviewCommission Ledgernew-commission-ledgerOverviewCampaign Attributionnew-campaign-attributionOverviewChurn Cohort Analysisnew-churn-cohort
Automation playbook
Workflows & automation
The register below is copied from the ten saved proto definitions in the live app. Study every node, connection, branch, and persisted result without activating or executing anything. The lab cards underneath turn each saved definition into a concrete read-only reasoning exercise.
Current-state rule
All ten saved workflows are inactive. Five are five-node trigger → Code Executor → IF → ERP AI branch graphs; five are two-node trigger → ERP AI update graphs. Their current persisted outcome is a source-record update, not the downstream Case, Dunning Action, notification, task, or history item a production process may eventually require.
WF 01Inactive · 5 nodes
KYC rejected -> compliance hold routing (complex)
Classifies the rejected customer as corporate or retail, routes the branch, and updates the triggering customer to Pending KYC. It does not create a Case, task, notification, or service hold record.
01
Customer KYC is rejected
appEventTriggerPurpose
Listen for the KYC Status transition.
Why it is needed
Without a field-scoped event, unrelated customer updates could route into compliance.
Logic
record_updated on Customers; field yqnJ; changed_to select value 4.
Inputs
Customers record · recordId · rawCells
Outputs
main event item
02
Assess KYC rejection
code.executorPurpose
Normalize customer type and choose compliance ownership.
Why it is needed
The branch needs a deterministic route and SLA rather than relying on display text.
Logic
Reads Name, Customer Type, and Is Corporate/rawCells.wFfI; emits route corporate or retail, owner, SLA 4 or 24 hours, and message.
Inputs
record · rawCells · recordId
Outputs
$data.route · $data.reviewOwner · $data.reviewSlaHours · $data.message
03
Compliance handling route
ifPurpose
Select corporate versus retail ownership.
Why it is needed
The two routes need different review ownership while preserving the same source-state update.
Logic
Tests {{$data.route}} equals corporate; true is corporate, false is retail.
Inputs
$data.route
Outputs
true · false
04
Place corporate customer on KYC hold
erpaiNodePurpose
Write Pending KYC to the triggering customer.
Why it is needed
The source record must expose the hold state to operators.
Logic
ERP AI current-app update-record on Customers using ID {{$data.businessId}}.
Inputs
$data.businessId
Outputs
updated Customers record
Persisted result
Customers.Status = Pending KYC (jhdQ = 4)
05
Place retail customer on KYC hold
erpaiNodePurpose
Write Pending KYC to the triggering customer.
Why it is needed
Retail still needs a governed source-state update even though the reviewer differs.
Logic
Same Customers update-record form as the corporate branch.
Inputs
$data.businessId
Outputs
updated Customers record
Persisted result
Customers.Status = Pending KYC (jhdQ = 4)
Connections and branch order
Customer KYC is rejected.main → Assess KYC rejection.mainAssess KYC rejection.main → Compliance handling route.mainroute.true → corporate holdroute.false → retail holdReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 02Inactive · 5 nodes
MNP rejected -> porting support routing (complex)
Normalizes the rejection reason, routes manual donor/UPC issues separately from account remediation, and writes a note to the MNP request. It does not create status history, a Case, a task, or a customer interaction.
01
MNP request is rejected
appEventTriggerPurpose
Detect the rejected portability transition.
Why it is needed
The follow-up belongs to rejected requests only.
Logic
record_updated on MNP Requests; field z6WA; changed_to select value 7.
Inputs
MNP request record · recordId
Outputs
main event item
02
Classify MNP rejection
code.executorPurpose
Classify the rejection for manual porting versus account remediation.
Why it is needed
UPC, donor, validation, and malformed reasons require a different owner and priority.
Logic
Reads MNP Code, MSISDN/rawCells.bdkI, and Rejection Reason; normalizes text and detects upc|donor|validation|malformed.
Inputs
record · rawCells · recordId
Outputs
$data.manualReview · $data.route · $data.priority · $data.message
03
Porting follow-up route
ifPurpose
Choose manual porting escalation versus account exception.
Why it is needed
A donor/UPC problem cannot be handled like an account cleanup.
Logic
Tests {{$data.route}} equals manual; true is manual, false is account.
Inputs
$data.route
Outputs
true · false
04
Record manual porting escalation
erpaiNodePurpose
Preserve a manual escalation note on the request.
Why it is needed
The source request needs a visible handoff while it remains rejected.
Logic
ERP AI update-record on MNP Requests using ID {{$data.businessId}}.
Inputs
$data.businessId · $data.message
Outputs
updated MNP request
Persisted result
Notes = Manual porting escalation: {{$data.message}}
05
Record account exception
erpaiNodePurpose
Preserve account-remediation context on the request.
Why it is needed
The operator needs the reason and next route without overwriting the rejection.
Logic
Same update-record form; uses the account-exception note prefix.
Inputs
$data.businessId · $data.message
Outputs
updated MNP request
Persisted result
Notes = Account exception follow-up: {{$data.message}}
Connections and branch order
MNP request is rejected.main → Classify MNP rejection.mainClassify MNP rejection.main → Porting follow-up route.mainroute.true → manual escalationroute.false → account exceptionReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 03Inactive · 5 nodes
Critical fraud alert -> immediate block routing (complex)
Ranks severity and score, routes block versus investigate, and updates the triggering alert. The saved graph does not create a restricted Case or investigation task.
01
Critical fraud alert
appEventTriggerPurpose
Detect a critical severity transition.
Why it is needed
Critical alerts require an immediate risk route.
Logic
record_updated on Fraud Alerts; field NtK6; changed_to select value 4.
Inputs
Fraud Alert record · recordId
Outputs
main event item
02
Assess fraud severity
code.executorPurpose
Convert severity and score into a response route and window.
Why it is needed
A numeric score can escalate an alert even when the label is not Critical.
Logic
Reads Alert Code, Severity, Score/rawCells.5MsR; block if rank >= 4 or score >= 90; emits 5 or 30 minute window.
Inputs
record · rawCells · recordId
Outputs
$data.route · $data.score · $data.responseWindowMinutes · $data.processedAt
03
Block or investigate
ifPurpose
Choose the block branch or investigation branch.
Why it is needed
The branch determines whether Auto Action Taken is recorded.
Logic
Tests {{$data.route}} equals block; true is block, false is investigate.
Inputs
$data.route
Outputs
true · false
04
Block critical fraud alert
erpaiNodePurpose
Move the alert to investigation and record a blocked action.
Why it is needed
The saved source state must show the risk action taken.
Logic
ERP AI update-record on Fraud Alerts using ID {{$data.businessId}} and {{$data.processedAt}}.
Inputs
$data.businessId · $data.processedAt
Outputs
updated Fraud Alert
Persisted result
Status = Under Investigation; Auto Action Taken = Transaction Blocked; Assigned To = Risk Operations
05
Investigate fraud alert
erpaiNodePurpose
Move the alert to investigation without claiming a block.
Why it is needed
A lower route must not imply that a transaction was blocked.
Logic
Same update-record form but omits Auto Action Taken.
Inputs
$data.businessId · $data.processedAt
Outputs
updated Fraud Alert
Persisted result
Status = Under Investigation; Assigned To = Risk Operations
Connections and branch order
Critical fraud alert.main → Assess fraud severity.mainAssess fraud severity.main → Block or investigate.mainroute.true → blockroute.false → investigateReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 04Inactive · 5 nodes
Payment failed -> collections routing (complex)
Normalizes the failure reason and routes retryable failures versus collections review, writing only a note on the triggering payment.
01
Payment fails
appEventTriggerPurpose
Detect a payment entering Failed.
Why it is needed
The failed state is the source event for controlled follow-up.
Logic
record_updated on Payments; field lLT3; changed_to select value 4.
Inputs
Payment record · recordId
Outputs
main event item
02
Classify payment failure
code.executorPurpose
Normalize gateway failure text and decide retryability.
Why it is needed
Temporary/network/timeout reasons should not immediately become collections actions.
Logic
Reads Payment Code, Amount/rawCells.owY8, Failure Reason/rawCells.TYqv; detects retry|timeout|temporary|network|issuer decline.
Inputs
record · rawCells · recordId
Outputs
$data.retryable · $data.retryWindowHours · $data.route · $data.message
03
Retryability decision
ifPurpose
Separate retry plan from collections hold.
Why it is needed
The route protects customers from premature collections while retaining a collection path for non-retryable failures.
Logic
Tests {{$data.route}} equals retry; true is retry, false is collections.
Inputs
$data.route
Outputs
true · false
04
Record retry plan
erpaiNodePurpose
Write retry context to the payment.
Why it is needed
The source record needs a visible handoff for the retry owner.
Logic
ERP AI update-record on Payments using ID {{$data.businessId}}.
Inputs
$data.businessId · $data.message
Outputs
updated Payment
Persisted result
Notes = Retry orchestration queued: {{$data.message}}
05
Record collections hold
erpaiNodePurpose
Write collections-review context to the payment.
Why it is needed
The operator needs to distinguish a non-retryable failure from a transient failure.
Logic
Same update-record form with collections note prefix.
Inputs
$data.businessId · $data.message
Outputs
updated Payment
Persisted result
Notes = Collections review required: {{$data.message}}
Connections and branch order
Payment fails.main → Classify payment failure.mainClassify payment failure.main → Retryability decision.mainroute.true → retry planroute.false → collections holdReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 05Inactive · 5 nodes
Invoice overdue -> finance dunning routing (complex)
Calculates days overdue and balance-based dunning tier, then writes standard or escalated context to the triggering invoice. It does not create a Dunning Action.
01
Invoice becomes overdue
appEventTriggerPurpose
Detect an invoice entering Overdue.
Why it is needed
Dunning context should be calculated only after the lifecycle transition.
Logic
record_updated on Invoices; field XwAP; changed_to select value 5.
Inputs
Invoice record · recordId
Outputs
main event item
02
Calculate dunning context
code.executorPurpose
Calculate days overdue and dunning tier.
Why it is needed
Balance and age determine standard versus escalated review.
Logic
Reads Balance Due/rawCells.U6Ms, Due Date/rawCells.00Qd, and Invoice Number; intensive when balance >= 1000 or age >= 14, escalated when age >= 7.
Inputs
record · rawCells · recordId
Outputs
$data.daysOverdue · $data.dunningTier · $data.route · $data.message
03
Escalation policy
ifPurpose
Choose escalated versus standard dunning context.
Why it is needed
High-balance or aged invoices need a different owner and review priority.
Logic
Tests {{$data.route}} equals escalate; true is escalated, false is standard.
Inputs
$data.route
Outputs
true · false
04
Record escalated dunning
erpaiNodePurpose
Write escalation context to the invoice.
Why it is needed
The source invoice should show why it was prioritized.
Logic
ERP AI update-record on Invoices using ID {{$data.businessId}}.
Inputs
$data.businessId · $data.message
Outputs
updated Invoice
Persisted result
Notes = Escalated dunning: {{$data.message}}
05
Record standard dunning
erpaiNodePurpose
Write standard dunning context to the invoice.
Why it is needed
The source invoice still needs an explainable route even below escalation thresholds.
Logic
Same update-record form with standard note prefix.
Inputs
$data.businessId · $data.message
Outputs
updated Invoice
Persisted result
Notes = Standard dunning: {{$data.message}}
Connections and branch order
Invoice becomes overdue.main → Calculate dunning context.mainCalculate dunning context.main → Escalation policy.mainroute.true → escalated dunningroute.false → standard dunningReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 06Inactive · 2 nodes
Invoice written off -> collections audit routing
A two-node source-update route that writes a collections-audit handoff note to the triggering invoice. It does not create an approval or audit record.
01
Invoice is written off
appEventTriggerPurpose
Detect the write-off transition.
Why it is needed
Write-off requires downstream review context.
Logic
record_updated on Invoices; field XwAP; changed_to select value 7.
Inputs
Invoice record · recordId
Outputs
main event item
02
Record write-off audit handoff
erpaiNodePurpose
Write invoice number and balance into Notes.
Why it is needed
The current graph preserves context even though it has no separate audit artifact.
Logic
ERP AI update-record on Invoices using {{$record["ID"]}}, {{$record["Invoice Number"]}}, and {{$record["Balance Due"]}}.
Inputs
$record.ID · $record.Invoice Number · $record.Balance Due
Outputs
updated Invoice
Persisted result
Notes = Collections audit handoff recorded for written-off invoice …
Connections and branch order
Invoice is written off.main → Record write-off audit handoff.mainReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 07Inactive · 2 nodes
Subscription suspended -> service recovery routing
A two-node source-update route that records service-recovery context on the suspended subscription. It does not create a recovery task or status-history row.
01
Subscription is suspended
appEventTriggerPurpose
Detect the suspension transition.
Why it is needed
Recovery review begins from the exact lifecycle change.
Logic
record_updated on Subscriptions; field BFCp; changed_to select value 2.
Inputs
Subscription record · recordId
Outputs
main event item
02
Route suspended subscription
erpaiNodePurpose
Write recovery instructions to the subscription.
Why it is needed
Operators need a visible reminder to validate balance, dunning, and contact before restoration.
Logic
ERP AI update-record on Subscriptions using {{$record["ID"]}} and {{$record["MSISDN"]}}.
Inputs
$record.ID · $record.MSISDN
Outputs
updated Subscription
Persisted result
Notes = Service recovery routed for suspended MSISDN …
Connections and branch order
Subscription is suspended.main → Route suspended subscription.mainReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 08Inactive · 2 nodes
High fraud alert -> investigation routing
A two-node route that moves a high-severity alert to Under Investigation and assigns Risk Operations. It does not create a case or notification.
01
High-severity fraud alert
appEventTriggerPurpose
Detect a high severity transition.
Why it is needed
High alerts need an accountable investigation owner.
Logic
record_updated on Fraud Alerts; field NtK6; changed_to select value 3.
Inputs
Fraud Alert record · recordId
Outputs
main event item
02
Start fraud investigation
erpaiNodePurpose
Set investigation status and ownership.
Why it is needed
The source alert must show that it is being worked.
Logic
ERP AI update-record on Fraud Alerts using {{$record["ID"]}} and {{$now}}.
Inputs
$record.ID · $now
Outputs
updated Fraud Alert
Persisted result
Status = Under Investigation; Assigned To = Risk Operations; Assigned At = {{$now}}
Connections and branch order
High-severity fraud alert.main → Start fraud investigation.mainReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 09Inactive · 2 nodes
Payment disputed -> chargeback review routing
A two-node route that writes chargeback-review context to the disputed payment. It does not create a chargeback case or freeze a wallet.
01
Payment becomes disputed
appEventTriggerPurpose
Detect the disputed payment state.
Why it is needed
Disputes need a review route without changing the original payment evidence.
Logic
record_updated on Payments; field lLT3; changed_to select value 6.
Inputs
Payment record · recordId
Outputs
main event item
02
Route disputed payment
erpaiNodePurpose
Write payment code and amount into Notes.
Why it is needed
The source payment retains a visible audit handoff.
Logic
ERP AI update-record on Payments using {{$record["ID"]}}, {{$record["Payment Code"]}}, and {{$record["Amount"]}}.
Inputs
$record.ID · $record.Payment Code · $record.Amount
Outputs
updated Payment
Persisted result
Notes = Chargeback review routed for payment …
Connections and branch order
Payment becomes disputed.main → Route disputed payment.mainReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
WF 10Inactive · 2 nodes
Invoice disputed -> billing review routing
A two-node route that writes billing-audit context to the disputed invoice. It does not create a dispute case or reconciliation task.
01
Invoice becomes disputed
appEventTriggerPurpose
Detect the disputed invoice state.
Why it is needed
Dispute review starts from the source invoice transition.
Logic
record_updated on Invoices; field XwAP; changed_to select value 6.
Inputs
Invoice record · recordId
Outputs
main event item
02
Route disputed invoice
erpaiNodePurpose
Write invoice number and balance into Notes.
Why it is needed
The source invoice retains a review handoff even without a separate case artifact.
Logic
ERP AI update-record on Invoices using {{$record["ID"]}}, {{$record["Invoice Number"]}}, and {{$record["Balance Due"]}}.
Inputs
$record.ID · $record.Invoice Number · $record.Balance Due
Outputs
updated Invoice
Persisted result
Notes = Billing dispute routed for audit …
Connections and branch order
Invoice becomes disputed.main → Route disputed invoice.mainReview rule
Read the graph in order, predict the branch from an authorized UAT record, then compare the actual node mappings in the proto. Never activate or execute this saved definition from the Academy.
Scenario labs: predict the graph before you open the proto
Use one authorized UAT source record. Predict the branch and persisted fields first, then open the linked proto and compare the actual node mapping. Do not enable, execute, or mutate a saved proto from the Academy.
LAB 01Branch lab
KYC rejected -> compliance hold routing (complex)
Classifies the rejected customer as corporate or retail, routes the branch, and updates the triggering customer to Pending KYC. It does not create a Case, task, notification, or service hold record.
- Start with
- Customers · KYC Status = Rejected
- Node sequence
- Customer KYC is rejected → Assess KYC rejection → Compliance handling route → Place corporate customer on KYC hold → Place retail customer on KYC hold
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Place corporate customer on KYC hold: Customers.Status = Pending KYC (jhdQ = 4) · Place retail customer on KYC hold: Customers.Status = Pending KYC (jhdQ = 4)
LAB 02Branch lab
MNP rejected -> porting support routing (complex)
Normalizes the rejection reason, routes manual donor/UPC issues separately from account remediation, and writes a note to the MNP request. It does not create status history, a Case, a task, or a customer interaction.
- Start with
- MNP Requests · Status = Rejected
- Node sequence
- MNP request is rejected → Classify MNP rejection → Porting follow-up route → Record manual porting escalation → Record account exception
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Record manual porting escalation: Notes = Manual porting escalation: {{$data.message}} · Record account exception: Notes = Account exception follow-up: {{$data.message}}
LAB 03Branch lab
Critical fraud alert -> immediate block routing (complex)
Ranks severity and score, routes block versus investigate, and updates the triggering alert. The saved graph does not create a restricted Case or investigation task.
- Start with
- Fraud Alerts · Severity = Critical
- Node sequence
- Critical fraud alert → Assess fraud severity → Block or investigate → Block critical fraud alert → Investigate fraud alert
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Block critical fraud alert: Status = Under Investigation; Auto Action Taken = Transaction Blocked; Assigned To = Risk Operations · Investigate fraud alert: Status = Under Investigation; Assigned To = Risk Operations
LAB 04Branch lab
Payment failed -> collections routing (complex)
Normalizes the failure reason and routes retryable failures versus collections review, writing only a note on the triggering payment.
- Start with
- Payments · Status = Failed
- Node sequence
- Payment fails → Classify payment failure → Retryability decision → Record retry plan → Record collections hold
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Record retry plan: Notes = Retry orchestration queued: {{$data.message}} · Record collections hold: Notes = Collections review required: {{$data.message}}
LAB 05Branch lab
Invoice overdue -> finance dunning routing (complex)
Calculates days overdue and balance-based dunning tier, then writes standard or escalated context to the triggering invoice. It does not create a Dunning Action.
- Start with
- Invoices · Status = Overdue
- Node sequence
- Invoice becomes overdue → Calculate dunning context → Escalation policy → Record escalated dunning → Record standard dunning
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Record escalated dunning: Notes = Escalated dunning: {{$data.message}} · Record standard dunning: Notes = Standard dunning: {{$data.message}}
LAB 06Source-update lab
Invoice written off -> collections audit routing
A two-node source-update route that writes a collections-audit handoff note to the triggering invoice. It does not create an approval or audit record.
- Start with
- Invoices · Status = Written Off
- Node sequence
- Invoice is written off → Record write-off audit handoff
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Record write-off audit handoff: Notes = Collections audit handoff recorded for written-off invoice …
LAB 07Source-update lab
Subscription suspended -> service recovery routing
A two-node source-update route that records service-recovery context on the suspended subscription. It does not create a recovery task or status-history row.
- Start with
- Subscriptions · Status = Suspended
- Node sequence
- Subscription is suspended → Route suspended subscription
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Route suspended subscription: Notes = Service recovery routed for suspended MSISDN …
LAB 08Source-update lab
High fraud alert -> investigation routing
A two-node route that moves a high-severity alert to Under Investigation and assigns Risk Operations. It does not create a case or notification.
- Start with
- Fraud Alerts · Severity = High
- Node sequence
- High-severity fraud alert → Start fraud investigation
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Start fraud investigation: Status = Under Investigation; Assigned To = Risk Operations; Assigned At = {{$now}}
LAB 09Source-update lab
Payment disputed -> chargeback review routing
A two-node route that writes chargeback-review context to the disputed payment. It does not create a chargeback case or freeze a wallet.
- Start with
- Payments · Status = Disputed
- Node sequence
- Payment becomes disputed → Route disputed payment
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Route disputed payment: Notes = Chargeback review routed for payment …
LAB 10Source-update lab
Invoice disputed -> billing review routing
A two-node route that writes billing-audit context to the disputed invoice. It does not create a dispute case or reconciliation task.
- Start with
- Invoices · Status = Disputed
- Node sequence
- Invoice becomes disputed → Route disputed invoice
- Connection question
- Which input crosses each edge, and what happens when the branch is false?
- Persisted result
- Route disputed invoice: Notes = Billing dispute routed for audit …
Implementation guide
Data loading order
Load the app in dependency order so every reference, lifecycle state, charge, and customer outcome can be traced from its source. Each phase now states what to load, how to validate it, and what must block the next import.
Use this sequence for a new tenant, migration, or reset
Complete each phase, validate it, and record the import batch before moving to the next. The order prevents orphaned references, impossible status transitions, and invoices that cannot be explained.
01
Phase 01
Reference and control values
What to doLoad stable lookup values first. Keep codes immutable and make labels, ordering, active state, and effective dates explicit.
Validate before continuingEvery select, formula, workflow guard, and form default resolves to a valid option; no business record is loaded yet.
Do notDo not start with customers or invoices while status and reference values are still changing.
02
Phase 02
Partners, tenants, and network context
What to doCreate the commercial and data-isolation boundaries that later records will reference.
Validate before continuingEach partner has an owner, tenant scope, active dates, currency, and permitted catalog/rate boundary.
Do notDo not load partner transactions or Partner Commissions before the partner and tenant key exists.
03
Phase 03
Product catalog and charging configuration
What to doLoad products from broadest dependency to narrowest: Services → Tariff Plans → Bundles → Bundle Components → Business Rules → Promotions. Version changes instead of overwriting active rules.
Validate before continuingEvery plan has currency, price, eligibility, effective dates, tax treatment, and at least one valid charging path.
Do notDo not activate a plan that references a missing service, bundle, business rule, tax rate, or tenant.
04
Phase 04
Customer identity and account hierarchy
What to doCreate the customer master and verify identity before attaching service or financial records.
Validate before continuingCustomer identity, KYC status, customer type, billing responsibility, privacy scope, and duplicate checks are complete.
Do notDo not create active subscriptions, invoices, or payment promises for an unresolved or duplicate customer.
05
Phase 05
Network inventory and service identity
What to doLoad allocatable network identities and inventory before creating subscriptions. Keep serial/number uniqueness enforced.
Validate before continuingEvery asset has a lifecycle state, ownership, availability, effective dates, and no duplicate identifier.
Do notDo not assign an inventory item that is already active, reserved by another tenant, or outside the customer’s region.
06
Phase 06
Subscriptions and service identity
What to doLink Customers → Subscriptions → MSISDN Pool / SIM Inventory / IMSI Pool → Tariff Plans / Services. Create lifecycle history at the same time as the current record.
Validate before continuingCustomer, network identity, plan, tenant/partner, KYC, effective dates, and status transition all agree.
Do notDo not load balances, usage, or invoices against a subscription that is not valid for the event date.
07
Phase 07
Balances, wallets, allowances, and counters
What to doCreate opening state, then append the opening transaction or adjustment so the state is explainable.
Validate before continuingEvery balance has a subscription/wallet owner, currency or unit, status, expiry, opening evidence, and a before/after trail.
Do notDo not type a balance correction directly when an opening transaction, recharge, credit, or adjustment should explain it.
08
Phase 08
Source usage and sessions
What to doLoad immutable source events in event-time order, preserve source IDs, then resolve the subscriber and service context.
Validate before continuingSource, event time, MSISDN/subscriber, quantity, service, partner/zone, duplicate key, and ingestion outcome are present.
Do notDo not create invoice lines from an unvalidated source event or repair a source by overwriting its original payload.
09
Phase 09
Rating, charges, and billing documents
What to doProcess source usage → normalized usage → rated charge → balance/ledger impact → invoice line → invoice. Keep the source reference on every derived record.
Validate before continuingUsage-to-charge completeness, rule version, tax, rounding, currency, invoice totals, and billing-period eligibility reconcile.
Do notDo not finalize invoices while unbilled CDRs, open sessions, missing tax, broken references, or unresolved high-value exceptions remain.
10
Phase 10
Cash, collections, assurance, and support
What to doLoad or process financial and assurance outcomes only after the invoice/customer context exists. Keep every decision linked to its source and owner.
Validate before continuingGateway state, invoice/payment state, dunning stage, adjustment approval, risk disposition, case SLA, and interaction outcome agree.
Do notDo not close a period, write off value, suspend service, or close a risk case without approval and evidence.
Record the control envelope
Keep source file/query, batch ID, operator, import timestamp, target table, row count, rejected count, and validation result. A row count without rejected-row evidence is not a completed load.
Roll back the phase, not the history
Quarantine failed rows, preserve the source payload, correct the dependency, and rerun only the affected phase. Do not delete valid prior history to make a later import pass.
Prove the full trace
Use one controlled record to trace customer → subscription → usage → charge → invoice → payment. Then test a missing-reference, duplicate, stale-date, and rejected-state path.
Operator rule
When a later phase exposes a missing or invalid earlier reference, stop the later import, correct the earlier phase, and rerun only the affected batch. Do not patch around a broken relationship in the destination table.
Technical reference
Data model
The authoritative object map, direct references, shared-context reconciliations, lifecycle states, and ownership semantics from the live schema. Use the expanded table cards to see the current UAT count, known states, fields, owner, and join rule.
CommercialCustomersAccount HierarchySubscriptionsTariff Plans
↓
OperationalCall Detail RecordsUsage TransactionsCharging SessionsBalances
↓
FinancialBilling PeriodsInvoicesInvoice Line ItemsPayments
↓
AssuranceFraud AlertsAML AlertsCasesErasure Requests
Customers
Account, identity, hierarchy, contact, and service relationship context.
Service identity
Subscriptions, MSISDN, SIM, IMSI, device, and lifecycle history.
Subscriptions
An active or historical customer service relationship with plan and lifecycle state.
Tariff Plans
Price, allowance, tax, effective-date, and eligibility rules.
Usage Transactions
Normalized voice, SMS, data, roaming, and service events.
Call Detail Records
Source usage evidence received from network or partner feeds.
Charging Sessions
Online or offline charging context, quota, and balance impact.
Balances & Wallets
Prepaid, postpaid, bonus, wallet, and ledger positions.
Invoices
A customer-facing billing document with line-item and tax detail.
Payments
Gateway, capture, settlement, reversal, and application outcomes.
Recharges
Prepaid top-up, voucher, adjustment, and resulting balance event.
Fraud & AML
Alerts, rules, identity signals, dispositions, and investigation history.
Verified joins
How to connect records without inventing relationships
Direct reference means open the named field. Shared context means match business keys and time. Derived outcome means follow the real intermediate records.
Subscriptions · Customer → Customers
The subscription points to the customer that owns the service.
Open Subscriptions ↗Open Customers ↗Subscriptions · Current Plan → Tariff Plans
Use the plan reference plus event/effective dates to explain eligibility and price.
Open Subscriptions ↗Open Tariff Plans ↗Subscriptions · Current Device → Devices
The service identity is connected to the current device context.
Open Subscriptions ↗Open Devices ↗Subscriptions · Current Roaming Zone → Roaming Zones
The subscription's current roaming context is a direct configuration reference.
Open Subscriptions ↗Open Roaming Zones ↗Account Hierarchy · Parent Customer / Child Customer → Customers
Use the hierarchy to determine billing responsibility and customer scope.
Open Account Hierarchy ↗Open Customers ↗Wallets · Customer → Customers
A wallet belongs to a customer; wallet transactions explain balance movement.
Open Wallets ↗Open Customers ↗Balances · Subscription / Tariff Plan → Subscriptions / Tariff Plans
The balance is current state; usage, recharge, and event time explain why it changed.
Open Balances ↗Compare the named target tables in the catalog.Usage Transactions · Charging Session / Subscription / Balance → Charging Sessions / Subscriptions / Balances
Usage is directly tied to charging, service, and balance context.
Open Usage Transactions ↗Compare the named target tables in the catalog.Call Detail Records · Charging Session / Subscription / Customer / Tariff Plan → Charging Sessions / Subscriptions / Customers / Tariff Plans
The CDR is the immutable source event and has direct corroborating context.
Open Call Detail Records ↗Compare the named target tables in the catalog.Invoices · Customer / Account Hierarchy / Billing Period → Customers / Account Hierarchy / Billing Periods
Invoice ownership, billing responsibility, and period eligibility are direct references.
Open Invoices ↗Compare the named target tables in the catalog.Invoice Line Items · Invoice / Subscription → Invoices / Subscriptions
Line items are the direct bridge from invoice total to service-level charges.
Open Invoice Line Items ↗Compare the named target tables in the catalog.Payments · Customer / Wallet / Recharge → Customers / Wallets / Recharges
Payment records point to the customer and payment-side balance/recharge context.
Open Payments ↗Compare the named target tables in the catalog.Dunning Actions · Invoice / Customer → Invoices / Customers
Collections actions point to the overdue invoice and its customer.
Open Dunning Actions ↗Compare the named target tables in the catalog.Fraud Alerts · Rule / Subscription / Customer / Related Case → Fraud Rules / Subscriptions / Customers / Cases
Use the alert's direct links for investigation and disposition.
Open Fraud Alerts ↗Compare the named target tables in the catalog.MNP Requests · Customer / Subscription → Customers / Subscriptions
Portability is grounded in the customer and service being moved.
Open MNP Requests ↗Compare the named target tables in the catalog.Roaming Sessions · Subscription / Partner / Zone → Subscriptions / Roaming Partners / Roaming Zones
Roaming charges require the visited partner, zone, and subscription context.
Open Roaming Sessions ↗Compare the named target tables in the catalog.Partner Commissions · Partner / Recharge → Distribution Partners / Recharges
Commission must retain the qualifying partner and recharge event.
Open Partner Commissions ↗Compare the named target tables in the catalog.Commission Disputes · Commission → Partner Commissions
The dispute is a governed child of the commission record.
Open Commission Disputes ↗Open Partner Commissions ↗Role Assignments · User / Role → Users / Roles
Access is assigned through the live user-to-role records.
Open Role Assignments ↗Compare the named target tables in the catalog.Usage Transactions → Invoices
There is no direct Usage Transactions → Invoices reference; reconcile through charge/rating output and Invoice Line Items.
Open Usage Transactions ↗Open Invoices ↗Invoices → Payments
There is no direct Invoices → Payments reference in the live schema; match customer, amount, invoice allocation, gateway reference, and time.
Open Invoices ↗Open Payments ↗Payments → Dunning Actions
There is no direct Payments → Dunning Actions reference; reconcile payment state, invoice overdue state, and collection timing.
Open Payments ↗Open Dunning Actions ↗Fraud Alerts → MNP Requests
There is no direct alert-to-port reference; match customer, subscription, MSISDN, timing, and case context.
Open Fraud Alerts ↗Open MNP Requests ↗MNP Requests → Cases
A case may be created or linked by an operator, but the live MNP schema does not provide a direct Case reference.
Open MNP Requests ↗Open Cases ↗Tariff Plans → Bundles
Do not assume a direct plan-to-bundle column; reconcile eligibility, effective dates, and configured offering context.
Open Tariff Plans ↗Open Bundles ↗AML Alerts → Erasure Requests
Regulated monitoring and privacy requests are separate governed paths; do not imply one creates or owns the other.
Open AML Alerts ↗Open Erasure Requests ↗Optional deep reference
49 core tables mappedOpen the table catalog only when you need field-level detail
The app contains 118 tables. The Academy keeps the detailed 49-table operational map closed by default; every mapped card now opens the live table route. Use the app’s table browser for the remaining tables.
Detailed table cards are hidden.Select a domain above, or choose All domains, to open them.
| Object | Lifecycle | Operating rule |
|---|---|---|
| Subscription | Active → Suspended → Terminated · Port Out · Port In Pending | Use the configured state values; verify customer, plan, identity, service, and portability evidence before changing state. |
| Usage / CDR | Received → Validated → Rated → Billed / Rejected | Preserve source evidence and explain every rejected or delayed outcome. |
| Invoice | Draft → Generated → Issued → Partially Paid → Paid / Overdue | Finalization requires line, tax, customer, and period checks. |
| Payment | Initiated → Pending → Captured → Settled / Failed / Reversed | Do not equate gateway capture with account reconciliation. |
| MNP Request | Submitted → Validating → Accepted / Rejected → Completed | Every transition needs regulatory and customer evidence. |
Support center
Troubleshooting
Diagnose behavior systematically, preserve history, and escalate with the evidence needed for fast resolution.
Diagnostic 01
A page or table is not visible
Work through these checks in order. Preserve the source record and audit trail.
- Confirm the correct ERP•AI organization and app.
- Check the role, page category, and default home resolution.
- Open the app navigation rather than a stale bookmark.
- Ask an Admin for a read-only access review.
Escalation
Send the role, missing surface, app URL, and a screenshot of the navigation.
Send the role, missing surface, app URL, and a screenshot of the navigation.
Universal diagnostic decision tree
- ScopeOne user, record, view, or the whole app?
- AccessConfirm role, tenant, owner, and lifecycle.
- DataVerify fields, relationships, dates, and filters.
- AutomationCheck trigger, guard, duplicate, and delay.
- EvidenceCapture expected, actual, ID, time, and screenshot.
- EscalateSend the smallest complete evidence pack.
Terminology
Glossary
Shared definitions for subscriber, usage, charging, billing, payment, partner, and risk work.
⌕
- Account hierarchy
- The parent, corporate, household, or billing relationships that organize customers and subscribers.
- ARPU
- Average revenue per user; interpret with period, cohort, product, and revenue-definition context.
- Balance
- A monetary or allowance position available to a subscriber, wallet, or account.
- Billing period
- A controlled time window used to collect eligible charges and generate invoices.
- Bundle
- A packaged set of allowances, services, or price benefits with eligibility and expiry rules.
- Capture
- A payment gateway outcome indicating that the payment has been accepted for capture; not always fully settled or applied.
- CDR
- Call Detail Record; source event evidence for voice, messaging, data, or other network activity.
- Charging session
- A tracked usage or service session used to authorize, measure, and apply charges.
- Dunning
- A governed sequence of notifications and collection actions for overdue invoices.
- Effective date
- The date and time when a plan, tariff, tax, or service rule is valid for evaluation.
- Invoice line item
- An itemized charge, discount, tax, credit, or adjustment contributing to an invoice total.
- MNP
- Mobile number portability; the controlled process of moving a number between networks.
- MVNO
- Mobile virtual network operator; a tenant or partner that uses network capacity under its own commercial context.
- Rating
- The calculation that converts usage into a charge using plans, bundles, tariffs, taxes, and effective dates.
- Reconciliation
- The process of proving that two or more systems or records agree on amount, state, and reference.
- Roaming
- Use of service on a visited network, usually governed by zone, partner, wholesale, and customer rates.
- Settlement
- Finalization of payment or partner amounts after capture, usage, or invoice processing.
- SIM / eSIM
- Physical or embedded subscriber identity module used to associate a device and service identity.
- Subscription
- The customer’s service relationship with a plan, lifecycle state, and effective dates.
- Tax rate
- A configured rate and jurisdiction rule applied to an eligible charge or invoice line.
- Tenant
- A partner or business boundary whose data, catalog, rate, or reporting scope must remain isolated.
- Unbilled CDR
- A source usage record that has not reached a valid invoice-eligible outcome.
- Usage counter
- A cumulative or period-specific count of consumed units used for allowance and billing decisions.
- Wallet
- A balance container used for prepaid, bonus, credit, or payment-related value.
- Workflow guard
- A condition that prevents unsafe, premature, or duplicate automation.
Change history
Release notes
Documentation and learning experience updates for the Telecom Billing Academy.
12Aug
2026
2026
Current
Application-grounded course overhaul
- Rechecked the operational Telecom Billing App and aligned training to its current 34-page navigation and 118-table UAT model.
- Rebuilt all 36 courses as five-stage learning journeys: brief, in-depth lessons, guided product walkthrough, live-record lab, and applied assessment.
- Expanded every lesson with objectives, field-by-field meanings, verification tests, decision rules, eight-step procedures, failure modes, current-state caveats, and evidence standards.
- Added deep lesson procedures with 12 ordered operator steps per lesson; each step now explains what to do, what to inspect, the expected result, the stop/escalation path, and the evidence to capture.
- Added explicit normal, missing-reference, and duplicate/stale/conflict branches, worked examples, reasoning prompts, and direct-reference versus shared-context versus derived-outcome relationship labels.
- Grounded Customer 360 training in its real selector, profile/KYC, wallet, subscription, allowance, session, CCR, recharge, case, and lifecycle panels.
- Added verified controls and outputs for Payment Health, Prepaid Customer Balances, CDR Settlement Report, Fraud Operations, Erasure Queue, Self SIM Swap, eSIM QR, Dealer Performance, Commission Ledger, Family Plan Management, CSR Home, Finance Home, Manager Home, Customer Usage Dashboard, Dealer Portal, and Compliance.
- Added structured labs with proof requirements and stop conditions for each application-grounded task.
- Replaced MCQ-only completion with five scenario decisions, a substantive written operator case note, and a seven-point evidence rubric.
- Corrected workflow training to show exact current behavior: all ten definitions are inactive and update triggering records rather than creating the Cases, Dunning Actions, notifications, tasks, or history previously implied.
- Corrected Subscription status teaching to the live values: Active, Suspended, Terminated, Port Out, and Port In Pending.
- Added explicit warnings for duplicate pages, editable calculated fields, SFID display behavior, thin UAT tables, Self SIM Swap, Corporate Portal, and stale Tariff Plan relationships.
- No workflow was enabled and no scheduled or cron automation was introduced.