Openfront Dealership

Source · Live site · Catalog

Openfront Dealership is a self-hostable vehicle storefront and dealership operations app. Shoppers browse and compare vehicles and send sales, test-drive, trade-in, financing, and service requests. Staff work those requests through inventory, CRM, deal, finance, delivery, service, parts, payment, and accounting desks.

It is built with Next.js 16, React 19, Keystone 6 (GraphQL), PostgreSQL through Prisma, and Tailwind CSS. Start with Getting started.

Financing is intake and record keeping. Lender decisions, compliance checks, contract status, and accounting postings are entered by staff.

Code layout

Tenancy and access

• DealerGroup is the tenant root. A Rooftop is one store. Most operating lists carry a rooftop field and are filtered to the rooftops the user can reach.
• Access comes from the user's Role. Operating permissions can also come from an active DealerGroupMembership (optionally all rooftops) or RooftopMembership, for that scope only. Memberships change only through changeDealerMembership, which writes a MembershipAuditEvent.
• Some permissions are role-only: people, users, roles, settings, onboarding, API keys, and payments.
• Leads, deals, approvals, and trade-ins are limited to the assigned salesperson unless the user has canViewAllLeads across all rooftops. Dealer cost needs inventory or financing management across all rooftops.
• API keys (ApiKey) are owned by a user and limited to scopes: read_inventory, write_inventory, write_leads, write_deals, write_service, read_reports.
• Most operational lists are command-only. Their Keystone create and update are denied, so writes go through named mutations. Each command writes a DomainAuditEvent and a DomainOutboxEvent in the same transaction, keyed by an idempotency key.

Data model

A CRM Customer is separate from the login User. Public submissions find or create a Customer per rooftop by email or phone. A storefront account is linked to Customers only after it confirms its email with confirmCustomerEmailVerification.

Main workflows

Inventory. A unit enters through intakeInventoryVehicle (one step) or startInventoryAcquisition then transitionInventoryAcquisition (appraised, approved, purchased, arrived, reconditioning, frontline) and establishInventoryStock. Staff move stock, record costs, open and close recon work, edit listing content and photos, then submit and approve or reject merchandising. A vehicle shows on the storefront only when its current revision is approved, recon is complete, it is frontline, and its status is available. recordInventoryFeedRun records a feed run. Price changes append PriceHistory.

Leads. Public forms create a Lead and the matching record. Staff can open a lead (openLead), edit it (updateLeadDetails), route it by rule (routeLead) or by hand (transferLeadOwnership), log interactions, add and complete tasks, run cadences, schedule sales visits, and close it won or lost (transitionLead).

Deals. createDealPencil starts a deal at pencil, with tax and doc fee from the dealership profile. Staff save, present, and accept the worksheet (cash, finance, or lease), pick a lender offer for finance or lease, then move the deal through submitted, approved, financed, and delivered, or cancel it. Submitting reserves the vehicle. Delivery marks it sold.

Finance and F&I. Applications are queued with the operator-recorded adapter and decisions are entered with recordLenderDecision. The finance desk records product quotes, the F&I menu and customer choice, compliance checks (identity, OFAC, red-flag, privacy), the contract package, prerequisite review, funding, cash deposits (recordCashDealDeposit), and product cancellations.

Delivery. manageDeliveryCase schedules, records arrival and the checklist, takes the customer acknowledgment, or cancels. completeDealDelivery delivers the deal. manageWeOweItem tracks promises after the sale.

Service and parts. Appointments move through transitionServiceAppointment. openServiceOrder opens a repair order, which moves estimate, approved, in-progress, completed, invoiced, paid. Staff add, edit, and remove labor, part, and sublet lines, set tax, and run labor operations. Parts have a movement ledger and purchase orders. Receiving a purchase order posts receipt movements.

Payments and accounting. createPaymentCheckout creates a checkout for an approved deal or an invoiced repair order. Webhooks update transactions and refunds. stageAccountingBatch builds a balanced batch from mappings, and manageAccountingBatch records posting, failure, reconciliation, and lock.

Named GraphQL operations

Custom operations are declared in features/keystone/mutations/index.ts.

Lists that are not command-only (for example Make, Model, ServicePackage, Role, DealerGroup, Rooftop, DealershipProfile, PaymentProvider, ApiKey, VehicleConditionReport, VehicleHistory) also use Keystone's generated CRUD.

Integrations