Every piece of data stored, viewed, or processed in the platform is defined through an object. Objects are the foundation of any application built on the platform, and understanding how they work is essential before beginning configuration.
What is an Object?
An object defines a type of business data you want to store. If you think of the platform as a database, an object is similar to a table.
Each object has two parts:
an object specification - its name, description, and settings
a set of attributes - the individual fields that store data
Attributes are the columns; each record stored in the object is a row.
For example, an object that stores project records might have attributes such as Project Name, Start Date, Status, and Owner. Each row in that object stores information about one project.
When you need to store a new type of business data, you create an object for it. If you are modelling customers, contracts, and transactions, each would typically have its own object.
Attribute Settings
Each attribute has configuration options that control how data is stored and validated, including:
whether the attribute is part of the unique key
whether it is mandatory
whether it references another object
what data type it stores
These settings are covered in detail in Create Object Attributes.
The Unique Key (Primary Key)
Every object must have a unique key - one or more attributes whose combined values identify each record uniquely. No two records in an object can share the same unique key values.
Single-attribute unique key - if one attribute is enough to identify a record uniquely, that attribute alone forms the key. For example, if each customer has a unique name, the Name attribute can be the unique key.
Multi-attribute unique key - sometimes one attribute is not enough. For example, an object storing daily transaction records might need both a reference to the entity and a date to uniquely identify each record, because the same entity will have many records across different dates. The unique key would then include both attributes.
Attributes included in the unique key must be set to required and cannot contain null values.
The unique key cannot be changed after an object is created. If you need to change it, the object must be recreated. Plan unique keys carefully before saving.
Attribute types not suitable for unique keys
The following attribute types should not be used in a unique key:
Text (very long values)
HTMLText (special characters and formatting)
File (storage structure does not support uniqueness)
Relationships Between Objects
Objects can be related to each other. Relationships are defined using a reference attribute in the child object that points to the parent object.
In a parent-child relationship, the parent represents the higher-level entity and the child depends on it. For example, a Contracts object might reference a Customers object, meaning each contract belongs to a customer.
One parent can have many children. A customer might have many contracts; a contract might have many line items. These one-to-many relationships allow the platform to model how different types of data connect to each other.
A few important things to know about relationships:
you must create the parent object before its child objects
the relationship is visible on screen - related records appear in panels below the parent record and update automatically when you select a different parent record
underlined attribute values in screens are links; selecting one opens the related record
Audit History
Every change to a record - and every change to an object's definition itself - is recorded in a full audit history, including who made the change, when, and why.
Selection Groups (Optional)
An object can optionally use selection groups to control how dropdown lists behave on screens and in processes. For example, selecting one value in a field can automatically filter the options available in a related field. Selection groups are covered in Selection Groups.