> 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/monolith-features/people/clients.md).

# Clients

Clients represent the requestors associated with work performed in Monolith.

A client can be selected or created during case creation, added or changed later by editing the case, or carried into a case from a Relay request. Monolith maintains these client records in **People > Clients**, where your team can search, review, import, and reuse clients across future cases.

This allows the relationship between the requestor and the work performed for them to remain part of the case record over time.

### Clients and Case Creation

Selecting a client is part of the normal case creation workflow in Monolith.

When creating a case, the **Client** field allows you to:

* Search for and select an existing client
* Create a new client without leaving the case creation form
* Leave the client blank and add one later by editing the case

You do not need to create clients in advance before beginning casework.

If the appropriate client already exists, select them from the searchable client list. If they do not exist, select **Create New Client** and create the client as part of the case creation process.

This allows the client and case relationship to be established without interrupting the intake workflow.

<figure><img src="/files/6RmTZsdCZtCv7QWx2yyW" alt=""><figcaption><p>Create Client</p></figcaption></figure>

### Add or Change a Client Later

A client does not have to be selected when the case is first created.

If the requestor is not yet known, or the case was created before all intake information was available, edit the case later and select or create the appropriate client.

This can also be useful when correcting or updating the requestor associated with a case.

### Clients From Relay

Relay provides another common path for clients to enter the Monolith workflow.

A typical Relay workflow is:

1. A requestor submits a request through Relay.
2. The request appears in Monolith as an **Inquiry**.
3. Your team reviews the inquiry.
4. The inquiry is used to create a new case or merge information into an existing case.
5. The requestor from the inquiry is associated with the resulting Monolith case as the client.

This allows requestor information collected during intake to carry forward into the case without requiring your team to manually recreate it.

For more information, see the **Relay Request Portal** documentation.

### People > Clients

**People > Clients** is the global client directory for your Monolith environment.

Clients created during case creation, received through supported workflows, imported through integrations, or added programmatically through the API become part of this reusable client list.

Use **People > Clients** to:

* Search and review existing clients
* Create clients outside of a case when needed
* Update client information
* Review organization information
* Review cases associated with a client
* Find repeat requestors
* Import clients from supported directory integrations
* Maintain a consistent client directory for future case creation

When a client already exists in this directory, that client becomes available in the searchable **Client** field when creating or editing a case.

<figure><img src="/files/Pvb7CI3OjIyf3sGGhtIM" alt=""><figcaption><p>Clients Table</p></figcaption></figure>

{% hint style="info" %}
You do not need to populate the client directory before using Monolith. Clients can be created naturally as cases and requests are received, while the global Clients area provides a central place to manage those records over time.
{% endhint %}

### Client Information

Client records can be used to preserve useful requestor information such as:

* Name
* Email address
* Phone information
* Organization
* Address
* City
* State or province
* Postal code
* Client or requestor type
* Notes or other relevant information

Maintaining consistent client information makes it easier to identify repeat requestors and understand the history of work associated with a person or organization.

<figure><img src="/files/1Cm7v14bZxhZf6v2rCcs" alt=""><figcaption><p>Client Page</p></figcaption></figure>

### Associated Cases

A client record also provides access to the cases associated with that requestor.

This is especially useful when working with repeat clients or reviewing the history of work performed for a particular person or organization.

Two case views are available:

* **My Associated Cases** — Shows cases associated with the client that you are assigned to as a user.
* **All Associated Cases** — Provides an administrative view of all cases associated with the client.

The associated cases table can help answer questions such as:

* How many cases has this client submitted?
* What work has previously been performed for this requestor?
* Which cases from this client am I currently assigned to?
* How frequently does this person or organization request work?

This history becomes increasingly useful as your organization builds more case and client data in Monolith.

<figure><img src="/files/FZ5STYRV9HNexdOGkMgC" alt=""><figcaption><p>Associated Cases views</p></figcaption></figure>

### Printing Client Labels

Client information can also be used with Monolith's custom label system.

From the client detail page, use **Print Label** to select an available label template and print a label using information from that client record.

The information displayed on the printed label depends on the selected template and the client variables configured within it.

