User flows

This page draws the journeys that the PRD describes as user stories. Each diagram is followed by a numbered explanation that names the screens (RA-xx reseller app, RW-xx reseller web, DA-xx delegate app, BO-xx back-office), the API operations (op ids such as cart.checkout) and the requirements involved, each linked to its page. Statuses are the API values of enums.json; their transition tables are on lifecycles and statuses, which is authoritative when a diagram simplifies.

Four product decisions of 17 Oct 2026 shape most journeys: no order is confirmed automatically — every order waits for a person in the back-office (ORD-14); resellers see status changes live and as notifications (ORD-15); resellers, guests and delegates see availability only, never a stock quantity (STK-07); prices depend on the customer type declared at sign-up, and guests see none (PRC-02, AUTH-10).

Diagram conventions: rounded boxes are entry points, diamonds are decisions, dotted arrows are notifications or background effects; labels in French are UI labels.

At a glanceCopy Anchor Link

Who uses which interface, and how every interface reaches the single API (cahier §2).

1. Guests use the reseller app or web without an account; the guest operations — catalog.products.list, catalog.facets, banners.list, promotions.list, support.whatsapp — accept anonymous calls and never return a price (AUTH-10).
2. Resellers use the same two interfaces signed in; the same account, cart and orders are shared by app and web (RWA-02). Their own event stream events.stream keeps order, return and ticket screens live while open (ORD-15).
3. Delegates only use the delegate app, which works offline and replays its actions through sync.batch (SYN-04, SYN-05).
4. Back-office roles — commercial administration, stock, finance, delivery, direction, super administration — share one back-office whose menus and actions follow their permissions (ACL-02, ACL-05); the back-office stream admin.events.stream feeds the confirmation queue, the live field map and the alerts (SYN-07).

Reseller journeysCopy Anchor Link

From guest to account with a customer typeCopy Anchor Link

1. The app checks its version and the maintenance flag with appConfig.get on RA-01; below the minimum version every call answers 426 UPGRADE_REQUIRED and RA-36 forces the update (ADM-07, AUTH-09).
2. Without a session the visitor is a guest (RA-41, RW-01): home with banners and daily offers, catalog with the advanced filters, product pages and promotions — prices replaced by « Créez un compte pour voir les prix », availability shown as En stock / En rupture, no cart (AUTH-10, STK-07). The WhatsApp button resolves the support region from the device location when allowed (support.whatsapp, SUP-05).
3. Any priced action leads to RA-02. Sign-up starts with the phone on RA-03 (the invitation code is prefilled when the app was opened from an invitation) and the SMS code on RA-04 (auth.otp.send, auth.otp.verify, AUTH-03, AUTH-07).
4. A phone that already has a reseller user goes to sign-in; a phone that matches a field-created record claims it — no duplicate, the delegate keeps the attribution (AUTH-05, CRM-03).
5. RA-05 collects store details, password and the customer type; auth.signup.reseller creates the account PENDING_VALIDATION, the record ACCOUNT_CREATED and returns a session (AUTH-11, CRM-04).
6. Pending resellers see the prices of their declared type at once (default of D-18); checkout, assisted-order confirmation and payment declarations wait for validation (AUTH-08).
7. The account.pending event puts the account in BO-13, where the reviewer confirms or changes the customer type and approves (admin.resellers.validate) or rejects with a reason shown on RA-06 (CRM-09).
8. The reseller web runs the same flow on RW-01 (RWA-01).

Ordering: search, filters, cart rules and checkoutCopy Anchor Link

1. Search (RA-10, catalog.products.suggest), barcode (RA-11, catalog.products.byBarcode) and the catalog (RA-12) lead to the product page (RA-14, catalog.products.get) (CAT-07, CAT-10).
2. The filter sheet RA-13 (sidebar on RW-03) combines category and sub-category, brand, price range, the category's attributes, availability, promotion and new arrivals; every value carries its count from catalog.facets (CAT-12, CAT-13).
3. Prices are those of the reseller's customer type, promotions on top; availability is En stock or En rupture only, and an En rupture variant cannot be added (PRC-02, STK-07).
4. cart.items.add enforces minimum, step and maximum per order; cart.get re-prices and re-checks at every view and returns blocking issues (ORD-01, ORD-02, PRC-05).
5. ORDER_MIN_AMOUNT_NOT_MET shows the missing amount; STOCK_INSUFFICIENT says the quantity cannot be served without revealing what is left; products that became invisible must be removed (ORD-02, STK-07, CAT-05).
6. RA-18 uses cart.checkoutOptions for addresses (RA-19), enabled payment methods, delivery fee and available credit; over-limit credit orders are blocked by default (D-04) (FIN-02, FIN-05, DLV-06).
7. cart.checkout requires an Idempotency-Key: a retry with the same key replays the same order; a change found at submission returns to the cart instead of creating the order (ORD-03).
8. The order is SUBMITTED — never confirmed automatically — and enters BO-41 live; RA-20 says HOCO will confirm it (ORD-14, SYN-07). The full sequence is in checkout.

