Overview
An Object Interface is a PHP interface that a domain object implements to declare its semantic role within the platform. Registering an object with the platform tells it that something is an object — an Object Interface tells the platform what kind of thing it is: a customer, a document, a piece of content.
This distinction unlocks platform-level capabilities that would otherwise require custom implementation in every project: richer UI components that understand the object’s role, standardized actions and workflows scoped to that role, and cross-object features like linking any CustomerObject to a contact timeline.
No Object Interfaces are currently provided by Core. This page documents the concept and extension point so you can design your object model with this pattern in mind.
How It Works
An Object Interface is a plain PHP interface that declares a set of methods mapping the object’s properties to well-known semantic fields.
interface CustomerObject
{
public function getCustomerEmail(): ?string;
public function getCustomerName(): ?string;
public function getCustomerPhone(): ?string;
}
class Contact extends Model implements CustomerObject
{
public function getCustomerEmail(): ?string
{
return $this->email;
}
public function getCustomerName(): ?string
{
return $this->full_name;
}
public function getCustomerPhone(): ?string
{
return $this->phone;
}
}
if ($object instanceof CustomerObject) {
// render the customer-specific UI panel
// attach the standard customer actions
// link to the contact timeline
}
Why This Matters
The power of Object Interfaces comes from decoupling semantic meaning from implementation. A Contact, a Company, and a Lead might all represent a customer relationship in different contexts. By implementing CustomerObject, each signals to the platform that it participates in the customer-related feature set — regardless of its internal data model.
This enables three things:
Richer UI components. A CustomerTimeline component can render for any CustomerObject without knowing its concrete type. A DocumentViewer can display any DocumentObject. The platform ships the component once; objects opt in.
Standardized platform actions and workflows. An “onboard customer” workflow can target any CustomerObject. A “request signature” action can be offered on any DocumentObject. The workflow is defined once at the platform level and becomes available to all implementing objects automatically.
Cross-object discoverability. Features like global search, reporting, and AI context assembly can use interfaces to find “all things that are customers” or “all things that have content” across the entire object graph, without hardcoding model class names.
Anticipated Interface Types
These are the kinds of semantic interfaces likely to emerge as the platform matures. None are finalized or available yet.
| Interface | Semantic Role | Example Objects |
|---|
CustomerObject | Represents a person or organization in a commercial relationship | Contact, Company, Lead |
ContentObject | Has a rich-text body intended for human reading or publication | Post, Article, Note |
DocumentObject | Is a formal document, often requiring review or signature | Contract, Proposal, Invoice |
MediaObject | Is primarily a media asset (image, video, audio) | Asset, Recording |
When designing your object model, consider which of these roles apply to your objects. Even before the platform provides interfaces for them, structuring your objects this way makes future adoption straightforward.
Relationship to Capabilities
Object Interfaces and Capabilities are complementary but distinct:
| Object Interfaces | Capabilities |
|---|
| What they express | What the object is semantically | What the object can do technically |
| Declared via | PHP interface implementation | Trait on the model |
| Consumed by | Platform features, UI components, workflows | Core system (search index, media library, activity log) |
| Example | implements CustomerObject | use Searchable |