For more information about creating custom labels and the available client variables, see **Item Labels**.

<figure><img src="/files/37wHkNBklRiN5rJL0pCO" alt="" width="375"><figcaption></figcaption></figure>

### Organizations and Repeat Requestors

Client records become increasingly useful as your organization builds case history in Monolith.

For example, your team may regularly receive requests from **ABC Law** with several different requestors at that organization.

From the Clients area, you can use filtering and the associated case information to answer questions such as:

* How many requestors do we work with at ABC Law?
* Which clients are associated with that organization?
* How many cases has a particular requestor submitted?
* Which cases are associated with a specific client?
* How frequently are we receiving work from a particular organization?

For example, filtering clients by organization may show three requestors from the same firm, while opening one of those client records may show that the individual is associated with ten cases.

This makes the Clients area useful not only for case intake, but also for understanding the relationships and request history your organization has built over time.

### Import Clients From Microsoft 365 or Google Workspace

Organizations using Microsoft 365 or Google Workspace can configure directory integrations to help populate the Monolith client directory at scale.

Supported directory integrations include:

* **Microsoft 365 Admin**
* **Google Workspace Admin**

These integrations are configured from **Settings > Integrations**.

Once configured, the client import functionality in **People > Clients** can use information from the connected directory to bring selected users into the Monolith client list.

This can be particularly useful when your organization has a known group of internal requestors that should already be available for selection when cases are created.

For example, instead of creating twenty internal requestors individually as new cases arrive, an administrator can import those users into the global client directory. They will then appear in the searchable Client field during case creation.

{% hint style="info" %}
Directory import is optional. Many organizations simply create clients as requests and cases are received. Integrations provide an additional option when maintaining a larger known group of requestors in advance is useful.
{% endhint %}

### Clients API

Clients can also be created and managed programmatically through the Monolith API.

The API provides another way to add records to the global client directory and can be useful when integrating Monolith with another system or automating client management.

Clients created through the API become available for use throughout Monolith just like clients created through the application.

See **Clients API** for available endpoints and developer documentation.

### Clients vs. Contacts

Clients and Contacts both store information about people, but they represent different relationships to your work.

**Clients** generally represent the requestor associated with a case.

**Contacts** represent other people connected to the case, evidence, acquisitions, or related forensic work.

For example, a case might include:

* An investigator as the **Client** who requested the examination
* A device owner as a **Contact**
* A suspect as a **Contact**
* A victim as a **Contact**
* A custodian as a **Contact**
* An attorney as a **Contact**

Contacts can be associated with cases, evidence items, and acquisitions as needed.

See **Contacts** for more information.

### Clients and Reporting

Maintaining accurate client information helps preserve the requestor relationship throughout the lifecycle of a case.

Client information can be used when reviewing case history and can also be included where applicable in Monolith case reporting.

Keeping client and organization information consistent helps ensure that the requestor information associated with a case remains useful when the work is reviewed or reported later.

### Best Practices

* Create or select the client as part of case intake when the requestor is known.
* Add the client later if the information is not available when the case is created.
* Search for an existing client before creating a duplicate record.
* Reuse the same client record when a repeat requestor submits additional cases.
* Keep organization names consistent so filtering and review remain useful.
* Use Clients for requestors and Contacts for other people related to the case.
* Use Microsoft 365 or Google Workspace imports when maintaining a larger known requestor population is helpful.
* Use the Clients API when client creation or management needs to be integrated with another system.

### Delete a Client

Administrators can delete a client from the client detail page when the record is no longer needed.

To delete a client:

1. Open the client from **People > Clients**.
2. Select **Delete**.
3. Review the confirmation message.
4. Confirm **Delete Client**.

{% hint style="warning" %}
Deleting a client cannot be undone. Confirm that you have selected the correct client before completing the action.
{% endhint %}

<figure><img src="/files/P5eWl4gIQwSwwLYlXEhQ" alt=""><figcaption><p>Delete Client</p></figcaption></figure>

### Related Documentation

* **Cases**
* **Contacts**
* **Relay Request Portal**
* **Microsoft 365 Integration**
* **Google Workspace Integration**
* **Monolith Case Reports**
* **Clients API**
