> For the complete documentation index, see [llms.txt](https://docs.monolithforensics.com/monolith/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.monolithforensics.com/monolith/using-monolith/case-management/cases.md). # Cases Create and manage cases as the central workspace for evidence, acquisitions, tasks, documentation, people, quality assurance, reporting, and other forensic work in Monolith. A **Case** is the central Monolith record representing an investigation, matter, request for work, or other unit of forensic casework. Cases bring the information and activity associated with that work together in one place. Instead of maintaining separate spreadsheets, notes, evidence trackers, task systems, file repositories, and reports, Monolith connects those records back to the Case they belong to. A Case can bring together: * Evidence Items * Acquisitions * Storage Items * Clients and Contacts * Tasks * Notes * Files * Quality Assurance * Reports * Activity history * Assignments * Custom Fields * Status and Progress information This makes the Case the primary workspace for understanding what the work is, who is responsible for it, what has been collected, where each part of the workflow stands, and what has happened over time. ### Cases in the Monolith Workflow Most Monolith workflows eventually center around a Case. A common workflow looks like: ``` Request or Case Creation ↓ Case ↓ Evidence ↓ Acquisitions and Forensic Work ↓ Documentation, Tasks, and QA ↓ Reporting ``` Not every organization follows the same process. Monolith allows teams to configure Case Types, Progress stages, [Custom Fields](/monolith/using-monolith/settings/custom-fields.md), and other options around the way their lab or organization actually works. The Case provides the overall structure while individual Evidence Items, Tasks, Acquisitions, and other records can progress independently within it. ### Global Cases and the Case Workspace There are two useful frames of reference when working with Cases. #### Case Management > Cases The main **Cases** page provides an organization-wide view of Case records available to you. Use this view to: * Search for Cases * Filter and sort Case information * Review work across the organization * Focus on Cases you are assigned to * Create a new Case * Open an existing Case The **My Cases** view focuses on Cases where you are assigned in some way. The Cases visible in the broader view depend on your Monolith account access and permissions. #### Inside a Case Opening a Case takes you into the workspace for that specific investigation or matter. From there, you can work with its Evidence, Acquisitions, Storage Items, Tasks, Notes, Files, Contacts, Quality Assurance, Reports, and other related information without losing the Case context. #### Video Walkthrough - Case Workspace {% embed url="" %} If the video does not render, you can [watch on YouTube here](https://youtu.be/xv-VZMJYvzY) {% endembed %} ### Ways Cases Enter Monolith Cases can enter Monolith through several workflows. #### Create a Case Manually Users can create a Case directly from **Case Management > Cases**. This is useful when your team already has the information needed to begin work and does not need a separate request or triage process. #### Create a Case From an Inquiry Requests submitted through **Relay** arrive in Monolith as Inquiries. After reviewing the request, your team can use the Inquiry to create a new Case. Supported request information can carry forward into the Case, including Evidence, Contacts, files, requestor information, and mapped Custom Fields. This reduces duplicate data entry between request intake and active casework. #### Merge an Inquiry Into an Existing Case When a new request belongs to a Case that already exists, the Inquiry can be merged into that Case rather than creating a duplicate Case. Merge Inquiry can add selected Evidence Items, Contacts, and Documents while preserving the Case's existing metadata. Review the Inquiry for any request narrative, Custom Field values, or other Case-level information that should also be manually added to the existing Case. See [**Inquiries**](/monolith/using-monolith/case-management/inquiries.md) for detailed Create Case and Merge Inquiry behavior. #### Cases API Organizations integrating Monolith with another system can also create and work with Cases through the Monolith API. See [**Cases API**](/monolith/monolith-api-and-webhooks/cases-api.md) for available endpoints and implementation details. {% hint style="info" %} Historical data migrations are typically coordinated during Monolith implementation rather than performed through the normal Case creation workflow. {% endhint %} ### Create a Case {% embed url="" %} If the video does not render, you can [watch on YouTube here](https://www.youtube.com/watch?v=851vRjmFl70) {% endembed %} To create a Case: 1. Navigate to **Case Management > Cases**. 2. Select **Create Case**. 3. Enter or review the **Case Number**. 4. Enter a **Case Name**. 5. Select a **Client**, if applicable. 6. Select a **Case Type**. 7. Select the appropriate **Case Status**. 8. Select a **Case Lead**, if applicable. 9. Enter the **Case Open Date**. 10. Select a **Case Priority**. 11. Enter a Description. 12. Complete any applicable Custom Fields. 13. Select **Create Case**.
The create a case form inside of Monolith
Not every field is required. Capture the information that is useful to your workflow and reporting requirements. ### Case Number and Case Name The **Case Number** provides the structured identifier used to reference the Case. Monolith can automatically generate Case Numbers using the format configured by your organization under **Settings >** [**Item Number Formats**](/monolith/using-monolith/settings/item-number-formats.md). Using a consistent Case Number format is recommended because it provides a stable identifier that can be searched, reported on, and referenced across your organization. The **Case Name** provides a more human-readable description of the investigation or matter. For example, a Case Number may follow an organization's formal numbering convention while the Case Name identifies the project, investigation, incident, or matter in language that users can quickly recognize. ### Clients A Case can be associated with a **Client** representing the person or organization requesting the work. A Client is optional during Case creation and can be updated later. When a Case originates from a Relay Inquiry, the requestor can carry forward as the Client during the create or merge workflow. See [**Clients**](/monolith/using-monolith/people/clients.md) for additional information. ### Case Types **Case Types** classify the kinds of work your organization performs. The categories that make sense depend on the organization. A law enforcement laboratory might use Case Types related to crimes or investigative categories, while a corporate, consulting, or legal team might use categories such as internal investigations, data breaches, legal matters, or other service types. Consistent Case Types improve filtering, reporting, analytics, and historical understanding of the work your team performs. See [**Case Types**](/monolith/using-monolith/settings/case-types.md) for configuration guidance. ### Case Priority Case Priority provides a quick indication of relative urgency.
Available priorities are: * **Urgent** * **High** * **Low** * **None** Priority is separate from Status and Progress. It describes how urgently the Case should be treated rather than where it is in the workflow. ### Custom Fields Custom Fields allow your organization to capture additional Case information that is specific to your workflow. For example, an organization might track internal identifiers, legal information, referral details, matter attributes, or other metadata that is not part of the standard Case form. Capturing useful structured information makes that data available for filtering, reporting, templates, integrations, and future reference. ### Status, Progress, and Assignment Monolith separates several concepts that are often combined in simpler case tracking systems. Each answers a different operational question. #### Case Status **Case Status** describes the current state of the Case. **Active** and **Closed** are permanent Monolith statuses and control whether the Case is considered open or closed. Organizations can create additional Case Statuses to describe other states used in their workflow. These additional statuses provide useful classification without closing the Case. When a Case is changed to **Closed**, Monolith records the Case as closed and maintains the associated Case Close Date information. See [**Case Statuses**](/monolith/using-monolith/settings/case-statuses.md) for configuration guidance. #### Case Progress **Case Progress** represents where the overall Case sits within your organization's workflow. Progress stages are configurable. For example, a forensic workflow might include stages such as: ``` Pending → Processing → Preservation → Collection → Analysis → Reporting → Case Completed ``` This is only an example. Organizations should configure Case Progress around the stages that are meaningful to their own process. Case Progress provides a quick visual pipeline across the top of the Case workspace. See [**Case Progress**](/monolith/using-monolith/settings/case-progress.md) for configuration guidance. #### Case Progress Metrics The Case Overview also provides calculated progress information based on work associated with the Case.
**Total Progress** considers completion across: * Tasks * Evidence Items * QA Reviews **My Progress** provides a similar view scoped to work associated with the current user. These metrics provide another perspective on Case completion alongside the configurable Case Progress pipeline. The pipeline answers: > Where is the Case in our process? The calculated progress metrics help answer: > How much of the work associated with the Case has been completed? #### Case Lead A Case can have one **Case Lead**. The Case Lead identifies the primary person responsible for the Case. When a Case Lead is assigned, the Case is associated with that user's Office. User accounts and Office assignments are managed through [**Team Management**](/monolith/using-monolith/organization/team-management.md). A Case does not require a Case Lead, although assigning one can provide clearer ownership and workload visibility. #### User Assignments Additional users can be assigned to the Case. Assignments provide users with access to the Case based on their permissions and allow work within the Case to be distributed across the team. Users assigned to the Case can also be selected for other Case-related responsibilities, such as Evidence assignments. #### Group Assignments Groups allow multiple users to be associated with a Case more efficiently. This can be useful when a team, unit, or group of examiners routinely works on the same Cases. Together, Case Lead, User Assignments, and Group Assignments provide different ways to establish ownership and collaboration. ### Understanding the Case Workspace The Case workspace brings the major parts of the Case together through a set of tabs.
Depending on your Monolith configuration, available areas may include: * Overview * Evidence * Acquisitions * Storage Items * Analysis * eDiscovery * Tasks * Notes * Files * Contacts * Quality Assurance * Reports * Activity Some features, including **Analysis** and **eDiscovery**, may not be enabled in every Monolith environment. ### Overview The **Overview** tab acts as the Case command center. It brings together information such as: * Case Number and Name * Status * Progress * Priority * Open and Close Dates * Last Activity * Case Lead * Office * Client * Case Type * Evidence and Acquisition counts * Task information * User and Group assignments * Custom Fields * Description * Progress metrics Use the Overview to quickly understand the Case before moving into its more detailed workflows. ### Evidence The **Evidence** tab contains the Evidence Items associated with the Case. Evidence represents the devices, data sources, accounts, media, and other items connected to the forensic work. Individual Evidence Items can maintain their own metadata, assignment, Progress, Chain of Custody, location, Acquisitions, Photos, Notes, and other information while remaining associated with the overall Case. See **Evidence Items** for detailed guidance. ### Acquisitions The **Acquisitions** tab tracks forensic collections, images, extractions, exports, or other acquisition activity performed as part of the Case. An Acquisition can be associated with an Evidence Item when it originates from a specific source. Useful Acquisition information can include: * Acquisition Name * Evidence Item * Format * Type * Forensic Software and version * Size * Storage Item * Hash values and algorithms * Acquisition Date * Duration * Acquired By * Linked Contact * Notes * Custom Fields Associating an Acquisition with its source Evidence Item creates a stronger relationship between the source, collection activity, and resulting forensic data. It also improves how that information can be used later in reporting. ### Storage Items The **Storage Items** tab contains storage specifically assigned to the Case. Assigned Storage Items are available for that Case until they are unassigned. Monolith also supports general Storage Items that can be used across Cases. Forensic Acquisitions can be associated with the appropriate Storage Item to record where the acquired data is being preserved. See **Storage Items** for additional guidance. ### Tasks The **Tasks** tab shows work associated with the Case. Tasks can be created for the Case generally or associated with a specific Evidence Item when additional context is useful. Tasks can include assignments, due dates, categories, priorities, subtasks, and other workflow information. **Task Templates** can be used to recreate repeatable workflows. For example, a team might create an `iPhone Collection` template containing the standard steps that should be completed each time that type of work is performed. This can help teams: * Standardize repeatable procedures * Assign work consistently * Break larger workflows into subtasks * Track completion across the Case * Reduce the need to recreate the same task structure for every Case Keeping Tasks connected to the Case helps users understand not only what needs to be done, but which investigation and Evidence Item the work relates to. ### Notes The **Notes** tab provides a rich workspace for documenting Case-specific information directly within Monolith. Case Notes can be used for investigative notes, examination details, findings, summaries, procedural documentation, or other information that belongs to the overall Case. The Notes editor supports structured content such as: * Formatted text * Tables * Images and pasted screenshots * Links * Other rich note content [**Editor Templates**](/monolith/using-monolith/settings/editor-templates.md) can also be used to standardize information your team records repeatedly. For example, a team may create templates for common examination procedures, intake documentation, findings, or other recurring note formats. Evidence Items can maintain their own Notes when information relates more specifically to an individual source. Keeping Notes inside Monolith preserves the context of the work and allows supported information to be incorporated into Case Reports. ### Files The **Files** tab provides a Case-level repository for documents and other files associated with the Case. This can include reports, supporting documents, exports, working files, and other Case documentation. Files stored in Monolith can also be shared with approved Relay users through [**Case Drives**](/monolith/relay-request-portal/relay-overview/using-relay.md#case-drives) when external file sharing is needed. Organizations that want to use Monolith for larger forensic images, long-term digital evidence, or high-volume file storage can also use Monolith's expanded digital evidence storage capabilities. See the [**Digital Evidence Storage** product page](https://www.monolithforensics.com/solutions/digital-evidence-storage) for additional information about large-scale storage options. ### Contacts The **Contacts** tab contains the people associated with the Case. Contacts can represent anyone relevant to the investigation or matter. Examples include: * Custodians * Employees * Investigators * Attorneys * Suspects * Victims * Witnesses * Contractors * Device owners * Account holders * Other involved people Contacts can also be associated with individual Evidence Items or Acquisitions when that relationship is useful. Contacts can be added manually, imported by CSV, sourced through supported Google Workspace or Microsoft 365 integrations, or managed through the [**Contacts API**](/monolith/monolith-api-and-webhooks/contacts-api.md). See [**Contacts**](/monolith/using-monolith/people/contacts.md) for additional guidance. ### Quality Assurance The **Quality Assurance** tab supports review workflows where another team member needs to verify part of the Case or forensic work. A QA Review can use a configured checklist and be assigned to another Monolith user. The assigned reviewer receives the related work and can complete the review within the Case. This can support peer review, technical review, internal quality processes, and organizations with formal accreditation or review requirements. ### Reports The **Reports** tab turns information collected throughout the Case into an editable Microsoft Word report. Reports can incorporate supported information from the Case, including Evidence, Acquisitions, Chain of Custody, Notes, Contacts, Tasks, analysis, and other Case data. Monolith provides a standard report builder, and organizations can also use customized Word templates to match their own reporting requirements. Because the report is generated as a `.docx` file, users can make final edits before delivering or archiving it. See [**Case Reports**](/monolith/using-monolith/case-management/cases/case-reports.md) for detailed reporting guidance. ### Activity The **Activity** tab provides a historical view of recorded activity associated with the Case. Entries generally identify the time, user, and activity performed. This provides useful context when reviewing how a Case has changed over time. The Activity tab is not intended to represent every possible action performed anywhere in Monolith. ### Optional Analysis and eDiscovery Features Some Monolith environments may also include **Analysis** or **eDiscovery**. **Analysis** provides timeline-oriented analysis capabilities for tracking events and related investigative information. **eDiscovery** provides tools for tracking legal holds and related eDiscovery workflows. These features may not be enabled in every environment. ### Closing a Case When work is complete, changing the Case Status to **Closed** marks the Case as closed and records the Case Close Date. A closed Case remains part of the organization's historical record. Closing a Case does not necessarily prevent an authorized user from opening the Case or adding information later if additional work is required. ### Editing and Deleting Cases Case information can be edited when information changes or needs to be corrected. Deleting a Case is also available to users with the appropriate permissions. {% hint style="warning" %} Deleting a Case can remove a significant part of your organization's historical forensic record. Monolith asks for confirmation before deletion. Review the Case and its associated information carefully before proceeding. {% endhint %} ### Why Structured Case Information Matters A well-maintained Case record provides more than a place to store information about one investigation. Consistent Case data supports: * Faster searching and historical lookup * Better handoffs between examiners * Clearer ownership and assignments * Workload and backlog visibility * Progress tracking * Consistent evidence and acquisition relationships * More complete reporting * Quality assurance * Management reporting and analytics * API and integration workflows * Long-term institutional knowledge The goal is to maintain a Case record that remains understandable and useful throughout the work and long after the Case has been completed. ### Recommended Practices * Use a consistent Case Number format across the organization. * Enter a clear Case Name that users can quickly recognize. * Use Case Types that reflect the work your organization actually performs. * Capture useful structured metadata and Custom Fields when that information matters to your workflow. * Assign a Case Lead when clear ownership is important. * Use User and Group assignments to support collaboration. * Keep Case Status, Progress, Priority, and assignments focused on the different questions they are designed to answer. * Create Evidence Items for the individual sources involved in the Case. * Associate Acquisitions with Evidence when the source relationship is known. * Use Tasks, Notes, Contacts, QA, and Files within the Case so related work stays connected. * Keep information current so searches, reports, analytics, and future reviewers can rely on the Case record. * Close Cases when work has been completed rather than leaving completed work indefinitely active. ### Related Documentation * [**Case Management**](/monolith/using-monolith/case-management.md) * [**Case Reports**](/monolith/using-monolith/case-management/cases/case-reports.md) * [**Inquiries**](/monolith/using-monolith/case-management/inquiries.md) * [**Evidence Items**](/monolith/using-monolith/evidence-management/evidence-items.md) * [**Storage Items**](/monolith/using-monolith/evidence-management/storage-items.md) * [**Contacts**](/monolith/using-monolith/people/contacts.md) * [**Managing Relay Requests in Monolith**](/monolith/relay-request-portal/relay-overview/managing-relay-requests-in-monolith.md) * [**Cases API**](/monolith/monolith-api-and-webhooks/cases-api.md)