Object Core Concepts
Audience: Admins, Developers, and Solution Architects
Purpose: Explains the foundational architecture of Objects in Kizen, including how schemas, fields, Records, and relationships work together to support scalable data models, automation, reporting, and integrations.
Overview
Objects are the foundation of how all data is structured in the platform. They determine what fields are available, how Records relate to one another, and which system behaviors are enabled. Objects provide the structure, fields define the details, and Records store the actual data.
The Kizen platform supports two Object configurations:
Standard Objects: used to model structured data for storage, reference, and organization.
Workflow Objects: used to model process-driven data that moves through stages and can optionally support value tracking and pipeline reporting.
The platform remains flexible and can support a wide range of use cases beyond these common patterns. For example, a Standard Object can still track values without becoming a Workflow, and a Workflow can be used without enabling value tracking. This flexibility allows you to design data models that match your business needs while maintaining consistent behavior across automation, reporting, and integrations.
System Behaviors
The following behaviors describe how data is structured and behaves across the platform.
Objects contain the structure: Objects function like a container that holds the schema, fields, relationships, and behavior for a type of data.
Fields define the structure: Fields are configured on the Object, but Field values exist only on individual Records.
Records contain the data: Records represent individual real-world items and store the actual data entered by users or integrations.
Relationships connect Records: Relationships link Records across Objects and enable navigation, automation, and reporting.
For more information, see Object Data Model.
Why Objects Matter
Objects form the structural foundation of the platform’s data model and directly determine how reliable reporting, automation, integrations, and governance function at scale.
A well-designed Object model enables:
Accurate reporting and dashboards
Predictable automation behavior
Scalable integrations
Clean data governance
Reusable configuration across teams
Poor Object design often leads to:
Overly complex automations
Confusing Record relationships
Confusing end-user UX
Reporting that cannot scale
Redundant data
Objects vs Contacts
Contact Objects are a specialized type of Object designed specifically for managing people. They behave like Standard Objects and represent a person and their data.
While fundamentally they behave similarly, there are a few key distinctions between them:
Always present regardless of permissions
No
No
Returned via Objects and Records
No
Yes
Supports Custom Fields
Yes
Yes
Can relate to other Objects
Yes
Yes
Schema flexibility
Limited (Workflows not available)
Fully configurable
Optimized for Communication, Email & SMS
Yes
No
Unique Identifier
Record Name
For more information, see Contacts.
How Objects Are Used
Objects support many of the platform’s most powerful capabilities, including:
Pipelines and lifecycle tracking: Deals, onboarding flows, ticket lifecycles, project stages
Cross-object automation: Triggering record creation or updates in one object when another changes stage
Activity logging with cross-record updates: Logging an activity on a Contact that updates fields on a related Ticket
Dashboards and reporting: Aggregated metrics and insights based on object fields and stages
API integrations: External systems creating, updating, and relating records programmatically
Complex data modeling: Supporting domains such as insurance, healthcare, and financial services
Objects provide the abstraction layer that makes all of this possible without hardcoding business logic.
Object Configurations
Objects share the same foundation, but behave differently based on how they are configured. The configuration you choose affects how data flows through the system, how users interact with Records, and how reporting and automation behave.
Standard Configuration
Use when Records represent structured data that does not move through stages.
No stages or lifecycle
Not shown in pipeline dashboards or board views
Supports fields, relationships, automations, and APIs
Common for reference or structured data (e.g., Locations, Policies, Assets, Providers)
Workflow Configuration
Use when Records represent work that moves through a process or lifecycle.
Includes stages and board (kanban) views
Supports stage-based automation
Powers dashboards and workflow reporting
Optional tracking for value and percent chance to close
Common for Deals, Tickets, Applications, Projects, Cases, Reviews, and similar processes
Choosing the Right Object Configuration
Store structured data without lifecycle
Standard Configuration
Move through stages and require reporting on time in stage
Workflow Configuration
Represent operational processes with heavy automation
Workflow Configuration
Need to track monetary values
Standard or Workflow Configuration with Track Entity $ Value enabled
Track monetary values in a sales pipeline
Workflow Configuration with Track Entity $ Value and Include % Chance to Close enabled
For more information on Object Configurations, see Object Data Model.
Object Name vs Record Name
The platform distinguishes between Object-level labels (collection names) and Record-level labels (instance names), each used in different UI and API contexts.
Object names are primarily used for navigation and structural labeling. Record name fields are used to represent individual instances within an Object.
In addition to display labels, every Record is assigned a system-generated backend name, which functions as the authoritative identifier for APIs, integrations, and internal references. Implementations should rely on this backend identifier rather than display labels.
Objects also have API names. For more information see Object API Names.
Key Use Cases
Objects support the following industry use cases:
Industry Examples
Insurance Teams Modeling Policy and Operational Data
Objects provide the data foundation for insurance platforms by modeling real business entities such as policies, applications, claims, and accounts. This enables structured data capture, cross-Object relationships, reporting, and automation across the entire policy lifecycle.
Insurance teams use Objects to define consistent data models that support underwriting, servicing, compliance, renewals, and integration with external systems.
Examples include:
Creating a Policy Object to store structured data such as policy number, coverage type, effective dates, carrier, premium amount, and status
Defining an Application Object to track intake details, applicant information, risk attributes, and underwriting requirements
Modeling a Claim Object with fields for loss type, incident date, adjuster assignment, reserve amounts, and claim status
Using a Renewal Object with a workflow configuration to have stages such as Pending Review, Offered, Accepted, and Lapsed to manage retention workflows
How Objects Help:
Establish a consistent, scalable data model for policies, applications, claims, and related Records
Enable relationships between Records, such as linking a policy to a contact, agency, carrier, or claim
Support lifecycle management using an Object with a workflow configuration for renewals, onboarding, or claims processing
Power reporting, dashboards, and forecasting based on structured fields like premium value, status, and stage
Enable automation and integrations, such as creating renewal Records when policies near expiration or syncing policy data to external policy administration systems via APIs and webhooks
Healthcare Teams Modeling Clinical and Operational Data
Objects provide the data foundation for healthcare workflows by modeling real-world entities such as patients, referrals, appointments, care plans, and cases. This enables structured data capture, secure relationships between Records, and scalable automation across clinical and administrative processes.
Healthcare teams use Objects to define consistent data models that support care coordination, intake management, operational workflows, and integration with external systems.
Examples include:
Creating a Patient Intake Object to capture structured data such as demographics, referral source, insurance details, and consent status
Defining a Referral Object to track referring provider, specialty, urgency level, and acceptance status
Modeling an Appointment Object with fields for visit type, scheduled date, assigned provider, and attendance status
Using a Care Pathway Object with a workflow configuration to create stages such as Intake, Evaluation, Treatment, Follow-Up, and Completed
How Objects Help:
Establish a consistent, scalable data model for clinical and operational Records
Enable relationships between Records, such as linking patients to referrals, providers, appointments, and care plans
Support lifecycle management using an Object with a Workflow configuration for referrals, treatment workflows, and discharge processes
Power reporting and dashboards for operational visibility, such as referral volume, appointment throughput, and care outcomes
Enable automation and integrations, such as creating follow-up records when appointments are completed or synchronizing patient data with EHR systems through APIs and webhook events
Financial Services Teams Modeling Client and Financial Data
Objects provide the data foundation for financial services workflows by modeling real-world entities such as clients, accounts, opportunities, portfolios, and service cases. This enables structured data capture, relationship modeling, reporting, and automation across advisory, banking, and operations functions.
Financial services teams use Objects to define consistent data models that support client onboarding, relationship management, compliance tracking, and lifecycle-based engagement.
Examples include:
Creating a Client Profile Object to store structured data such as household details, risk tolerance, investment goals, and regulatory classifications
Defining an Account object to track account types, custodians, balances, and account status
Modeling an Opportunity Object to manage advisory engagements with fields for estimated assets, probability to close, and expected close date
Using a Client Lifecycle Object with a workflow configuration to create stages such as Prospect, Onboarded, Active Client, Review Due, and At Risk
How Objects Help:
Establish a consistent, scalable data model for clients, accounts, opportunities, and portfolios
Enable relationships between Records, such as linking clients to households, accounts, advisors, and service requests
Support lifecycle management using an Object with a Workflow configuration for onboarding, engagement management, and retention workflows
Power dashboards and reporting for visibility into AUM, pipeline value, client segmentation, and service performance
Enable automation and integrations, such as creating onboarding Records when a client is won or synchronizing client and account data with CRMs, custodial platforms, and external financial systems through APIs and webhook events
What's Next
Learn more about working with Records, then explore Custom Fields to extend Object schemas and Object Permissions to manage access.
Last updated
Was this helpful?