Custom Object

What It Is

A custom object lets an organization describe things that do not fit a standard record category. A club can define Boats, a regulator can define Enforcement Actions and another organization can define its own register. The object is the shared definition; each boat or action is an individual custom record.

The definition brings together properties and operational settings. It chooses how records are named and numbered, whether publication is available, who may reach records and where staff find the category. Optional ownership describes a relationship to another record rather than a separate owner value embedded in every definition.

Why It Matters

An organization needs a coherent register rather than an assortment of unrelated additional fields. A shared object definition gives its records a common structure and lifecycle, while scoping access can keep a sensitive register within an assigned role.

Separating design from activation lets administrators prepare properties before staff start keeping records. Retained archival protects established data when a register goes out of use. Those lifecycle choices also tell consumers whether configuration or record-writing work remains available.

How It Works

An administrator creates a draft with durable identities. Definitions are versioned, count limits include retained objects and replacement cannot bypass lifecycle operations. Properties are added through the custom-field model, with a custom-object limit that includes archived properties.

Activation validates the naming property and reports definition problems together. A suitable naming property allows record names to be derived consistently. Activation also writes query recipes; the examined archive operation contains no matching recipe-retirement call, so query cleanup is not presented as established behavior.

Ownership must use a supported active relationship type ending at the custom object. Publication cannot be disabled while published records remain. Portal configuration is checked against workspace roles and eligibility bindings, but configured predicates and delivered portal screens are distinct evidence questions.

What It Contains

Lifecycle status, naming and numbering, ownership, publication, app placement, staff access and portal access form the object’s main facets. A record category can be useful without app placement or ownership. Placement helps people find it, while ownership supplies a relationship that other views and predicates can use.

Staff access can admit broad record grants or require object-scoped role assignments. That distinction affects both direct requests and navigation. Portal settings describe operation predicates and public publication choices without proving a completed member-facing workflow.

What It Is Related To

The metadata catalogue lists available custom objects beside registered categories and describes fixed record information followed by their properties. Custom fields define those properties; custom records hold the resulting values. Relationship types can supply ownership and other links.

Forms and layouts use the object’s purpose. Custom apps group placed objects in the console, while scoped access determines which entries a person can open. These connections remain independent enough that an unplaced object can still be reached through related-record work.

What Needs Deciding

The product should decide how recipe retention follows object archival and how stored per-owner limits become enforceable behavior. Reset also needs careful product treatment because retained active definitions can lose their properties and data. The findings preserve these gaps so design does not infer enforcement from a stored setting or a successful lifecycle action.