Skip to Content
Welcome to the Novantra documentation.
GuidesGovernanceParty GovernanceOverview

Party governance

A party in Novantra is any external entity your workspace deals with: a customer, a supplier, an applicant, a beneficiary, a partner. Party governance is how your organization defines and runs the structured journey each party walks through with you: from first contact, through eligibility checks, through onboarding, through ongoing engagement, through eventual offboarding.

Party governance is composed of seven modules working together. This section explains how each fits into the whole. If you’ve only encountered the brief summary in Workspace governance, this is the deep dive.

The seven modules

ModuleWhat it owns
Party TypesThe definitions: what kinds of party your organization tracks, and what assignments connect parties to other records.
LifecyclesThe states a party walks through and the transitions between them, versioned and audited.
EligibilityThe rules that gate lifecycle transitions: “this party can move from prospect to approved only if these conditions hold.”
Public SessionsThe mechanism by which external parties interact with the workspace through session links, public forms, and document tasks.
FormsThe form templates parties (or members) complete: structured data capture with versioning and classification.
ResponsibilitiesThe named duties inside the workspace that own pieces of party work.
Review & ApprovalThe cross-cutting actioner that lets any decision flow through reviewers, approvers, and recorded sign-off.

How they compose

These modules are designed to compose. A typical onboarding flow uses all seven:

  1. A public session is issued to a prospective party with a link to a form.
  2. The party completes the form. Their submission moves the party along a defined lifecycle.
  3. Eligibility rules check the submitted data: does it meet onboarding criteria?
  4. Responsibilities route review tasks to the right team members.
  5. Review and approval captures sign-off from those responsible.
  6. The party’s party type determines what subsequent work attaches to them.

You don’t have to use all seven. A party governance program can be as light as: party types + a manual lifecycle. Or as rich as: every lifecycle step gated by eligibility, every approval routed through review-approval, every interaction with the party through a public session and form.

A worked example: a B2B procurement marketplace governs vendor and buyer onboarding

A B2B procurement marketplace platform connects industrial buyers with vetted vendors across categories like industrial components, packaging, and logistics services. Both sides — vendors and buyers — go through a governed onboarding before they can transact. Once active, both sides have ongoing engagement (annual reviews, document refreshes, risk reassessments).

The head of marketplace compliance, Felipe, sets up party governance to handle this. The rest of the pages in this section walk through each piece of his setup:

  • Party Types: he defines vendor and buyer as distinct party types, each with its own set of assignments (a vendor has product categories, certifications, payment posture; a buyer has industry, purchasing posture, account approvals).
  • Lifecycles: each party type has its own lifecycle. Vendors walk prospect → due-diligence → qualified → active → suspended/closed. Buyers walk prospect → kyc-checked → active → suspended/closed.
  • Eligibility: rules gate transitions. A vendor can’t move from due-diligence to qualified unless their certifications are current, their financial standing check passed, and their goods/services align with permitted categories. A buyer can’t move to active unless KYC is clear and payment posture is verified.
  • Public Sessions: prospective vendors and buyers receive a session link that walks them through the relevant intake forms. They don’t get an account in the marketplace until onboarding is complete.
  • Forms: each step in each lifecycle has its own form — vendor intake captures company info, products, financials; vendor certification captures certifications and uploads; buyer intake captures purchasing patterns; etc. Forms are versioned and approved.
  • Responsibilities: the compliance team owns due-diligence review. The category team owns vendor qualification. The credit team owns buyer KYC. Each is a named responsibility assigned to specific members or roles.
  • Review & Approval: every lifecycle transition that gates the party’s marketplace access is routed through review-approval. Approval triggers the transition; rejection routes back with notes.

After three months of operation:

  • Both vendor and buyer onboarding are governed and reproducible.
  • Every transition has an approver and rationale recorded.
  • Eligibility rules catch ineligible parties before they reach the marketplace.
  • Public sessions handle the first touch without requiring marketplace accounts.
  • Forms capture the intake structurally, not as free-form email.
  • Responsibilities mean no party application sits unowned.
  • An auditor reviewing the marketplace’s KYC and AML discipline has the full party governance trail to examine.

The rest of this section walks each piece of that setup in depth.

Where to start

If your organization is rolling out party governance for the first time:

  1. Define your party types through Party Types. This shapes everything else.
  2. Design lifecycles through Lifecycles, one per type that needs governed states.
  3. Add eligibility rules through Eligibility to gate the lifecycle transitions that matter.
  4. Author the forms parties (and members) will complete through Forms.
  5. Set up responsibilities through Responsibilities so no work is unowned.
  6. Wire approvals through Review & Approval for the decisions that need sign-off.
  7. Configure public sessions through Public Sessions for any party interaction that happens outside the workspace.

You can layer these on incrementally. Start with party types + a simple manual lifecycle. Add eligibility rules as you discover what should gate transitions. Wire forms and public sessions when self-service intake matters. Layer review-approval where decisions need traceable sign-off.

Last updated on
RunsParty Types