> 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/inquiries.md). # Inquiries Review and triage incoming work before creating a new Case or merging the request into an existing Case. An **Inquiry** is a pre-case intake record used to collect, review, and triage requested work before it becomes an active Case. Inquiries give your team a place to evaluate what has been requested, review the available Evidence, Documents, Contacts, and other information, and decide how the request should move forward. A common workflow looks like: ``` Request ↓ Inquiry ↓ Review and Triage ↓ ┌──────────────────┬─────────────────────┐ ↓ ↓ Create New Case Merge Into Existing Case ``` Relay is Monolith's built-in request portal and is a common way for Inquiries to enter Monolith, but Inquiries can also be created manually or through the Monolith API. ### View Inquiries Navigate to **Case Management > Inquiries** to view the Inquiries available in your Monolith environment. The Inquiries table provides an organization-wide view of incoming and previously processed requests. The table can display metadata associated with each Inquiry, including standard fields and configured Custom Fields.
Available columns may include: * Request Name * Status * Inquiry Date * Type * Converted Date * Client * Organization * Email * Description * Referred By * Evidence Total * Custom Fields * Other Inquiry metadata available in your environment Use the column selector to choose which information appears in the table. This allows teams to surface the Inquiry details that are most useful for their intake and triage workflow. Use search, filters, sorting, and the available table controls to find and review requests. For example, an organization might display legal authority, request type, evidence count, priority-related information, or other Custom Fields directly in the Inquiry queue so users can evaluate incoming work without opening each request individually. ### Ways Inquiries Enter Monolith #### Relay Requests submitted through [**Relay**](/monolith/relay-request-portal/relay-overview/managing-relay-requests-in-monolith.md#review-inquiries) flow directly into **Case Management > Inquiries**. Relay provides a structured request experience for people outside the primary Monolith user base while allowing the forensic team to review the resulting request inside Monolith. A Relay-originated Inquiry can include: * Requestor and Client information * Request details * Evidence * Documents * Contacts * Custom Fields * Submitted date and time When the team is ready, the Inquiry can be used to create a new Case or merged into an existing Case. See [**Managing Relay Requests in Monolith**](/monolith/relay-request-portal/relay-overview/managing-relay-requests-in-monolith.md) for the complete Relay workflow. #### Manual Entry Users can also create an Inquiry directly in Monolith.
This can be useful when a request is received through another channel but the team still wants to use the Inquiry workflow for intake and triage. #### Inquiries API Organizations with another request, intake, or business system can use the **Inquiries API** to integrate that workflow with Monolith. This allows organizations to use Monolith's Inquiry and Case Management workflows without requiring Relay to be the source of every request. See [**Inquiries API**](/monolith/monolith-api-and-webhooks/inquiries-api.md) for available endpoints and implementation details. {% hint style="info" %} Inquiries created manually or through the API remain Monolith Inquiries. They do not automatically create a corresponding request in Relay. {% endhint %} ### Create an Inquiry Manually To create an Inquiry: 1. Navigate to **Case Management > Inquiries**. 2. Select **New Inquiry**. 3. Enter a **Request Name**. 4. Select an existing [**Client**,](/monolith/using-monolith/people/clients.md) or create a new Client. 5. Select the **Inquiry Type**. 6. Enter the person or source that **Referred By**, if applicable. 7. Enter a **Description**. 8. Complete any applicable Custom Fields. 9. Select **Create Inquiry**. A Client is required when manually creating an Inquiry. #### Inquiry Type Inquiry Type uses the [**Case Types**](/monolith/using-monolith/settings/case-types.md) configured in Monolith. This allows the same organizational categories used for Cases to help classify requested work while it is still in the Inquiry stage. For example, a law enforcement organization may use investigative or crime-related types, while a corporate or legal team may use categories such as internal investigation, breach, or legal matter. See **Case Types** for configuration guidance. ### Review an Inquiry Open an Inquiry to review its submitted information and determine how the request should proceed.
The Inquiry workspace includes: * **Overview** * **Evidence** * **Documents** * **Contacts** The left side of the Inquiry also displays Requestor and Inquiry information such as: * Client * Organization * Email * Referred By * Request Name * Inquiry ID * Relay information, when applicable * Status * Type * Inquiry Date Inquiry information can be edited as additional details become available. ### Evidence The **Evidence** tab contains the devices, accounts, data sources, media, and other items submitted or added as part of the Inquiry. Evidence can be added or updated while the request is still being reviewed. The Inquiry workflow captures the core information needed to identify the item without requiring the full Evidence intake and chain of custody information used later during active casework. Standard Evidence information available during Inquiry intake can include: * Evidence Number * Evidence Type * Make or Provider * Model Number or Service * Unique Identifier * IMEI * Description Depending on your organization's configuration, additional **Evidence Custom Fields** may also be collected as part of the request. When the Inquiry is used to create a new Case or merged into an existing Case, your team can select which Evidence Items should carry forward. Selected Evidence becomes Evidence Items within the resulting Case, and supported metadata collected during the Inquiry carries forward with each item. Once the Evidence Item is part of the Case, your team can add the additional information needed for active casework, including intake details, chain of custody, location, assignment, acquisitions, photos, notes, and other Evidence metadata. #### Evidence Custom Fields Evidence Custom Fields remain associated with the individual Evidence Item as it moves from the Inquiry into active casework. For example, if your organization collects additional information about a device, account, authority, condition, or requested collection during intake, those values can remain attached to that Evidence Item after the Case is created or merged. This is different from **Inquiry Custom Fields**, which describe the request as a whole and can be mapped to corresponding Case Custom Fields. Preserving Evidence information through the intake workflow reduces duplicate data entry and maintains continuity between the original request and the Evidence record used during forensic work. See [**Evidence Items**](/monolith/using-monolith/evidence-management.md#evidence-items) for information about managing Evidence after it becomes part of active casework. ### Documents The **Documents** tab contains files provided with or added to the Inquiry. Examples might include: * Authorization documents * Request forms * Supporting documentation * Legal documents * Screenshots * Other files relevant to the request Selected Documents can carry forward when the Inquiry is used to create or merge a Case. ### Contacts The **Contacts** tab contains people associated with the request. Contacts might include investigators, custodians, employees, attorneys, suspects, witnesses, victims, device owners, account holders, or other people relevant to the requested work. Selected Contacts can carry forward into the resulting Case and can later be associated with individual Evidence Items or Acquisitions when appropriate. See [**Contacts**](/monolith/using-monolith/people/contacts.md) for additional information. ### Custom Fields Custom Fields allow your organization to collect additional structured information during intake. An Inquiry can include both **Inquiry Custom Fields** and **Evidence Custom Fields**, depending on how your environment is configured. #### Inquiry Custom Fields Inquiry Custom Fields capture structured information about the overall request. Examples might include legal authority, requesting department, service requested, handling requirements, or other information relevant to the request as a whole. Inquiry Custom Fields can be mapped to corresponding **Case Custom Fields** for use when creating a new Case from the Inquiry. This allows supported request-level information to initialize the new Case without requiring users to enter it again. When merging an Inquiry into an existing Case, do not rely on the merge workflow to update existing Case Custom Fields or other Case metadata. Review important Inquiry values during the merge and manually capture anything that should remain directly visible on the Case. #### Evidence Custom Fields Evidence Custom Fields capture additional structured information about the individual Evidence Items included with the Inquiry. When selected Evidence is carried forward during the Create Case or Merge Inquiry workflow, its supported Evidence Custom Field values carry forward with the resulting Evidence Item. This allows information collected about a device, account, data source, or other item during intake to remain associated with that Evidence Item as it moves into active casework. Unlike Inquiry-to-Case field mapping, Evidence Custom Fields remain associated with the Evidence Item itself. #### Relay Custom Fields When Relay is used for request intake, enabled Inquiry and Evidence Custom Fields can be presented directly to the requestor as part of the submission process. This allows your organization to collect structured information before the request reaches the forensic team. See [**Custom Field Options**](/monolith/relay-request-portal/relay-overview/relay-administration/custom-field-options.md) for information about enabling Inquiry and Evidence Custom Fields in Relay and mapping Inquiry fields to Case fields. ### Inquiry Status Inquiry Status provides a simple way to communicate where a request stands during the intake and triage process. Available statuses include: * **New** * **Contacted** * **Accepted** * **Declined** * **Converted** * **Merged** * **Transferred** These statuses are separate from Case Status and are intended to help manage the Inquiry before or as it transitions into active casework. #### New Use **New** for a request that has entered the Inquiry queue and still needs review. #### Contacted Use **Contacted** when your team has reached out for clarification, additional information, evidence delivery, or another follow-up. #### Accepted **Accepted** indicates that your team intends to proceed with the request. Accepting an Inquiry does not create a Case. This allows the Inquiry to remain in the triage process while your team waits for physical evidence, additional information, authorization, or another requirement before active casework begins. #### Declined Use **Declined** when the requested work will not move forward. #### Converted **Converted** identifies an Inquiry that has been used to create a new Case. #### Merged **Merged** identifies an Inquiry that has been merged into an existing Case. #### Transferred **Transferred** is available for workflows where the Inquiry has been transferred as part of the intake or triage process. How this status is used may depend on your organization's workflow. ### Create a New Case From an Inquiry When the request is ready to become active casework, select **Create Case** from the Inquiry. Because this workflow creates a new Case, Monolith can use information from the Inquiry to initialize the Case record. Depending on the Inquiry and your configuration, information carried forward can include: * Case Name * Case Type * Case Description * Client information * Selected Evidence * Selected Documents * Selected Contacts * Mapped Inquiry Custom Field values * Other supported request metadata This preserves information collected during intake and reduces the need to manually recreate the request inside Monolith. After the Case is created, the Inquiry is marked **Converted**. See **Cases** for information about managing the resulting Case and its related work. ### Merge an Inquiry Into an Existing Case If the requested work belongs to a Case that already exists, select **Merge Inquiry** instead of creating another Case. The Merge workflow is designed to add selected related records to the existing Case while preserving the Case's current metadata. During the merge, users can carry forward supported records such as: * Evidence * Documents * Contacts Monolith also links the Inquiry to the existing Case. Unlike **Create Case**, Merge Inquiry does not overwrite or append existing Case-level information such as: * Case Name * Case Description * Case Type * Case Status * Case Lead or assignments * Case-level Custom Fields * Other existing Case metadata This is useful when multiple requests or supplemental submissions belong to the same Case and the existing Case record should remain intact. #### Review Important Inquiry Information Before Merging Before completing a merge, review the Inquiry for information that should remain part of the active Case record. For example, consider whether the Inquiry contains: * Important request narrative * Operational or investigative context * Inquiry Custom Field values * Supplemental instructions * Other information needed for reporting or future Case review If that information should remain visible directly within the Case, add it to the appropriate Case Description, Case Note, Custom Field, File, or other Case record as part of your workflow. After the merge is completed, the Inquiry is marked **Merged**. ### Relay-Originated Inquiries When an Inquiry originates from Relay, Monolith preserves the relationship to the original Relay request. Changes to Inquiry Status can be reflected back to the requestor in Relay. If additional communication is needed, request-specific comments and @mentions are handled in **Relay** rather than directly from the Monolith Inquiry. A Monolith user who needs to participate in Relay comments must also have an appropriate Relay account. Once the Inquiry becomes a Case, supported Case and Evidence progress information can be made visible to the requestor through Relay. See **Managing Relay Requests in Monolith** for additional guidance. ### Inquiries as an Integration Point The Inquiry workflow can also serve as the intake boundary between Monolith and another system. An organization may already have an established request process, internal application, ticketing system, or other intake workflow. The **Inquiries API** provides a way for those systems to send structured requests into Monolith while preserving the Inquiry review and triage process. A common integration model might look like: ``` Existing Request System ↓ Inquiries API ↓ Inquiry ↓ Review / Triage ↓ Create or Merge Case ``` This allows Monolith to become the system used for forensic casework without requiring users to manually re-enter information that already exists elsewhere. ### Editing and Deleting Inquiries Inquiry information can be edited when additional details are received or existing information needs to be corrected. Users with the appropriate permissions can also delete an Inquiry. {% hint style="warning" %} Review the Inquiry and its relationship to any Relay request before deleting it. Deleting the Inquiry in Monolith should not be treated as a method for removing or cleaning up the corresponding request in Relay. {% endhint %} ### Recommended Practices * Use Inquiries as a triage layer when work should be reviewed before becoming an active Case. * Capture enough information during intake for the team to understand what is being requested. * Use structured Evidence, Contacts, Documents, and Custom Fields instead of relying only on a free-text description. * Use Inquiry Status consistently so users can quickly understand where requests stand. * Use **Accepted** when the work will proceed but is not yet ready for Case creation. * Create a new Case when the request represents new casework. * Merge the Inquiry when the work belongs to an existing Case. * Preserve useful information collected during intake by carrying it into the resulting Case. * Use Relay when your organization wants an out-of-the-box request portal and requestor experience. * Consider the Inquiries API when Monolith needs to connect with an existing request or intake system. ### Related Documentation * [**Case Management**](/monolith/using-monolith/case-management.md) * [**Cases**](/monolith/using-monolith/case-management/cases.md) * [**Evidence Items**](/monolith/using-monolith/evidence-management/evidence-items.md) * [**Clients**](/monolith/using-monolith/people/clients.md) * [**Contacts**](/monolith/using-monolith/people/contacts.md) * [**Relay Overview**](/monolith/relay-request-portal/relay-overview.md) * [**Managing Relay Requests in Monolith**](/monolith/relay-request-portal/relay-overview/managing-relay-requests-in-monolith.md) * [**Custom Field Options**](/monolith/relay-request-portal/relay-overview/relay-administration/custom-field-options.md) * [**Inquiries API**](/monolith/monolith-api-and-webhooks/inquiries-api.md)