Live tracking, cancellation and assisted-order confirmationCopy Anchor Link

1. While order screens are open, the app and the web keep events.stream; order.status_changed and order.modified update RA-21 counters and the RA-22 timeline at once, and a lost connection resumes with Last-Event-ID (ORD-15, SYN-07).
2. Every change is also a notification — push and inbox RA-26 — whether the app is open or not (NOT-01, NOT-02, NOT-05).
3. orders.get returns the allowed actions: orders.cancel while SUBMITTED or PENDING with a reason, which releases any reservation automatically (ORD-10, STK-03); documents via orders.document (ORD-12); orders.reorder (ORD-07).
4. On a DELIVERED order the reseller can open an after-sales claim or a return (SUP-04, ORD-13).
5. Assisted orders arrive on RA-23 (web RW-09): orders.confirmAssisted makes them SUBMITTED — still waiting for the back-office confirmation —, orders.rejectAssisted cancels them with a reason, and after 72 h without answer they expire (D-23) (ORD-08, ORD-14).

Payment declarationCopy Anchor Link

1. RA-29 and RA-30 read finance.summary and invoices.list; credit notes from returns and after-sales appear against the invoices they reduce (FIN-10, FIN-08).
2. RA-31 declares a transfer, CCP or BaridiMob payment with a private proof uploaded through files.createUpload and files.completeUpload (FIN-03, SEC-04); proof, amount, date and reference are mandatory by default (D-26).
3. payments.declare creates a PENDING_VERIFICATION payment; nothing changes in the balance until finance confirms on BO-45 with admin.payments.verify and allocates with admin.payments.allocate (FIN-03, FIN-04).
4. A rejection carries a reason from PAYMENT_REJECT_REASON; both outcomes are notified (NOT-05).

After-sales claim (SAV)Copy Anchor Link

1. A claim starts from a delivered order or from RA-32; RA-33 (web RW-14) asks for the lines and quantities, the issue (AfterSalesIssue), a description and at least one photo (SUP-04).
2. tickets.create with type AFTER_SALES checks that the order is DELIVERED, that the claim is within the after-sales window (D-35) and that quantities are not already claimed or returned (SUP-04).
3. The claim is flagged SAV in BO-55 and listed on BO-69; BO-56 shows the order, the claimed lines, the photos and the reseller's claim history; agents can ask for more information, which reaches the reseller live and by push (admin.tickets.reply, SUP-02, ORD-15).
4. admin.tickets.resolve (permission support.validate) applies one resolution: a free replacement order that enters BO-41 like any order, a return already approved, a credit note, a repair, or a rejection with a reason (SUP-04, ORD-13, FIN-08, ORD-14).
5. The reseller sees the resolution and its effect, may contest a rejection once, and closes the ticket with a rating (tickets.close) or it auto-closes (SUP-01).

Return with automatic restockCopy Anchor Link

1. From a DELIVERED order, RA-40 (web RW-14) sends returns.create with lines, quantities (at most delivered minus already returned or claimed), a reason and photos, inside the return window — 7 days by default (D-35) (ORD-13).
2. Returns also start from an after-sales resolution RETURN (already APPROVED) and from a refusal at the door (already IN_TRANSIT) (SUP-04, DLV-03).
3. The commercial administration decides on BO-69 with admin.returns.decide: acceptance sends instructions (bring to the depot or a collection date); refusal needs a reason (ORD-13).
4. The stock team records the reception with admin.returns.receive (received and accepted quantities per line, a reason for each refused unit); accepted quantities re-enter stock automatically as RETURN movements, defective and damaged units are not re-entered (STK-03, STK-04).
5. In the same operation a credit note is issued for the accepted invoiced lines and the return becomes REFUNDED; the reseller follows every step live and by notification (FIN-08, ORD-15, returns.get).

