> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parley.so/llms.txt
> Use this file to discover all available pages before exploring further.

# Where information belongs

> Native properties, custom fields, notes, files, outputs, email, and calendar — and how to choose between them.

Parley gives each kind of information an appropriate home. The most reliable system does not collapse them into one record type.

## The layers

```text theme={null}
Calendar events = what is scheduled
Emails          = what was communicated
Notes           = what should be remembered
Files           = what was documented
Fields          = what is structurally true
Workflows       = what should happen next
```

Together these make a record useful without making any single layer carry every kind of information.

## Native properties

Built-in attributes that define the identity or basic structure of a record: a Project name, an Account name, a Contact's name, an Account association on a Contact.

Use native properties for core identity. Don't create a duplicate custom field merely because a native property is also represented as text.

## Custom fields

Custom fields — also called resource fields — are organization-defined, typed attributes attached to Accounts, Contacts, or Projects. They're for structured information that should be consistently captured, filtered, reported on, exported, or used to guide downstream work.

| Field                      | Lives on |
| -------------------------- | -------- |
| Case Status                | Project  |
| Target Date                | Project  |
| Country of Citizenship     | Contact  |
| Current Immigration Status | Contact  |
| Web Address                | Account  |
| Client Type                | Account  |

See [Field types](/self-driving/field-types).

## Notes

Narrative context attached to an Account, Contact, or Project. Use a note for information that's important for future work but doesn't fit naturally into a typed field: intake summaries, case strategy, relationship background, open questions, internal instructions, explanations of unusual facts, meeting or call summaries.

A note is durable context — not a replacement for a source document or a structured field.

## Files

Source artifacts: agreements, identity documents, correspondence, reports, pleadings, exhibits, templates.

Each Account, Contact, and Project can own a file tree with folders and documents. Projects commonly hold matter-specific evidence and work papers, while Accounts and Contacts hold reusable or person-specific documents.

Parley extracts text from supported documents, so agents can search and reason over the contents without every fact being copied into a note or field.

## Generated outputs

Work products produced by Parley agents — drafts, briefs, forms, packets, letters. They are distinct from source files:

* **Files** are inputs supplied to Parley.
* **Outputs** are work products generated from those inputs and the record context.

Keeping the distinction clear preserves the difference between evidence and the work product created from it.

## Email and calendar

**Calendar events** answer: what is scheduled, when, and who is expected to participate? Consultations, interviews, hearings, filing appointments. When a date must remain a durable case attribute — a statutory deadline, a target filing date — represent it in a Project date field as well.

**Emails** answer: what was communicated, by whom, and when? Email is evidence of communication and often supplies facts worth preserving in the matter's context. A concise operational conclusion may belong in a note, while the original email remains the authoritative correspondence.

<Warning>
  Don't use a status field to store an email thread, and don't replace important source correspondence with a paraphrase when the original message matters.
</Warning>

See [Email and calendar](/integrations/email-and-calendar).

## Workflows

The procedural layer: the sequence of actions, conditions, and handoffs used to move work forward.

A workflow may use fields as inputs, files as required evidence, emails as communication, calendar events as scheduled steps, and notes as human-readable context. The workflow should not become the permanent home for the underlying facts — those belong on the appropriate Account, Contact, Project, note, or file.

## Choosing where information belongs

Ask these in order:

<Steps>
  <Step title="Is this identifying the record?">
    Use a native property.
  </Step>

  <Step title="Is this a structured fact to filter, report, or reuse?">
    Use a custom field.
  </Step>

  <Step title="Is this narrative context, an instruction, or a conclusion?">
    Use a note.
  </Step>

  <Step title="Is this source evidence or an original artifact?">
    Use a file.
  </Step>

  <Step title="Is this a connection between records?">
    Use a relationship.
  </Step>

  <Step title="Is this a communication or scheduled event?">
    Preserve it as email or a calendar event.
  </Step>

  <Step title="Is this a sequence of actions or conditions?">
    Use a workflow.
  </Step>
</Steps>

## A practical example

A firm handling an employment-based immigration filing:

* The employer is an **Account**.
* The employee is a **Contact** linked to that Account.
* The filing is a **Project** linked to both.
* `Current Immigration Status` belongs on the Contact, because it describes the person generally.
* `Case Status`, `Receipt Number`, and `Target Date` belong on the Project, because they describe the filing.
* The employment agreement and identity documents are **Files**.
* A summary of the client's explanation of a complicated travel history is a **Note**.
* The consultation appointment is a **Calendar event**.
* The client's instructions sent by email remain **Email correspondence**.
* A filing checklist or generated support letter is a **Generated output**.
* The steps for collecting missing evidence belong to the **Workflow** layer.

The same fact should not be copied into every layer. Each layer points to or relies on the durable source that owns the fact.