> For the complete documentation index, see [llms.txt](https://docs.cottfile.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cottfile.com/admin-guide/case-types-and-documents.md).

# Case Types and Documents

Filing types and docket entries define what filers can submit and how those submissions are recorded. How you manage them depends on the parish:

* **Parishes connected to Verdict CMS** -- both pages are **read-only** mirrors of Verdict data.
* **Standalone parishes** (not connected to a CMS) -- both pages are **editable** here in the Admin Panel.

{% hint style="info" %}
**Naming:** what the Admin Panel calls a **Filing Type** is what filers see as a **Case Type**, and an admin **Filing Subtype** is the filer's **Filing Type**. Keep this in mind when matching a filer's question to these pages.
{% endhint %}

## Verdict Parishes: Read-Only View

For a parish with Verdict court codes, filing types, docket entries, and fee schedules all originate in Verdict CMS and sync into the e-filing system automatically. To change them, change them in Verdict — the Admin Panel reflects whatever Verdict has. Each page carries a note that the data "...are managed in Verdict CMS. This is a read-only view."

### Filing Types

Open a parish from the **Parishes** card grid, then choose **Filing Types** in the parish sidebar. Each row shows:

* **Name** -- Display name of the case type (e.g., "Civil")
* **Code** -- Short identifier
* **Sub-Types** -- Count of sub-types under this case type
* **Document Types** -- Count of document types associated with this case type

If no filing types have synced yet, the page shows "No filing types configured."

### Docket Entries

Choose **Docket Entries** in the parish sidebar. Each row shows:

* **Name** -- Display name shown to filers (e.g., "Petition")
* **Code** -- Short identifier
* **Filing Type** -- The case type this document type is associated with, if any

If no docket entries have synced yet, the page shows "No docket entry types configured."

## Standalone Parishes: Editable Reference Data

A standalone parish has no CMS behind it, so its reference data lives here. The Filing Types page explains: "{court} is not connected to Verdict CMS, so its case types, filing types, and advance deposits are managed here."

### Filing Types

The page shows a tree -- **Filing Types — Manage filing types and filing subtypes organized by court** -- with an **Add Filing Type** button. Each filing type row has a **+** button ("Add Filing Subtype"), a pencil to edit, and a trash to delete (with the confirmation "Delete this case type and all filing types?").

**Add/Edit Filing Type** dialog fields:

| Field           | Example / help |
| --------------- | -------------- |
| **Name**        | e.g., "Civil"  |
| **Code**        | e.g., "CIV"    |
| **Description** | Optional       |

**Add/Edit Filing Subtype** dialog fields:

| Field                   | Example / help                                                                              |
| ----------------------- | ------------------------------------------------------------------------------------------- |
| **Name**                | e.g., "Personal Injury"                                                                     |
| **Code**                | e.g., "PI"                                                                                  |
| **Description**         | Optional                                                                                    |
| **Advance deposit ($)** | "Leave blank if no deposit is set" -- "Charged when a filer opens a new case of this type." |

### Docket Entries

The Docket Entries page notes that the parish's "docket entry types and their fees are managed here." The table columns are **Name**, **Code**, **CMS Event Code**, **Linked Filing Type**, and **Actions**, with a search box and an **Add Docket Entry** button. Deleting asks "Delete this docket entry?"

**Add/Edit Docket Entry** dialog fields:

| Field                  | Example / help                         |
| ---------------------- | -------------------------------------- |
| **Name**               | e.g., "Petition"                       |
| **Code**               | e.g., "PET"                            |
| **CMS Event Code**     | e.g., "PTNFLD"                         |
| **Description**        | Optional                               |
| **Base fee ($)**       | "Blank = no fee"                       |
| **Per-page rate ($)**  | "Blank = no per-page fee"              |
| **Linked Filing Type** | Optional; choose a filing type or None |

{% hint style="warning" %}
**Blank is not the same as $0.** A blank fee means *no fee is set*. Entering $0 as a filing type's deposit or a docket entry's fee does **not** make filings fee-exempt -- the platform's e-filing and convenience fees still apply.
{% endhint %}

## Fee Schedules

The **Fee Schedules** page is read-only at every parish -- standalone included. The table shows **Category**, **Type**, **Amount**, and **Effective** only. At standalone parishes, fees are set on the docket entry types above, not here.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.cottfile.com/admin-guide/case-types-and-documents.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
