Sales object model

The Sales app is built on six objects. Each is a real object in the kernel sense — a physical table with typed columns, the standard system fields, and FLS — and each maps to a Salesforce analogue. Its page layouts, list views, and tabs are surfaces delivered by installable packages over those objects; the object/field/FLS engine underneath stays kernel. The sections below give each object’s Salesforce-aligned fields and the fields it carries beyond Salesforce.

Every object inherits the universal standard fields — id, owner_id, created_by_id, last_modified_by_id, created_at, updated_at, the audit stream, and the recency fields. The per-object fields below are in addition to that set.

The shape of the model

Account ──< Contact
   │
   └──< Opportunity
           └──< Proposal (a priced version)  ──▶ Order (on acceptance)  ──< Amendment

An Account is the customer company; Contacts are people at it; an Opportunity is the pursuit; a Proposal is a priced version of that pursuit; accepting a Proposal snapshots it into an Order; changes after the award are first-class Amendments. The lineage from pursuit → priced version → award → amendment is the spine of the app.

Account — customer company

Salesforce analogue: Account.

The customer company. Beyond the universal fields, the Account carries the firmographics a sales team files on: billing and shipping addresses, corporate hierarchy, and account source.

Salesforce-aligned fields: AccountNumber, ParentId (corporate hierarchy), Type, Website, BillingAddress + ShippingAddress (Salesforce models each as one compound field; here they are component fields until a composed address type exists — see Values with several parts), AnnualRevenue, NumberOfEmployees, AccountSource, Fax, Ownership, Rating, Sic / SicDesc.

Beyond Salesforce: a Procurement Channels multi-select — the purchasing portals and marketplaces a customer buys through — which a generic CRM has no field for.

Contact — person at an account

Salesforce analogue: Contact.

A person at an Account, with the name and reachability fields a contact record carries.

Salesforce-aligned fields: Salutation, Department, a distinct MobilePhone (split from the main Phone), ReportsTo (contact hierarchy), Fax, LeadSource, OtherPhone.

Beyond Salesforce: a Role picklist scoped to how the business classifies buyer-side people (purchasing vs. technical evaluation vs. project management), alongside the standard title fields.

Opportunity — the pursuit

Salesforce analogue: Opportunity.

An Opportunity is the pursuit: something a customer may buy and, if won, receive. It has a stage, an owner, an expected value, and a close.

Salesforce-aligned fields: a CloseDate kept separate from the customer’s due-date, Probability, ForecastCategory / ForecastCategoryName, Type, LeadSource, NextStep, the derived IsClosed / IsWon / ExpectedRevenue, LastStageChangeDate, and a primary-contact lookup — the forecasting and stage-hygiene fields on any opportunity.

Beyond Salesforce: an Outside Salesperson lookup (inside + outside rep both first-class), a Product Line that selects the record type, a Delivery Location, a human Opportunity Number, and a roll-up of the Proposals priced against the pursuit.

Proposal — a priced version

Salesforce analogue: Quote (+ QuoteLineItem).

A Proposal is a priced version of an Opportunity, with its lines, its totals, and the terms it was offered on.

Salesforce-aligned fields: a concrete ExpirationDate date (not a validity-in-days number), explicit Tax and ShippingHandling where applicable, a derived LineItemCount, a proposal-level ship-to address, a recipient-contact email/phone snapshot, and SortOrder / LineNumber on the line sub-objects.

Deliberately different from Salesforce: IsSyncing — Salesforce’s flag that syncs one priced version back to the opportunity has no analogue; an explicit revision lineage plus an accepted-proposal → Order snapshot records which version governs.

Beyond Salesforce: a guarded lifecycle state machine and a role-flipping owner (the record’s owner moves between the person pricing it and the salesperson as it advances).

Order — the accepted, snapshotted proposal

Salesforce analogue: Order (+ OrderItem).

Accepting a Proposal produces an Order: an immutable snapshot of what was sold, at what cost and margin, at the moment of award — the object fulfilment and finance work from.

Salesforce-aligned fields: a direct AccountId, an EndDate (target completion), a Name, an order-level ship-to address, ActivatedById / ActivatedDate, StatusCode, authorized-by sign-off pairs, and Type.

Beyond Salesforce: an immutable Baseline (Cost / Sell / Margin captured at award) and a TotalAmount that rolls up approved Amendments, so the order shows the current contract value without losing the original baseline.

Amendment — a change after the award

Salesforce analogue: none native — the closest is an Order amendment or a Contract, neither of which carries a margin-recapture approval.

An Amendment captures a scope change after the award and routes it through a margin-recapture approval. It is a first-class object with no Salesforce equivalent.

Fields: the single Salesforce “Approver / Approval Date” idea is split into customer-signed and internally-approved pairs, with an effective date and a schedule-impact date.

Beyond Salesforce: the object itself — a first-class post-award change with its own approval and a roll-up into the parent Order’s contract value.

Record types — structural variation by product line

Product lines can be structurally different: different required fields, different picklist values, different page layouts. Record types drive that variation — per-type page layouts, picklist filtering, and required-rule sets — so a services proposal does not present a hardware-only field as required while a hardware proposal does. The per-type layouts are package-delivered surfaces; the record-type, picklist-filtering, and required-rule model that keys them is kernel. Record types sit under the field model and the FLS / required-rule model that governs every proposal surface. See Field model for record-type mechanics.

Where the Sales model goes beyond Salesforce

Guarded Proposal lifecycle · role-flipping owner · the Order baseline snapshot with Amendment roll-up · Amendment as a first-class post-award object · and the firmographics (Procurement Channels, Product Line, Delivery Location, inside and outside salesperson) a generic CRM has no home for.