Data & Screen Reference

Data & Screen Reference

A map of the screens you work in, the records eBOSS keeps behind them, and the state machines that govern every step. This is a plain-language reference for administrators and power users — not a database schema dump. Use it to understand what a status means, what each hub's tabs are for, and what the audit trail records.

Hubs & tabs

The whole staff surface is a handful of hub pages in the Business Licensing (eBOSS) sidebar group, each with tabs. You only see what your role permits.

Two public, sessionless destinations sit outside the staff group: the Owner Self-Service Portal (bplo/portal, customer login) and Permit Verification (bplo/verify, no login).

Key records (data, in plain terms)

eBOSS stores its data in bplo_* records (created by the module migrations into a per-module migrations_bplo tracker). You never touch these directly, but knowing what they hold helps with reporting and support. The main families:

Sensitive registry fields (e.g. identifiers) are masked by default and can only be revealed with bplo_sensitive_view — each reveal is written to the audit trail.

State lifecycles

Every moving part is a whitelisted state machine — a status can only change along a defined path, and the workflow validates each transition before it is written.

Application (New / Renewal / Amendment)

Detours: PRELIMINARY_ASSESSMENT ↔ DEFICIENCY for missing items, and PARALLEL_CLEARANCE_REVIEW ↔ INSPECTION_REQUIRED ↔ INSPECTION_COMPLETED for on-site checks. Any non-terminal state can move to a terminal outcome — WITHDRAWN, REJECTED_WITH_REASON, CANCELLED, EXPIRED, VOIDED, SUPERSEDED. Retirement follows its own chain (identity/authority review → cessation-date validation → treasury account review → clearance & settlement → field verification → approved → business retired → retirement certificate issued).

Clearance

NOT_REQUIRED → REQUIRED → READY_FOR_REVIEW → UNDER_REVIEW → either straight to APPROVED, or through inspection (INSPECTION_TO_SCHEDULE → INSPECTION_SCHEDULED → INSPECTION_IN_PROGRESS → FINDINGS_ISSUED → CORRECTIVE_ACTION_PENDING → REINSPECTION) to COMPLIANT/CONDITIONALLY_COMPLIANT → APPROVED. An approved clearance ends at ISSUED_OR_REFERENCE_VERIFIED (this is where an external reference like BFP Fire is verified). Dead ends: NONCOMPLIANT, REJECTED_WITH_REASON.

Inspection

REQUESTED → SCHEDULED → IN_PROGRESS → COMPLETED, with side paths NO_ACCESS (back to SCHEDULED) and CANCELLED.

Assessment & fee set

Assessment: DRAFT → FOR_APPROVAL → APPROVED (immutable). Superseding an approved assessment spawns a new DRAFT version. Fee rule set: DRAFT → ACTIVE → RETIRED (activation is four-eyes and auto-retires other active sets of the same code).

Payment reference

INITIATED → RECEIVED → RECONCILED (posts to Finance, settles the bill) → REVERSED (reverses the GL entry, reopens the bill).

Permit

From ISSUED/RELEASED a permit may be SUSPENDED (reinstatable), REVOKED (terminal), or SUPERSEDED (terminal, re-issued as a new version). A failed render lands on VOID (terminal) — the reserved number is never reused. Expired is a derived read-time state (past validity), never a stored one.

Audit-log events

Every state change and sensitive action writes to the tenant's system activity log under the eBOSS category, keyed action:component (for example issued:bplo_permit, approved:bplo_assessment, activated:bplo_fee_set, revealed:bplo_sensitive). Events span Registry, Parties, Applications, Deficiencies, SLA, Governance, Clearances, Inspections, Assessment, Payments, Issuance, Lifecycle, Compliance, Portal and Administration, each tagged with a severity (info / warning / critical). Critical events include record deletions, permit issue/suspend/revoke, assessment/fee-set approval & activation, payment reversal, sensitive reveals, and business retirement finalization.

Seeders & reference data

eBOSS separates functional reference data (installed by the migrations) from demo/sample data (loaded on demand):

Where the language strings live

All eBOSS user-facing text is in the module's own language file (module language, English), keyed with the bplo_ prefix, plus each menu item's tooltip (nav_desc_*). Text is never hard-coded in screens — which is what lets the whole module be re-labeled or localized without touching logic.