Skip to content
Orascom DevelopmentOrascom Portals

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”

  1. 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.

  2. 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).

  3. 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”

  1. 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.

  2. 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.

  3. Ship your first change. Do the Ship your first change tutorial — a real edit to the lead flow, through to an MR. 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”

  1. 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.”

  2. 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.

  3. 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.

  4. Check what’s already known. Before you “fix” something odd, check the KT tracker — many quirks (the crm_status typing, the Montenegro RESERVED=7 gap, the disabled Paymob HMAC, the browser-bundle secrets) are already documented defects, not your bug to re-discover.

  5. 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:

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.

The whole map

Section titled “The whole map”
UnderstandArchitecture · CRM model · Data model · Auth model · Personas — how the system works.
FlowsEight end-to-end journeys, each also a support runbook.
How-toRecipes: add a field, a CRM operation, a payment gateway.
ReferenceLook it up: APIs by persona, state machines, env vars, the lead API.
OperationsRunbooks + the KT tracker of known issues and hardening items.
GlossaryThe vocabulary — Deal vs lead, Sanctum vs Passport, Logic App, source_id, Taskeen…