Support and regional WhatsAppCopy Anchor Link

1. The WhatsApp button is fixed on the reseller app and web screens, for guests and signed-in resellers (SUP-05).
2. support.whatsapp returns the number, the wa.me link and the hours of the support region: the region of the declared wilaya when signed in, of the device location for a guest who allows it, otherwise a wilaya picker and the default number (SUP-05, ADM-08). Regions are managed on BO-70; one national region applies until HOCO defines more (D-36).
3. Written requests go through RA-32 and RA-33 (tickets.create); agents answer from BO-55 and BO-56 (admin.tickets.reply, admin.tickets.update); the reseller answers on RA-34 (tickets.reply) and every reply arrives live and by push (SUP-01, SUP-02, ORD-15).

Delegate journeysCopy Anchor Link

A day in the field, from sign-in to closingCopy Anchor Link

1. DA-01 checks the version (appConfig.get); DA-02 signs in with phone and password and refuses suspended accounts explicitly (AUTH-02, AUTH-08).
2. On first launch DA-04 explains the location policy — sampling only during a tour in progress, every 5 min or 200 m, kept 90 days — and records consent (SEC-07, FLD-15, D-07).
3. sync.delta loads the day's snapshot (tour, visits, resellers in scope, tasks, reference lists) into the local database; without network the last snapshot is used and the offline banner shows (SYN-04, delegate.tours.today).
4. DA-05 shows the day (delegate.home, FLD-05). « Commencer la tournée » appears only for the delegate's own TO_START tour; delegate.tours.start works offline through the outbox, and the back-office receives tour.started once synced (FLD-04, SYN-05).
5. DA-06 runs the visit loop; a break uses delegate.tours.suspend and delegate.tours.resume, and stops sampling meanwhile (FLD-04, FLD-15).
6. delegate.tours.closingPreview on DA-20 lists stops without an outcome (fixed on DA-11, delegate.visits.notDone) and unsynced items (DA-27); delegate.tours.close then sets COMPLETED and returns the final report (FLD-09, FLD-12, SYN-06).

A visit at a point of saleCopy Anchor Link

1. DA-08 shows the next destination with ETA and distance and opens the phone's navigation app (FLD-07, INT-01).
2. « Arrivé » sends delegate.visits.arrive with position, accuracy and occurredAt; within 150 m and with accuracy ≤ 100 m the visit opens, otherwise DA-28 shows the distance and the visit stays closed (blocking by default, D-06) (FLD-07, GEO-03). Details in check-in.
3. DA-10 runs the visit: timer (delegate.visits.start), checklist of the visit type (delegate.visits.checklist, FLD-16), note of up to 300 characters (delegate.visits.note), photos (delegate.visits.addPhoto), call (FLD-08).
4. Opportunities lead to DA-14, DA-16 or DA-17 — see the conversion funnel.
5. DA-12 saves the structured report (delegate.visits.report); a next action with a date creates the follow-up on DA-19 (FLD-10, CRM-08).
6. delegate.visits.end refuses to finish while required photos or report are missing; a finished visit is locked until a back-office unlock (admin.visits.unlock, FLD-08). Everything in this loop works offline.

Prospect → invitation → install → account → first orderCopy Anchor Link

1. DA-14 runs delegate.resellers.checkPhone then delegate.resellers.create (offline-safe, client UUIDv7); the record carries the delegate, the position and a proposed customer type (FLD-11, CRM-03, AUTH-11).
2. DA-16 gets the active invitation from delegate.invitations.create and records the share channel with delegate.invitations.markShared (SENT) (IVT-01, IVT-02).
3. The link opens the app through Android app links when installed, otherwise the landing invitations.landing sends the visitor to the Play Store with the code in the referrer; the first open reports it with invitations.attribute (APP_INSTALLED) (IVT-04). Details in invitation attribution.
4. Sign-up claims the delegate's record and records ACCOUNT_CREATED and PHONE_VERIFIED; the first catalog read of the new account records CATALOG_VIEWED (AUTH-05, IVT-03).
5. The first order — placed by the reseller or prepared by the delegate on DA-17 and confirmed — is flagged first and attributed to the delegate (FIRST_ORDER); like every order it waits for the back-office confirmation; the reseller becomes ACTIVE when an order is delivered (ORD-09, ORD-14, CRM-04).
6. The delegate sees the steps tick on DA-16 (delegate.invitations.get); the back-office follows the funnel per delegate with admin.invitations.list (ANA-04).

