How Pinion Works (Order of Execution)

A managed package can feel like a black box — its Apex is hidden, so when a price recomputes, a record appears, or a rule fires, there’s no source to read. This page opens the box at the level administration actually needs: what runs, and in what order, for the flows you’ll debug in the field. It’s the execution model, not the algorithms.

The automation model

Pinion follows one trigger per object, with all logic in handler classes behind a dispatcher — never business logic in the trigger body itself. That gives every automation a single, predictable entry point and one choke point for control.

  • Turning automation off. A hierarchy setting, BypassSettings__c, carries a global BypassAllTriggers__c plus per-object flags (Opportunity, OpportunityLineItem, QuoteLineItem, Price Dimension, Attribute Number Band). Because it’s a hierarchy setting, you can bypass automation at the org, profile, or single-user level — useful for a data migration without firing every downstream rule.
  • What this means for you: if Pinion “isn’t doing something,” the bypass settings are the first place to look; if it’s “doing too much” during a bulk load, they’re the switch.

Flow 1 — A rep saves a configuration

This is the pipeline behind the configurator’s Save and Save & Sync, and the one worth understanding deeply because it’s where pricing is decided.

  1. The rep configures in the browser; the client prices live for a responsive UX.
  2. On save, the server takes over. It validates the configuration (product rules that block an invalid cart), then — this is the important part — recomputes every price authoritatively on the server (quantity, base price, discounts, MDQ segments, usage) before anything is written.
  3. It persists the line items with those server-computed values.
  4. On Save & Sync, it writes the deal’s line items from that one authoritative configuration (and marks it the synced one).

The load-bearing guarantee: the server never trusts a client-supplied price. It recomputes the authoritative price and persists that, so a tampered or hand-edited price can’t stick. (This is why “Quick Save” validates without writing lines, and “Save & Sync” is the sole writer of the deal’s lines.)

Flow 2 — A quote syncs to its opportunity

When a Quote syncs to its Opportunity, Salesforce copies the standard fields; Pinion adds twin-field copy — any custom field present on both the quote line and the opportunity line with the same API name copies automatically. No mapping. See Field Propagation for the details.

Flow 3 — An opportunity closes won

When an Opportunity reaches your Closed-Won stage and its Type is contract-eligible, Pinion activates the deal:

  1. Creates a Contract (idempotent — re-closing won’t duplicate).
  2. Creates a Subscription per recurring line and an Asset per one-time line, copying the line’s pricing, quantity, dates, and configuration onto them.

The full field-by-field carry — and why these writes run in system mode — is in Field Propagation and Lifecycle Defaults.

Flow 4 — Scheduled jobs

Some automation runs on a schedule rather than a trigger — auto-renewal opportunity creation and contract-expiration handling. These are the background jobs that keep the contract lifecycle moving without a user action. See Scheduled Jobs.

The subsystems at a glance

Everything above is built from a handful of subsystems. One paragraph each:

  • Pricing engine. A single canonical pricing kernel runs in two places — the browser (for live UX) and the server (as the authority) — kept in lockstep. The server recompute is the tamper-protection boundary: it re-prices before persistence, so displayed and saved prices agree to the cent.
  • Pricing waterfall. The ordered set of steps a line runs through (list price → block price → contracted price → volume/term/manual discounts → promo → floor/ceiling). Admin-configurable, over a locked default that reproduces Pinion’s standard order.
  • Rules engine. Product rules (Filter, Validation, Selection, Alert) and pricing rules shape the catalog and the cart. What the server enforces at save is the Validation type — Filter shapes the catalog server-side, and Selection/Alert run in the configurator for the rep’s experience. (See the trust note below.)
  • Bundles. Products that carry other products — components that scale, accessories that don’t, features with min/max selection, and option constraints (requires/excludes).
  • Approvals. A separate engine that evaluates approval rules on submit, routes to approvers, and gates a configuration from syncing until it’s approved.
  • Quoting. Templates, routing, translation, and PDF generation — rendering a deal into a document.
  • Config Promotion. Moving catalog and pricing configuration between orgs by a stable cross-org identity (the SyncKey), in dependency-safe order.

What’s authoritative — the trust model

Two things are worth stating plainly, because they’re the guarantees that make the rest trustworthy:

  • Pricing is server-authoritative, always. The server recomputes and persists the authoritative price regardless of what the client sent. You cannot save a wrong price.
  • The hard rule gate at save is the Validation rule type. A Validation rule blocks an invalid save server-side. Selection rules (auto add/remove products) and Alert rules (advisory messages) run in the configurator for the rep’s experience; the server doesn’t re-run them at save. The distinction that matters:
    • A soft Selection rule is a default the rep can override (re-add or deselect the product). It imposes no fixed final state, so there’s nothing to enforce — by design.
    • A required Selection rule does fix the final state, and the configurator enforces it. If that constraint must also hold against a save that bypasses the configurator (a direct API/data-load write), back it with a Validation rule — the Selection auto-adds the product for the rep’s convenience, and the Validation makes it binding at save. (Pricing is never in this position: the server always recomputes it authoritatively.)