Business process objects

Companies represent data in Clover as fields. The simplest is a single custom field — a yes/no flag like "Accepts drop-ship orders," or a text value. But a lot of business data is bigger and more structured than one field can hold: a purchase order, an invoice, a product, a chargeback. Clover represents those as business process objects, or BPOs. (In the app today you'll see these called "Business objects.")

A BPO is the same fundamental idea as a custom field, just richer. In both cases a company defines data — about itself or a trading partner — in a fixed shape, and then works with instances of that shape to conduct business. A custom field is the simple end of that spectrum; a BPO, with many fields, configurable views, and stages it moves through, is the complex end.

Definition, layout, and instance

A business process object has three parts:

Definition — the shape: a named record type with its own fields. A purchase-order definition might hold an order number, supplier, line items, and dates. Definitions usually start from a template Clover provides rather than from scratch.
Layout — a configured view of those fields. One layout might be the full internal form your team uses; another, a trimmed view you expose to a connected partner. Layouts control which fields a given audience sees.
Instance — an actual record that follows the definition and holds the values. Each purchase order, each chargeback, is one instance.

So: the definition is the shape, and each instance is a record that holds values.

Records can move through stages

Many business records have a life of their own — a chargeback gets raised, reviewed, disputed, and resolved. A definition can declare those stages and the moves between them, so each instance tracks where it is in its process. This is what makes a BPO more than static data: it models how your business actually works.

How BPOs connect to the rest of Clover

Workflows operate on them. When an admin authors a workflow, they choose the kind of object it works on — a product, a company, or another BPO type. At run time the workflow is handed an existing instance (or creates one), exposes its fields in the task, and writes the assignee's answers back to the record. The same mechanism updates a product, a company, or an arbitrary BPO.
Connections share them. A business process object is visible to a partner only across a connection, and only at the layout and access level you choose.
Dashboards surface them. The metrics a buyer shows a supplier — revenue, invoice accuracy, scorecards — are business process objects underneath.

Where products and companies fit

A product is a business process object — a predefined schema with properties and lifecycle stages, shared between trading partners. A company behaves like one too in how workflows handle it, even though, under the hood, the legacy company model isn't literally a BPO. The practical upshot: workflows manipulate company data, product data, and arbitrary BPOs the same way.

Why they matter

Standard profiles describe who a company is. Business process objects describe what's happening between companies — the operational data that runs a supply relationship. They are the part of Clover that adapts to your business instead of asking your business to adapt to it.

Workflows and tasks — how BPO data is collected and updated
Companies and profiles — custom fields, the simple end of the spectrum
How Clover works — where BPOs sit in the bigger picture