Skip to Content
Welcome to the Novantra documentation.
GuidesGovernanceParty GovernanceParty Types

Party Types

A party type is a definition. It says “this organization tracks parties of kind X, with these properties, and parties of kind Y, with those properties.” Defining party types is the first step in party governance: it shapes what lifecycle a party can walk, what eligibility rules apply, what forms they fill in, what assignments they hold.

A party type isn’t a person or a company; it’s the kind of party. The actual people and companies are parties of a type.

When you would reach for this

You define party types when:

  • Standing up party governance for the first time.
  • A new kind of party appears in your business (a new vendor category, a new beneficiary class).
  • Existing party kinds need to be split because their lifecycles or eligibility rules diverge.
  • A regulatory regime requires distinct tracking of different party kinds.

You don’t reach for this for an individual party — that’s day-to-day record creation. Party Types is the definition layer.

What lives in a party type

Each party type carries:

  • A name and a stable key (e.g., vendor, buyer, corporate-buyer, individual-applicant).
  • A description of what kind of party this represents.
  • A set of assignment kinds — the kinds of relationship a party of this type can hold with other records.
  • A status (draft, active, retired).
  • A pointer to the lifecycle definition typically used by parties of this type (the default; specific parties can be on bespoke lifecycles where needed).

Assignments

An assignment is how a party connects to another record. A vendor party can be assigned to product categories (which categories they supply), to certifications (which they hold), to engagement records (which contracts they’re under). Each assignment kind has its own shape.

Assignment kinds are defined per party type. Common assignment kinds:

  • primary-contact — points at a member or contact record on the party.
  • engagement — links to a party engagement.
  • category — categorical tagging within the type’s domain (e.g., vendor categories).
  • certification — points at a held certification record.
  • account-officer — names the internal owner responsible for the relationship.

Assignments are how a party plugs into the rest of governance. Without assignments, a party is just an identity record. With them, the party is integrated.

A worked example: the procurement marketplace’s two party types

Felipe’s marketplace governance setup begins with two party types:

Type 1: vendor. Represents a supplier offering goods or services on the marketplace.

  • Assignment kinds for vendors include: product-category (which categories they supply), certification (current certifications they hold), engagement (the master vendor agreement), account-officer (the internal vendor manager), payment-account (where settlement flows).
  • Default lifecycle: vendor-lifecycle (defined in Lifecycles).
  • Status: active.

Type 2: buyer. Represents a buying organization purchasing through the marketplace.

  • Assignment kinds for buyers include: industry-segment (the buyer’s industry), engagement (the buyer agreement), account-officer (the internal account manager), payment-method (how the buyer settles), kyc-status (the current KYC verification posture).
  • Default lifecycle: buyer-lifecycle.
  • Status: active.

A third type emerges later:

Type 3: payment-partner. Represents a financial institution that processes payments on behalf of the marketplace.

  • Assignment kinds: service-line (which kinds of payments they handle), regulatory-licenses, engagement, account-officer.
  • Status: active.

Each type’s assignment kinds shape what’s tracked about parties of that type. A vendor has product categories; a buyer doesn’t. A buyer has KYC status; a vendor’s equivalent is the financial-standing check tracked through their engagement record.

What you’ll see in the product

Party Types lives under Governance → Party → Types in the workspace.

The Types list shows every defined type with its key, name, status, current party count.

Inside a type, you see:

  • The full record and assignment kinds.
  • The default lifecycle reference.
  • The parties currently in this type (with filters).
  • Activity history.

Every change is captured in the workspace Audit Log.

Common workflows

Defining a new party type

  1. Party Types → New type. Pick a stable key, name, description.
  2. Define the assignment kinds the type supports.
  3. Reference a lifecycle (defined separately).
  4. Activate.

Splitting a type

  1. If an existing type has parties that need divergent lifecycles, define a new type for the splitting subset.
  2. Migrate the parties whose handling should change.
  3. Retire the original type if it’s no longer used.

Retiring a type

  1. Migrate or close out the parties of the type.
  2. Transition the type to retired.
  3. Historical assignments remain visible.
Last updated on
OverviewLifecycles