The data model is the product.Standard objects where Salesforce has them. Native records everywhere else.
Every claim on this site — native reports, admin skills that transfer, Agentforce that works on day one, migrations in weeks — comes back to one decision: Kugamon stores revenue data as Salesforce records in your org, on Salesforce's own catalog and pricing objects. This page shows exactly which objects, and what that buys you.
Kugamon is a managed package. It uses Salesforce's standard Product, Price Book, Price Book Entry, Account, Contact, Opportunity, Contract and Asset objects for everything Salesforce already models, and installs its own objects — Quote, Order, Shipment, Invoice, Payment, Subscription — for everything it does not. All of it is data in your org. There is no external database, no middleware and no sync.
The standard Product and Price Book
The catalog is Salesforce's. A Kugamon quote line points at a Product2 and takes its list price from a PricebookEntry, exactly as an Opportunity Product does. Tiered pricing, account-specific pricing, discount schedules, kits and bundles, configuration groups and options, tax flags, and the switches that decide whether a product ships, creates an Asset or a Subscription, renews or uplifts, live on a Kugamon Additional Product Info record attached to the product. Admins who know how to maintain a Price Book already know how to maintain the Kugamon catalog, and a Price Book change is a Price Book change — not a re-import into a second pricing model.
That is also where the benchmark comes from. A 100K-product catalog loads into the Lightning configurator in 3 seconds because the configurator is reading the standard objects with a Lightning UI built for them, not a copy of the catalog somewhere else.
Native objects, not synced copies
| Kugamon record | What it is in Salesforce | Notes |
|---|---|---|
| Product, Price Book, Price Book Entry | Standard objects | Kugamon adds Additional Product Info (kits, configuration, ship/asset/subscription/renewal/revenue flags, tax) |
| Account, Contact | Standard objects | One Additional Account Info record per Account holds billing defaults: contacts, invoice schedule, payment terms, tax location, price book, renewal uplift |
| Opportunity | Standard object | Primary Quote and Primary Order lookups; amount and lines sync back; New, Expansion and Renewal record types with Subscription Management |
| Asset | Standard object | Created on Order approval, per line or per quantity; linked to the Order, Shipment and Contract |
| Contract | Standard object | The container for subscriptions, assets, contributing orders and the renewal opportunity; ARR, MRR and TCV roll-ups |
| Quote, Quote lines | Kugamon object (kugo2p) | Disposable what-if; PDF, online acceptance, statuses; converts to an Order |
| Order, Order lines | Kugamon object (kugo2p) | The record of the sale; Release fires every downstream record |
| Shipment | Kugamon object (kugo2p) | Created on Release for tangible products; packing slips, carrier, tracking |
| Invoice, Invoice lines | Kugamon object (kugo2p) | Created on Release on the account's schedule; Age, Balance Due, Posted |
| Payment, Payment Method, Recurring Charge | Kugamon objects (kugo2p) | Processor connections to Stripe, Authorize.Net, PayPal, eWay; statuses set by the processor |
| Tax Location, Tax Rate, Carrier, Warehouse | Kugamon objects (kugo2p) | Set up once in Kugamon Settings |
| Subscription | Kugamon object (kuga_sub) | Created from service lines on Release; IsActive computed by a scheduled job |
| Revenue | Revenue Management add-on | Monthly records from Orders or Invoices |
| Inventory, Inventory Adjustment | Inventory add-on | Tied to Warehouses, Orders and Shipments |
The pattern is deliberate. Where Salesforce has an object that fits — Asset, Contract, Product — Kugamon uses it, so the rest of your org (Service Cloud, Field Service, your own automations) sees the same Asset a support agent sees. Where the standard object does not model the job Kugamon needs it to — release, shipments, scheduled invoicing, subscription lines — Kugamon installs its own, in your org, as custom objects with your permissions on them.
Native reporting, security and automation
Because every record above is a Salesforce record, three things are true on the day you install:
- Reports and dashboards work on quote, order, invoice, payment and subscription data with the standard report builder, and roll-up fields give you pipeline, balances and ARR without an export.
- Security is Salesforce security. Object permissions, field-level security and sharing rules apply to every transaction record. Kugamon does not hold a copy of your data anywhere it could be governed differently. See Security.
- Automation is Flow. Approvals, past-due tasks, credit holds, renewal reminders and custom notifications are Flows and email templates on these fields. No Apex is required for standard use; when you do want a trigger, it is ordinary Salesforce development against ordinary objects.
No middleware, no sync, nothing to debug
A CPQ or billing tool that runs outside Salesforce keeps its own database and pushes summaries into the CRM. That works until it does not: a sync fails overnight, a field mapping drifts, a rep sees an amount that finance does not. The integration becomes a permanent line item, and every new tool — including every AI agent — has to be wired to it separately.
Kugamon removes the category. The only outbound connections are gateway callouts for payments and the emails your org already sends. Everything else is a database write inside your org. That is why Agentforce reads a Kugamon Quote the way it reads an Opportunity, and why the Claude and Cirra AI walkthroughs on the AI & Agentforce page need no connector beyond Salesforce's own APIs.
Why the data model is the product
Features can be added to any architecture. What cannot be retrofitted is where the data lives. Salesforce CPQ (SBQQ) used its own quote objects on the standard catalog; Revenue Cloud Advanced introduces a new catalog and transaction model; Conga uses its own Price List objects; DealHub keeps quote data outside Salesforce. Each is a defensible design — and each decides, for years, what your reports can see, what your admin can change, what a migration has to move and what an agent can act on. The native CPQ test puts five questions to every option; the object mapper shows where each product's objects land if you move.
Kugamon's answer is the least interesting one on purpose: the standard objects where they exist, native custom objects where they do not, and nothing anywhere else.
Yes. Products, Price Books and Price Book Entries are the standard Salesforce objects, and Kugamon reads list prices from them. Kugamon adds an Additional Product Info record per product for the things Salesforce does not model — kits and bundles, configuration, whether a product ships, creates an Asset or a Subscription, renews, uplifts or recognizes revenue.
No. Quote, Order, Invoice, Payment and Shipment are Kugamon objects installed in your org by the managed package, in the kugo2p namespace, and Subscription is in the kuga_sub namespace. They are custom objects in your own org, so they behave like any other Salesforce record for reports, permissions, Flow and the APIs; Kugamon uses its own Quote and Order because its lifecycle — release, shipments, scheduled invoicing, subscription lines — needs fields and behavior the standard objects were not built around.
There is no external database, no Kugamon-hosted service that holds your data, and no API sync layer copying records in or out. The managed package runs on the Salesforce platform inside your org. Gateway connections to Stripe, Authorize.Net, PayPal and eWay are callouts from your org to the processor, with the result stored on the Payment record.
Because a report on quotes, invoices, balances or ARR is an ordinary Salesforce report over ordinary objects, available the day you install, with the same row-level and field-level security as the rest of your org. Nothing is exported, summarized or refreshed on a schedule from a second system.
Your Products and Price Books stay where they are. What moves is transaction history — open quotes, orders, subscriptions and the install base — from the old system's objects into Kugamon's. Because the destination is native and admin-configured, typical migrations run 4 to 8 weeks from Salesforce CPQ; the object mapper on this site shows where each source object lands.
What Salesforce admins say on AppExchange
Quoted verbatim from the Kugamon listing on AppExchange. Reviewer names and dates as published there. Read all 134, including the critical ones →
★★★★★A new bar for RevOps
“As someone who has set up Salesforce CPQ before, I found Kugamon to be much more straightforward and easier to use. It took us just a few weeks to get going, rather than the few months or even years required by other systems.”
★★★★★Easy to understand, easy to implement
“This SFDC-native platform is lightweight but powerful, bringing the entire sales process onto one pane of glass. No more disconnected Opportunities and Quotes/Orders, no more fractured approval processes, just more control over everything. Implementation is a breeze.”
★★★★★Clear & Intuitive
“The Kugamon team is incredibly responsive and handle support questions very quickly. It’s clear they genuinely value customer feedback and are always innovating.”
Configure, price, quote, sign, bill, collect, and renew.
All natively in Salesforce. Deploys in weeks, not months, usually without a systems integrator.