Back-office journeysCopy Anchor Link

Account validation with customer-type reviewCopy Anchor Link

1. Pending sign-ups arrive live through account.pending; field-created points of sale wait in the same queue BO-13 (admin.resellers.validation.list, CRM-09, FLD-14).
2. Duplicate hints come with each entry; real duplicates are rejected and pointed to the existing record — the merge tool is V2 (CRM-03, CRM-13).
3. The reviewer confirms or changes the declared customer type (a change needs a reason and is audited) before approving with admin.resellers.validate (AUTH-11, AUD-01); who validates is D-30.
4. Approval activates the account and notifies the reseller and the creating delegate; a rejection is shown with its reason on RA-06 (NOT-05).

Tour planningCopy Anchor Link

1. BO-21 plans tours per delegate and date, or a recurring series, with admin.tours.create (FLD-03).
2. BO-22 adds stops from the delegate's zone with time slots and priorities; the recommended mode computes a nearest-neighbour order with admin.tours.recommendOrder (FLD-17); admin.tours.setStops saves them (FLD-06).
3. A planned tour reaches the delegate at the next sync.delta; it can be edited until it starts (admin.tours.update) or cancelled with a reason (admin.tours.cancel, FLD-04).
4. The daily job sets TO_START; the delegate starts and closes it; BO-23 and BO-06 follow it live (admin.tours.get, admin.live.delegates, FLD-13); reopening a closed tour needs the validate permission (admin.tours.reopen, FLD-12).

Order confirmation queue: controls, hold, overrideCopy Anchor Link

1. Every channel lands in SUBMITTED — reseller app and web (cart.checkout), assisted orders once confirmed (orders.confirmAssisted, admin.orders.confirmAssisted), phone orders (BO-40, admin.orders.create, ORD-11) and after-sales replacements (admin.tickets.resolve). None is confirmed automatically (ORD-14).
2. BO-41 lists SUBMITTED and PENDING orders oldest first with their control results (admin.orders.toConfirm); new orders arrive live through order.to_confirm (SYN-07).
3. BO-39 shows the stock, price, credit and address controls (admin.orders.get, ORD-05). When everything passes, Valider is one click (admin.orders.validate).
4. When stock is short, the confirmer reduces the quantity with a reason (admin.orders.modify, ORD-06) or overrides with the stock-validate permission; credit over the limit needs a finance override; every override is logged as OVERRIDE (STK-08, FIN-05, AUD-01).
5. Mettre en attente holds the order in PENDING with a reason; Refuser ends it REFUSED with a reason from ORDER_REFUSAL_REASON (admin.orders.refuse).
6. Confirmation reserves stock and creates the delivery record TO_PREPARE (D-22); the reseller sees the change live and by push (ORD-15). See the confirmation sequence.

Stock: receipts, alerts, inventories and returnsCopy Anchor Link

1. Alerts arrive as stock.alert events on BO-07; BO-33 shows physical, reserved and available quantities per warehouse — quantities that only the back-office ever sees (admin.stock.levels, STK-02, STK-05, STK-07).
2. Receipts (admin.stock.receipt) and adjustments with a reason (admin.stock.adjust, BO-35) post movements to the journal BO-34 (admin.stock.movements, STK-04, STK-06); a variant back above 0 returns its product from OUT_OF_STOCK to ACTIVE (CAT-04).
3. Inventory sessions on BO-36 (admin.inventory.crud) are validated with admin.inventory.validate, which posts INVENTORY movements for the differences only (STK-06).
4. Restock is automatic: cancellations release reservations, and return receptions on BO-69 (admin.returns.receive) post RETURN movements for accepted units, without any manual adjustment (STK-03, ORD-13).

DeliveryCopy Anchor Link

