Object Relationships
Audience: Admins, Developers, Solution Architects
Purpose: Explains how Object relationships work in Kizen and helps admins and solution architects design connected data models that improve usability, visibility, and access control.
Overview
Object Relationships let you connect records across Objects so users can navigate related data, share context (such as timeline activity), and control access through team associations. In Kizen, relationships are configured at the Object level through Object Settings and are represented as relationship fields on Records.
During Object configuration, Related Objects appears as Step 2. If Workflows are enabled, it becomes Step 3.
General Settings
Related Objects
Customize Fields
Customize Layout
Permissions
What's an Object Relationship
An Object relationship defines how Records connect to one another across different Objects or on the same Object depending on configuration. Relationships make your data navigable, meaningful, and usable in real workflows rather than isolated lists of Records.
When you create a relationship, Kizen adds a relationship field to each Object so users can link related Records together. For example, a Location can be linked to a Company, a Deal can be linked to a primary Contact, or an Asset can be linked to a Location.
By default, relationships are created in both directions. This means each side gets its own field (for example, Related Company on Locations and Company Locations on Companies), allowing users to move naturally between related Records. You can choose to hide the reverse field if it is not useful for your use case.
Team Associations
Team Associations determine how access to Records is granted when relationships exist between Objects. In other words, this setting controls whether users can see and work with a Record because they are directly involved with it, because they are involved with a related Record, or both. Team Associations are configured using the Where does this object get its team associations? selector.
If this setting is misconfigured, users may run into situations where they can create Records but cannot see or access them later. Taking the time to choose the right option here helps prevent confusion and reduces the need for manual permission management.
Caution: Misconfiguration in this section is often a cause of Object visibility issues. If you are unable to see an Object or its Records, please ensure this configuration is correct.
Direct
Access is based only on a user’s direct connection to the Record. For example, a user can access the Record if they:
Own the Record
Are assigned to the Object or Record
Are explicitly added to a Team Association for the Object or Record
Use this when the Object should stand on its own and should not inherit access from other Objects. This is the most restrictive but safest option.
Related
Access is inherited from related Records. For example, if a user has access to a Location, they automatically gain access to all related Assets, even if they are not directly assigned to each Asset.
Use this option when the Object behaves like a “child” Object and should consistently follow the access rules of its parent.
Caution: Broad relationships can introduce unintended access. If users are granted access to a highly shared parent Record, they may automatically gain access to many related Records. For example, if all Assets are linked to a shared Location like “Headquarters,” giving a user access to that Location would also grant access to every Asset stored there.
Direct and Related
Access can come from either source. Users can access the Record if they are directly associated with it or if they are associated with a related Record.
Use this when you want maximum flexibility and want users to be able to work naturally across related data without constantly managing assignments. This is the most permissive option and may require more governance for larger teams.
Primary vs Additional Relationships
Kizen provides two ways to relate Records, based on whether users need to select one related Record or multiple related Records.
Primary Relationships
Use a Primary relationship when each Record should be connected to only one main related Record.
Best for:
A deal with one primary company
A ticket with one requester
A location with one owning company
Each Record gets a single-select field, so users can choose only one related Record. This improves clarity and consistency across the platform. By enforcing a single primary relationship, reporting, automation, and filtering behave predictably because there is always one authoritative related Record rather than multiple competing values.
Additional Relationships
Use an Additional relationship when each Record may need to be connected to multiple related Records.
Best for:
A deal with multiple stakeholders
A project with several contributors
A location with many assets
Each Record gets a multi-select field, allowing users to link several related Records.
When To Use Both
Many real-world processes need both a clear “main” relationship and supporting relationships. In these cases, use both types together.
Example: Deals and Contacts
Primary relationship: Primary Contact (single-select)
Additional relationship: Additional Contacts (multi-select)
This keeps the most important relationship clear, while still allowing flexibility.
Relationship Types
When you create a relationship between two Objects, Kizen asks you to choose a relationship type. This setting simply describes how many Records can be connected on each side of the relationship.
You will see options like:
One-to-One
One-to-Many
Many-to-One
Many-to-Many (through Additional relationships)
Rather than thinking in database theory, it helps to read the setting like this: “From the Record I’m editing, how many of the other related Records should I be able to connect?”
Examples
Example 1: Locations and Companies
If you configure: Locations → Companies = Many-to-One
That means:
A single Location can be connected to one Company
A Company can be connected to many Locations
In the UI, this typically results in:
A single-select field on Location (for Company)
A list of related Locations on the Company record
Example 2: Locations and IT Assets
If you configure: Locations → IT Assets = One-to-Many
That means:
One Location can be connected to many IT Assets
Each IT Asset links back to one Location
In the UI, this typically results in:
A multi-select or related list of Assets on the Location
A single Location field on each Asset
With Object relationships, you are not choosing a technical structure. You are choosing how users will connect Records in the interface:
Choose “one” when users should only pick one related Record
Choose “many” when users should be able to pick multiple related Records
Relationship Name vs Reverse Relationship Name
When you create a relationship, Kizen asks you to name the fields that users will see on both sides of the connection.
Relationship Name: label for the field that appears on the Object you are currently editing. This is the field users will use to link a Record to another Record. For example, on a Location Record, this might be labeled Related Company.
Reverse Relationship Name: label for the field that appears on the related Object. This allows users to see and navigate back to related Records. For example, on a Company record, this might appear as Company Locations.
Choosing clear, natural names here matters. These labels appear throughout the interface, including on Record detail pages and when users search for and select related Records, so they should match the language your team already uses.
Sharing & Options
Each relationship includes options that control whether certain information appears across related Records. These settings help you decide how much context users should see when moving between Records.
Timeline Sharing
Timeline sharing determines whether activity from one Record appears on another Record’s Timeline.
You can control this in two directions:
Share Timeline To Related: Activity from this Record appears on the related Records Timeline.
Share Timeline From Related: Activity from the related Record appears on this Record’s Timeline.
Enable timeline sharing when you want users to be able to see meaningful activity without having to jump between related Records. For example, it can be helpful to surface deal activity directly on a Company record, or to allow a Project to reflect what is happening across its related Tasks.
You may want to leave Timeline sharing turned off when it begins to create unnecessary noise. This often occurs when a Record is related to many other Records, each generating frequent updates, which can make the Timeline harder to scan and use effectively. As an alternative to disabling Timeline sharing entirely, Object Type filters can be used to temporarily hide updates from specific related Objects while preserving visibility into others.
Lead Source Sharing
Lead Source sharing controls whether lead source information passes between related Records.
You can enable this in either direction:
Share Lead Sources To Related: Lead source values on this Record are applied to the related Record.
Share Lead Sources From Related: Lead source values from the related Record are applied to this Record.
Enable lead source sharing when you want attribution to stay consistent across related Records. For example, if a Contact, Deal, and Company are all part of the same customer journey, sharing the lead source ensures they each reflect the same original origin without requiring users to manually keep those fields in sync.
Suppress Related Field
Suppress Related Field? hides the relationship field on the related Object and prevents updates from appearing in the Timeline.
Warning: Suppression is not reversible.
Use this when:
The reverse relationship would confuse users (example: reference data like States).
You do not want users navigating “backwards” from the related Object.
You want to reduce clutter in layouts and timelines.
What Gets Created When You Add A Relationship
When you save a relationship between two Objects, Kizen automatically sets up the fields users need to link Records together. You do not need to manually create anything else.
First, Kizen adds a relationship field to the Object you are editing, using the Relationship Name you provided. This is the field users will use to connect Records (for example, selecting a Company on a Location Record).
At the same time, Kizen creates a corresponding field on the other Object using the Reverse Relationship Name. This allows users to see and navigate the relationship from the other side as well (for example, viewing all related Locations on a Company Record).
The type of field users see depends on how the relationship was configured:
If the relationship allows only one related Record, the field appears as a single-select.
If the relationship allows multiple related Records, the field appears as a multi-select.
Once the relationship is created, both Objects immediately gain new fields that make it easy to connect and navigate related Records.
Additional Information
Best Practices for Relationship Design
Best Practices for Relationship Design
1. Start with the user workflow, not the database terms
Ask:
“On this Record, do users need to pick one related Record or many?”
“Which direction will users navigate most often?”
“Should timeline activity roll up, roll down, or stay isolated?”
2. Use Primary for the “main” link, Additional for “others”
This matches Kizen’s guidance for common CRM patterns (Company ↔ Contacts, Deal ↔ Contacts).
3. Be intentional about timeline sharing
Turn it on when you want “context at a glance.”
Keep it off when it creates noise, especially when many child Records will generate frequent updates.
4. Use Suppress Related Field sparingly
Because it is not reversible, treat it like a structural decision, not a cosmetic one.
Common Mistakes to Avoid
Common Mistakes to Avoid
Can’t find Records you just created? Check Team Associations. Try Direct and Related.
The relationship feels backwards? You likely picked the wrong direction. Recheck which side should allow one vs many.
Timelines look noisy? Turn off timeline sharing from high-volume child Records.
Labels feel confusing? Rename fields to match real language (e.g., Primary Company, not Related Record).
Thinking about suppressing the reverse field? Only do this if you are certain users will never need to navigate from the other side.
What's Next
Continue to the Object Data Model topic to see how relationships fit into the overall structure of your data.
You can also revisit Object Core Concepts for foundational terminology or review the Records topic to understand how users create and work with data in the platform.
Last updated
Was this helpful?