Event

How its data works

An event is a set of fields configured per company, and events are the most open-ended of the entities: beyond the platform’s required fields, you can add and edit any fields you like, with essentially no constraints. The platform requires a type, a status, an auto-assigned reference id, and a name (which it derives for you), and your configuration defines everything else — dates, amounts, coverage details, and any custom fields.

An event’s status starts open by default, and its name is generated by the platform from the exposures and claimant involved.

In the app, the Actions menu at the top right of an event collects the lifecycle operations — closing and re-opening, converting between claim and incident, renaming, generating forms, and deleting. See Event actions.

Connects to	How
Policy	Each event is reported against one policy. A policy can have many events.
Exposures	An event references the exposures it touches (many-to-many) — a single incident can involve several.

Connects to

How

Policy

Each event is reported against one policy. A policy can have many events.

Exposures

An event references the exposures it touches (many-to-many) — a single incident can involve several.

Files, Notes & Contacts

Events support all three shared tabs: upload files, record notes, and attach contacts (people from the directory, such as the claimant or adjuster).

Technical reference

API. Managed through the unified entity CRUD surface as event. See the Entities API overview.Framework-required fields.

Field	Notes
`eventName`	Derived by the platform (`DERIVE_EVENT_NAME(referencingExposures, claimant)`).
`eventType`	Option Set (e.g. Claim / Incident).
`eventStatus`	Defaults to `open`. Settable when the event is created (a historical import can load an already-closed claim), but changing it afterwards goes through the close / re-open actions rather than a field update — they move the status and append to the log together.
`eventReferenceId`	Auto-generated.
`eventCoverageType`	Option Set.
`eventDate`, `reportDate`, `closedDate`	Dates.
`eventOpenCloseHistory`	List of Objects — the event’s open / close / re-open log. Each entry carries `actionTakenDate`, `effectiveOnDate` and `action` (`open`, `close` or `reopen`). The platform appends an entry when an event is created, closed or re-opened; it stays writable so a historical import can supply a claim’s full log.
`openedOn`	Date, read-only — the effective date of the first `open` entry in the log.
`reopenedOn`	Date, read-only — the effective date of the most recent `reopen` entry; empty when the event has never been re-opened.
`previousClosedOn`	Date, read-only — the effective date of the last `close` that preceded that re-open; empty when the event has never been re-opened.
`isReopened`	Boolean, read-only — whether the event has ever been re-opened. Empty (rather than `false`) on an event that has not been written since these fields were added.
`referencingPolicy`	The policy this event is reported against (singular; reverse-read).
`referencingExposures`	Exposures this event touches (tenant-defined expression).
`contacts`	People linked as contacts (join to Person).

Additional fields are configured per company; discover them via the /entities/event/configuration endpoint.

Overview

Insurance entities

Directory entities

How its data works

What it connects to

Files, Notes & Contacts

​How its data works

​What it connects to

​Files, Notes & Contacts

How its data works

What it connects to

Files, Notes & Contacts