1. A confirmed order appears on BO-42 as TO_PREPARE (admin.deliveries.list, DLV-01); the picking list is printed with admin.deliveries.pickingList.
2. Preparation and readiness move the order through admin.orders.transition; each status reaches the reseller live (ORD-04, ORD-15).
3. admin.deliveries.update records the mode (Livreur HOCO, Société de livraison, Retrait au dépôt), the carrier and the tracking number (DLV-02, DLV-04); SHIPPED deducts stock and the delivery note is available (STK-03, ORD-12).
4. admin.deliveries.proof stores the photo and the recipient and marks the order DELIVERED (DLV-03); the first delivered order makes the reseller ACTIVE (CRM-04).
5. A refusal at the door turns the order RETURNED and creates a return already in transit, whose reception restocks and credits automatically (ORD-13).

FinanceCopy Anchor Link

1. Declarations from RA-31 and RW-13 are verified on BO-45 (admin.payments.list, admin.payments.verify); cash and other payments are recorded with their allocation (admin.payments.record, admin.payments.allocate) (FIN-03, FIN-04).
2. Credit notes from return receptions and after-sales resolutions reduce the invoice they relate to (FIN-08).
3. A daily job sets OVERDUE (FIN-01); reminders are V2 (FIN-07).
4. BO-46 sets limits and blocks (admin.credit.update), applied at the next checkout (FIN-05); BO-08 summarises expected payments, credit used and unpaid amounts (ANA-01).

DirectionCopy Anchor Link

1. Direction signs in on BO-01 and lands on BO-04 with the cards of cahier §4.1, filtered by date, wilaya, commune, delegate, brand and category (admin.dashboard.kpis, ANA-01, ANA-02).
2. The sales, field and finance dashboards (BO-05, BO-06, BO-08) and the reports library BO-59 (admin.reports.run) give the essential reports and the success indicators with the PRD's formulas (ANA-03, ANA-04).
3. Exports run in the background (admin.exports.create) and are downloaded from BO-60; every export is in the activity journal (ANA-05, AUD-01).

Sequence diagramsCopy Anchor Link

CheckoutCopy Anchor Link

1. « Valider la commande » on RA-18 or RW-07 sends cart.checkout with a required Idempotency-Key; a retry with the same key and body replays the original response, a different body with the same key is refused with 409 IDEMPOTENCY_KEY_REUSED (ORD-03).
2. The server re-prices with the customer-type price and promotions, re-checks availability without exposing quantities, checks credit for credit orders and the cart rules (PRC-02, PRC-05, STK-07, FIN-05, ORD-02).
3. Any failure returns a stable 422 code with the issues and creates nothing; success writes the order SUBMITTED, its number, lines, history and outbox events in one transaction (ADM-04, ORD-06).
4. The worker dispatches order.created and order.to_confirm to the back-office stream — the order is now in BO-41 waiting for a person — and notifies the reseller (ORD-14, SYN-07, NOT-05). Nothing confirms the order automatically.

Back-office confirmation and live status to the resellerCopy Anchor Link

1. The confirmer works from BO-41 (admin.orders.toConfirm) and BO-39 (admin.orders.get); admin.orders.validate requires the orders.validate permission (ORD-14, ORD-05).
2. Confirmation reserves stock, creates the delivery record and writes the outbox event in the same transaction (STK-03, DLV-01).
3. The worker updates the back-office queue and publishes order.status_changed on the reseller's own stream events.stream, filtered to that reseller only; an open RA-21, RA-22, RW-08 or RW-09 updates in place (ORD-15, SYN-07).
4. The push and the inbox entry are sent in every case — the stream is a convenience while the app is open, the notification is the guaranteed channel (NOT-02, NOT-05).
5. Reconnection uses Last-Event-ID, and a foreground refresh with orders.get guarantees the status shown equals the back-office status (ORD-07). The same mechanism carries hold, refusal, modification, preparation, shipment, delivery, returns and ticket replies.

Assisted orderCopy Anchor Link

1. delegate.assisted.create and delegate.assisted.update build a draft priced at the reseller's customer type with availability only; assisted orders need a connection (ORD-08, PRC-02, STK-07).
2. delegate.assisted.submit runs the same controls as a checkout, flags the first order for the delegate and asks the reseller for confirmation on RA-23 (ORD-02, ORD-09).
3. The reseller confirms (orders.confirmAssisted) or refuses with a reason (orders.rejectAssisted); the administration may confirm for a reseller who agreed by phone (admin.orders.confirmAssisted, BO-41); after 72 h the confirmation expires (D-23).
4. A confirmed assisted order is SUBMITTED and still waits for the back-office confirmation like every order (ORD-14); the delegate follows it on DA-18 (delegate.orders.list).

