Onboarding path
This is the reading order that takes a new engineer from nothing to shipping tickets and handling support on Orascom Portals. Each step links the pages you actually need — you don’t have to read everything, in order, to be useful.
Day 1 — build the mental model
Section titled “Day 1 — build the mental model”-
The shape of the system. Read Architecture — one Laravel API, four React apps, a CRM middleware to three Dynamics 365 orgs, a PDF service, payments. Then Personas — the five user types and how each authenticates.
-
The three cross-cutting models everything else is a special case of: CRM integration model (write → Logic App, read → OData, one Azure app), the Auth model (Sanctum for users, Passport for services), and the Data model (inventory is a published local mirror; the CRM owns the truth; where the PII is).
-
Know where things run. Skim Environments — there are two, UAT and production,
uatis the branch you open pull requests against, and all four apps share one hostname per environment. It is short, and getting it wrong wastes a day. -
Get it running. Follow Run the stack locally — the five repos, the ports, wiring the middleware to
crm-mock. Expect the honest caveats (no one-command boot; payments and Azure SSO don’t run locally).
By end of Day 1 you should be able to say, out loud, what happens when a broker submits a lead — and have a
backend responding on :8080.
Week 1 — learn the flows, ship a change
Section titled “Week 1 — learn the flows, ship a change”-
The reference flow. Read Broker submits a lead end-to-end. It’s the template every write-flow follows (React SPA → Laravel → CRM middleware → Dynamics). Understand this one and the rest are variations.
-
The other journeys, as you need them: Shopper buys a unit (the state machine), Sales-Man closes a sale, the online payment pipeline, Submitting an EOI, Generating a sales-offer PDF, and Oman broker pre-registration.
-
Ship your first change. Do the Ship your first change tutorial — a real edit to the lead flow, through to a pull request. Then read Add a field to the lead form to see the same change traced across frontend + backend + middleware.
Your first ticket
Section titled “Your first ticket”-
Find the flow it touches. A ticket almost always maps to one of the eight flows. Start there — the flow page tells you the controllers, actions, routes, and the “one thing that surprises everyone.”
-
Find the exact endpoint. API reference, by persona maps all ~372 endpoints by persona and resource, with the auth tier and the public/
signed/country-gated exceptions. -
Follow the recipe. For a common change there’s a how-to: Add a new CRM operation, Add a payment gateway, or add-a-field. Each has a “files you touch” checklist and the foot-guns to avoid.
-
Check what’s already known. Before you “fix” something odd, check the KT tracker — many quirks (the
crm_statustyping, the MontenegroRESERVED=7gap, the disabled Paymob HMAC, the Sentry token in the browser bundle) are already documented defects, not your bug to re-discover. -
Know the state machines. State machines shows every status enum and its transitions — invaluable when a ticket is about “why is this sale stuck in
pending_info”.
Doing support
Section titled “Doing support”The flow pages double as runbooks — each has a “Support” section keyed to real symptoms. For the two most common incidents there are dedicated runbooks:
- Lead isn’t reaching the CRM — triage by status code and log line, find the layer at fault, know who owns the fix.
- Paid but not reserved — the
status = success+status_after_success_transaction = 0case, matched bypayment_reference_id.
The one reflex to build: the CRM owns the truth. Most “the data is wrong” reports are a read/sync issue or a known mapping gap, not a lost write — the KT tracker and the data model tell you which.