Visit check-in with GPS toleranceCopy Anchor Link

1. « Arrivé » captures a fresh position; an accuracy worse than 100 m asks for a new measurement (GEO-03, FLD-07).
2. Online, delegate.visits.arrive computes the distance on the server; within 150 m the visit becomes CHECKED_IN and DA-10 opens with Position confirmée; outside, DA-28 shows the distance and the visit stays closed — blocking by default (D-06) (FLD-08).
3. Offline, the app applies the same rule against the cached shop position and queues the mutation; the server evaluates it again on replay and flags a disagreement (SYN-04, SYN-05).
4. The back-office receives visit.checked_in on BO-06 and BO-23 (FLD-13, SYN-07).

Offline replay through /sync/batchCopy Anchor Link

1. Offline actions are written to the local outbox with a client UUIDv7, an Idempotency-Key and occurredAt; implausible times (more than 5 min ahead, older than 72 h) are rejected with OCCURRED_AT_OUT_OF_RANGE (SYN-04, SYN-05).
2. sync.batch replays up to 50 items in order with one result per item; a lost response is harmless: the resent items come back REPLAYED with their original results (SYN-05).
3. An item whose target changed on the server returns CONFLICT and is shown in DA-27, never retried silently; REJECTED items are not retried, RETRY items are retried with backoff (SYN-06).
4. sync.delta then pulls the server's changes so the local state matches (SYN-01). The full design is in the offline sync design.

Invitation attribution with the Play install referrerCopy Anchor Link

1. delegate.invitations.create returns the active code (AB12-CD34), the link https://app.hoco.dz/i/AB12CD34 and the QR payload; delegate.invitations.markShared records the channel (IVT-01, IVT-02).
2. Installed apps open the link directly through verified Android app links; otherwise invitations.landing redirects to the Play Store with the code in the referrer, which the app reads on first open (IVT-04). On a computer or an iPhone the landing opens the web sign-up instead (RW-01).
3. invitations.attribute records APP_INSTALLED for the inviting delegate; invitations.resolve shows the store name and the delegate's first name on the sign-up screen (IVT-03).
4. auth.signup.reseller with the code claims the delegate's record with the declared customer type; a reseller who installed without the link is still attributed through the typed code or the phone match (AUTH-05, AUTH-11).

Cross-journey lifecycle of a resellerCopy Anchor Link

One record follows a point of sale through every journey above. ResellerStatus is its commercial lifecycle; it is distinct from the account status (PENDING_VALIDATION, ACTIVE, SUSPENDED, DISABLED) and from the validation status.

1. Records start as NEW_PROSPECT (delegate app, back-office, import — the customer type is captured on every path) or directly as ACCOUNT_CREATED when a shop signs up by itself (CRM-02, AUTH-11).
2. Qualification statuses (TO_CONTACT, INTERESTED, NOT_INTERESTED, TO_FOLLOW_UP) are set by delegates and the back-office with reasons, plus two system rules: planning a visit or call sets TO_CONTACT, inactivity sets TO_FOLLOW_UP (CRM-04, delegate.resellers.update, admin.resellers.setStatus).
3. The funnel statuses are automatic only and move forward from any qualification status: install attributed → APP_INSTALLED (invitations.attribute), record claimed → ACCOUNT_CREATED (auth.signup.reseller), first order submitted → FIRST_ORDER, an order delivered → ACTIVE (admin.deliveries.proof) (IVT-03, ORD-09).
4. Two automatic moves go backwards: a first order that ends refused or cancelled reverts FIRST_ORDER, and the daily inactivity scan moves ACTIVE or ACCOUNT_CREATED to TO_FOLLOW_UP after 60 days without a confirmed order (setting) with a follow-up task for the delegate; the next confirmed order restores ACTIVE (CRM-08).
5. SUSPENDED (unpaid, fraud, closure) is a back-office decision from any status: checkout, assisted orders and return requests are refused, sign-in and reading still work; lifting it restores the previous status (CRM-04). The full transition tables are on lifecycles and statuses.

What is not a flow and where it livesCopy Anchor Link

Configuration and administration screens support the journeys without being journeys themselves.