Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Monolith can be accessed in two ways: Web Browser and Monolith Desktop.
Monolith can be accessed from web browsers such as Google Chrome, Firefox, and Microsoft Edge via one of the following URLs:
Note: All new trials start in the US/NA Monolith server, so if you are trialing Monolith from Europe, you should use the US/NA server. Once you become a customer, we will deploy your Monolith tenant to our UK server.
Monolith be used as a desktop application called "Monolith Desktop". This app can be installed on MacOS and Windows Operating Systems.
You can download Monolith Desktop here:
Default Monolith deployments store files on the local file system of the host that is running Monolith's Docker containers.
If you want to use an external file share, you will need to adjust the docker-compose.yml file to include configuration settings for the file share you would like to use.
To connect to a basic Windows file share, add the following configuration to the bottom of your docker-compose.yml file:
Replace your_username
, your_password
, your_domain
with the appropriate credentials for accessing the CIFS share. your_domain
is not required if your share does not have a specific domain, so you can omit this value.
Replace //<SHARE_IP_ADDRESS>/share
with the network path to your CIFS share, but append the "/data" location at the end.
To utilize this new volume, we need adjust the current volumes listed in each service block of the docker-compose.yml file.
The following demonstrates the final docker-compose.yml file once a CIFS share has been configured:
When first logging into Monolith, here are the first steps you should take to get Monolith ready for your forensic work and evidence:
Setup your Organization Info.
Create user accounts for your team.
Set the formatting for case numbers, evidence numbers, & storage numbers.
Create & Customize form selection options:
Customize your Case Type selections.
Customize your Case Status selections.
Customize your Case Progress selections.
Customize Evidence Type Selections.
Customize Evidence Progress selections.
Customize Time Entry Categories to use with the Task Management System.
Customize Quality Assurance Issue Type selections.
Create and customize Quality Assurance checklists.
Create and upload evidence & storage labels with DYMO.
Create evidence locations.
Enter existing storage items.
Enter Forensic software.
Monolith can be deployed on-premises and in your IT environment
Monolith is licensed on a per user per year basis.
Pricing information for Monolith can be found here: Pricing Page
When you purchase Monolith - your purchase includes a limit on how many active users you can have at any one time.
For Example: If you purchase Monolith with 5 active users, this means that you can have 5 active user accounts in Monolith. The users associated with these accounts can log into Monolith from anywhere and from as many different devices as they want.
Inactive users will not be able to access Monolith.
Account sharing is not allowed in our licensing terms, however, exceptions to this rule can be made on a case-by-case basis.
If you choose not to renew your Monolith subscription, your Monolith access will revert to "Read-Only" mode. You will still have access to your Monolith data, but you will no longer be able to add new data or edit current data.
Your data will remain in Monolith for up to a year, after a year, we may permanently destroy any data still stored within our servers.
An export of your data in Monolith can be requested at any time by making a request to support@monolithforensics.com.
The data export will consist of a SQL dump file and a ZIP file that contains files uploaded to Monolith.
Please allow up to 2 weeks to receive your data export.
Once you have purchased Monolith and are ready to deploy - you will be provided with a Monolith On-premises deployment package. This package will contain configuration files necessary to run the deployment.
The package will contain the following items:
.env
This is an environment file that will contain variables that are injected into your Monolith deployment at run time. This is where your licensing information will be location along with other settings.
docker-compose.yml
This is a Docker deployment configuration file. This file dictates how the various Monolith containers will be built and deployed.
This allows you to use a pre-defined configuration so that you don't need to build the Monolith Docker deployment from scratch.
init folder
This contains additional configuration files needed for successful deployment.
There are a couple of steps to setup Monolith Desktop.
To download Monolith Desktop, go to the System section of the settings page and download the appropriate installer for you operating system (Windows or MacOS)
After installing Monolith Desktop and running it for the first time, you will be presented with an "API Mode" selection screen.
This screen allows you to connect Monolith Desktop to your Monolith Tenant, whether it is in the Cloud or On-premises:
For cloud hosted Monolith Tenants/Customers - keep the default selection as "Cloud". The region is defaulted to US/North America, but if you are a UK customer, change the region to "United Kingdom" and select submit.
This option ensures that Monolith Desktop will connect to the correct Monolith Server for your cloud deployment or region.
Additional Cloud regions may be added in the future.
For on premises customers - change the "API Mode" to "On-Premises". This mode allows Monolith to connect to an on-premises Monolith server that is running within your organization and network.
When you select the On-Premises option, you then need to enter your Monolith Server's API endpoint. This will typically be the IP address of your Monolith server, or a custom domain if you have one setup in your network.
The API endpoint must meet the following formats:
If Monolith Desktop can successfully reach the Monolith server, you will see a green check mark populate and the Monolith Login screen will load.
To reset Monolith's API connection settings, click the "Reset Monolith" button located on the Monolith Login screen. This will return you to the API mode selection.
You can log into Monolith using your account email and password.
By default, all cloud users are required to use 2-Factor Authentication to login to their Monolith accounts. Monolith utilizes TOTP based 2FA, which means that users must have an authenticator application to use 2FA with Monolith. The following authenticator apps are recommended:
Google Authenticator
Microsoft Authenticator
On you first login to Monolith, you will be prompted to setup 2FA with the authenticator app of your choice. Open the authenticator app and scan the QR code presented by Monolith:
Once you have scanned the QR code, type in the 6-digit code generated by the authenticator app into the box at the Monolith Login screen.
For subsequent logins, you will be presented with a 2FA screen and asked to enter a 6-digit code generated by you authenticator application of choice.
If you have lost your 2FA device or replaced it, a Monolith admin user can reset the 2FA device on your account. Once reset, Monolith will prompt you to connect a new 2FA device at your next login.
For cloud customers, you can request that 2FA be disabled for your account - please make a request to support@monolithforesics.com.
For on-premises customers, you can disable 2FA from your user profile page.
2FA is a very important and standard security measure - we highly recommend you do not disable this feature.
Webinars every Wednesday at 10 AM CT!
Office hours are a weekly webinar hosted by Monolith Forensics owner and founder Matt Danner.
Feel free to join to ask questions, get some training, or request a demo of Monolith or specific feature.
The webinar is conducted over Zoom - you can register at this link:
Log into Monolith using your organization's Single Sign On provider.
If your organization has purchased and setup SSO with Monolith, you will be able to log in with your SSO account.
When you type your email into the Monolith Login screen, Monolith checks your email domain and resolves it to your SSO provider. When you click the "Log In" button, you will be redirected to your SSO provider to authenticate. After authentication, you will then be redirected back to Monolith and given access to your Monolith Tenant.
These variables represent data contained within a report instance of a case.
Currently, the summary and analysis variables do not include any rich text formatting like bold, bullets, or underline. Pasted images are also not included in the template when generated.
These are template variables that reference your organization information entered into Monolith.
These are variables that reference the currently logged in Monolith user.
These are variables that contain data related to the current case you are generated a report for.
These are variables that contain data related to evidence items within a case.
Remember - the evidence object within a template is a list of evidence items. To use this data in a template, The values must be inside a loop:
Evidence photos are stored in an array/list and must be referenced within for loop syntax.
These are variables that contain data related to acquisition items within a case.
Remember - the acquisitions object within a template is a list of acquisition records. To use this data in a template, The values must be inside a loop:
How to manage your on-premises licensing for Monolith
Currently, your on-premises license to Monolith is managed within the ".env" file that is within your Monolith package deployment folder.
There are two values within the ".env" file that related to your Monolith License:
When the Monolith server starts up, it derives your license from one of these two values.
When both values are present, the MONOLITH_LICENSE_TOKEN value takes precedence.
The Monolith license token is a long string that is a securely signed token that contains your licensing information.
This method works in both online and offline environments and does not use the internet to operate.
The Monolith server derives your license details from this token.
This is the preferred method, because it does not rely on our licensing server to work and will keep your Monolith deployment operational even during internet outages.
A license token must be provided to you from Monolith support. These tokens expire on your annual renewal date and must be refreshed each year. Contact support@monolithforensics.com to get a new token.
The Monolith license key is a short, unique string that is associated with your Monolith customer account. Monolith uses this value to retrieve your licensing information from our online licensing server on the internet.
This licensing method will not work in air-gapped environments
To update your license, simply replace the License key or token value in your ".env" file with a new one and restart your Monolith Docker deployment.
You can restart your Monolith Docker deployment with the following commands:
Be sure to run these commands from the same directory as your ".env" file and "docker-compose.yml" file
Monolith utilizes Docker for on-premises deployments
Docker is a platform that uses OS-level virtualization to deliver software in packages called "containers". Docker is used to deploy, manage, and run containers within a variety of environments.
Monolith is deployed in on-premises environments using containers and Docker is recommended as the container management system to run and manage Monolith.
Monolith runs in a server-client configuration where users access and manage data via the Monolith desktop client or web application. A Monolith API server runs on a centralized host and handles HTTP requests from the desktop clients and web application. The API server communicates with a database to create, update, delete, and read data from the database.
The image above illustrates the basic setup of containers within an on-premises deployment. The containerized nature of Monolith allows for flexible and scalable on-premises deployment options.
This is a web server container that handles incoming requests from clients and proxies traffic to one of 3 containers: Monolith Web App,Monolith API, or the Relay App. This container can be configured to include custom domain TLS certificates.
This is the Monolith web application that can be access via a web browser. To access this application, you just need to navigate to the host system IP address or assigned domain name in a web browser - Ex: https://192.168.1.12
This container hosts an API server that can send authenticated requests for data to and from the Monolith and Relay web applications. This container connects directly to the MySQL server to store data and a file system to store files uploaded to Monolith.
The Relay app container runs the Relay application. Relay is a web-based request system that allows non-monolith users to submit requests for forensic services.
This container runs a MySQL database that stores data accessed and managed by users of Monolith and Relay. The MySQL database does not have to be a container inside Docker. You can use an external hosted MySQL database if you wish.
This is not a container, it represents your chosen file system component to store files that are uploaded to Monolith and Relay. This can be the file system on the host system, AWS S3 object storage, or a network file share.
Watchtower is an optional container that manages automatic updates for the other containers. Watchtower checks for container updates every 30 seconds. When an update is available, Watchtower downloads the new container images and replaces the current containers with new containers built from the updates container images.
This is an environment variables file that is loaded into the Monolith Docker deployment at build/run time. These values determine various setup options and licensing information for your Monolith deployment.
The values are typically set for you when you purchase Monolith.
This is a license key that allows for your Monolith deployment to get licensing information from our online license server. Using this value ensures that your Monolith deployment always has up to date license info.
This key will be provided to you upon purchase.
This is a signed token that contains licensing information for your Monolith purchase. This can be used to utilize cached license info without needed to query our licensing server for license info.
This is a good option for Monolith deployments that exist in air-gapped environments.
If this value is provided, Monolith will use this instead of the license key value.
This should be a long alphanumeric string. This value is used for various cryptographic operations related to access tokens, encryption, and session management.
This should be a long alphanumeric string. This value is used for various cryptographic operations related to access tokens, encryption, and session management.
This is the name of the MySQL schema that the Monolith API server should connect to.
This is the domain or IP address of the MySQL database host that the Monolith API server should connect to.
This is the MySQL user name that should be used for database connections.
NOTE: This should only be root if you are using the default MySQL container. If using an external MySQL database, you should provision a user account other than root to use here.
The port that should be used for database connections. The default MySQL port is 3306.
MySQL password used to establish database connections.
First name of initial Monolith user. Only required for first time setup/deployment.
Last name of initial Monolith user. Only required for first time setup/deployment.
Email of initial Monolith user. Only required for first time setup/deployment.
Password of initial Monolith user - this will be used for firs time login to Monolith. Only required for first time setup/deployment.
Initial tenant name for your Relay deployment. Only required for first time setup/deployment.
Organization name for your Relay deployment. Only required for first time setup/deployment.
URL slug for your Relay deployment. Only required for first time setup/deployment.
Initial tenant email for your Relay deployment. Only required for first time setup/deployment.
The Monolith API server runs in "cluster" mode. This allows multiple instances to run at the same time, which increases scalability. This value defaults to 1 and is disabled by default. You will likely not need to use this value, but contact support if you think this is needed.
This value determines whether Monolith will use a local file system or Amazon S3 to store Monolith files. Allowed values are "S3" or "Local". The default value is "Local". If you set this to "S3", you will also need to set the S3 access key values.
This value configures Monolith to use the correct AWS region with your S3 bucket.
The S3 bucket where you would like to store files uploaded to Relay.
The S3 bucket where you would like to store files uploaded to Monolith.
AWS access key to use S3 APIs for file storage.
AWS secret key to use S3 APIs for file storage.
Email host domain to enable email capabilities in Monolith.
Email port to enable email capabilities in Monolith. This value is typically 587.
User value to enable email capabilities in Monolith. May not be required if you are using an SMTP relay.
User password to enable email capabilities in Monolith. May not be required if using an SMTP relay.
Docker configuration and deployment file
This file is used to define the deployment options for the various Docker containers that make up the Monolith on-premises deployment.
Unless you require an advanced deployment, you will not need to modify this file.
Note: Indentation matters in this file - if the indentation is not set properly, you may see errors when trying to deploy Monolith.
This file is used with the following commands to build, re-build, and remove the containers that run Monolith.
Variable Name | Description |
---|
Variable Name | Description |
---|
Variable Name | Description |
---|
Variable Name | Type | Description |
---|
Variable Name | Type | Description |
---|
Variable Name | Type | Description |
---|
| This is the report summary data that was entered into the summary tab of a Monolith case report. |
| This is the analysis data that was entered into the analysis tab of a Monolith case report. |
| This is the name of your report instance. |
| Name of your agency, company, or organization. |
| Street address of organization. |
| City location of your organization. |
| State or province of your organization |
| Postal code of your organization |
| Email set for your organization. |
| Website URL set for your organization. |
| First Name of user. (Jane) |
| Last name of user. (Doe) |
| First name and last name combined. (Jane Doe) |
| User email address. |
| User title set in Monolith. |
| Office location that the user is assigned to. |
| Integer based user id stored by Monolith. |
| Number | Integer based, unique id set by Monolith for the case. |
| String | String based, unique id set by Monolith for the case. |
| String | Case number for the case. |
| String | Case name/reference set for the case. |
| Date | Case open date in the format "YYYY-MM-DD". |
| Date | Case closed date in the format "YYYY-MM-DD". |
| Date | Case last activity date in the format "YYYY-MM-DD". |
| String | Current status of case. |
| String | Current case type. |
| String | Current progress status of case. |
| String | Description of the current case. |
| {user_id, first_name, last_name, full_name, email, title} | Properties related to the user assigned as a case lead. |
| {name, value} | Case custom field value - replace 'id' with custom field id number. |
| Number | Unique ID of evidence |
| String | Unique ID of evidence |
| String | Item evidence number |
| String | Type of evidence |
| String | Service provider/manufacturer |
| String | Item name |
| Number | Size of item |
| String | Size units: KB, MB, GB, TB |
| Number | Size of item |
| String | Size units: KB, MB, GB, TB |
| String | Description of item |
| String | Progress status of item |
| Timestamp | Creation Timestamp |
| String | Name of linked contact |
| [{name, image}] | Array/list of evidence photos |
| {name, value} | Custom field value - ID is a number that uniquely identifies a custom field. |
| Number | Unique ID of item. |
| String | Unique ID of item. |
| String | Name of item. |
| String | Description of item. |
| Number | Size of item in numbers. |
| String | Units of item size: KB,MB,GB,TB. |
| String | Format of acquisition Ex. E01, DD, ZIP. |
| String | Type of acquisition: Ex. File System, Physical, Chip-off. |
| String | Active or Deleted. |
| Date | Date of acquistion. |
| Date | Date of record creation. |
| {full_name, user_id, email, title} | The user that acquired this data. |
| {name, contact_id} | The person that this acquisition is associated with. |
| {evidence_id, uuid, evidence_number} | Evidence linked to acquisition. |
| {name, version} | Software uses to create acquisition. |
| {storage_id, uuid, storage_number} | Storage item where acquisition is stored. |
| {hours, mins} | Time spent creating acquisition. |
| {name, value} | Custom Field Value |
These commands can be used together to conduct a "hard" restart of Monolith.
Restarting Monolith in this way does not cause any data loss and should be used when you need to update your licensing from a license token.
Additional Docker commands can be reviewed on Dockers official documentation pages:
https://docs.docker.com/engine/reference/run/
Additional Docker compose commands can be reviewed on Docker's official documentations pages:
These are the basic requirements for hosted Monolith on-premises
Docker or Docker Desktop is required for Monolith on-premises deployments. Installation instructions can be found here.
The following hardware is required to properly run the Monolith API backend within Docker:
Microsoft Windows 10/11, MacOS, or Ubuntu 20 system
4GB of RAM
2-core CPU
At least 100 GB of storage (>500 GB recommended)
Monolith is not currently supported for Windows Server operating systems. This is due to lack of support for Docker installation on Windows Server.
To enable Monolith’s email capabilities, an email account is required with SMTP credentials:
SMTP host
SMTP port
SMTP user
SMTP password
These values are supplied to the Monolith API server/Docker container at run-time.
If you want to store Monolith files in AWS S3, you will need to have the following to integrate S3:
AWS Access Key
AWS Secret Key
AWS Region & Endpoint
This section will cover restoring a database backup of your Monolith MySQL database.
This restore process assumes you have previously created a SQL dump of your Monlith databse from MySQL. A SQL dump file is a plain text file that contains your database data in a SQL format.
MySQL has a concept called "schemas". Schemas are the data segements within MySQL that store tables and data. You can have any number of schemas within a MySQL database. Your Monolith data is stored within a single schema within MySQL.
Schemas are the data object that we will backup and restore from backups.
Recommended Tools:
MySQL Workbench
This is a free tool provided by the MySQL team to access and manage MySQL databases. It also has several useful utilities including database backup and backup import services.
Open MySQL Workbench
Ensure that Workbench has a connection to your Monolith database.
Open your Monolith database in MySQL workbench.
Select "Server >> Data Import" from the Workbench menu bar.
The import wizard should start at the "Import from Disk" tab - select this tab if its not selected.
Under "Import Options", check the radio button for "Import from Self-Contained file".
Use the file select browser to locate and choose your Monolith database backup, which should have a ".sql" extension.
(Optional) Select a default target schema or create a new one.
This is optional because your SQL dump file likely already has a directive to create a new schema with the correct name.
Click the "Start Import" button.
This process will create a new "schema" and populate it with tables and data from your Monolith database backup.
If the new schema has a different name from your original Monolith schema (database), then you may need to update your Monolith deployment configuration.
These are the documented methods of installation for Docker
To Install Docker on Windows, you need to install Docker Desktop for Windows. This installer can be downloaded from here:
https://www.docker.com/products/docker-desktop/
To deploy Monolith on Windows, you will need to install the WSL package for Windows. This allows Windows to run Linux containers. During the Docker Desktop install, Docker typically prompts you to install this. If not, here is a direct link to download and install WSL:
https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi
To Install Docker on MacOS, you need to install Docker Desktop for MacOS. This installer can be downloaded from here:
https://www.docker.com/products/docker-desktop/
To install Docker on a Linux OS, refer to the following Docker documentation for Linux installations:
Monolith On-premises deployments do not include a native backup solution.
The customer is responsible for creating and managing backups for data stored in the Monolith deployment.
The customer should set up a backup system that creates backups of the "data" folder maintained by the Monolith server. A backup solution for the MySQL Monolith database should also be implemented. The MySQL backup process should create something similar to SQL dumps of the databases stored by Monolith in MySQL.
Deploying Monolith with the default configuration is a simple matter.
Install Docker - Instructions
Pick a location to store your on-premises package files.
Open a command terminal.
Navigate to the location of your Monolith On-premises package files.
This is the folder that contains the .env and docker-compose.yml files.
Run the following command to download, deploy, and run the Monolith containers referenced in the docker-compose.yml file:
docker compose up -d
This will download the Monolith container images which may take a few minutes.
Once downloaded, the containers will launch and build the initial Monolith system.
You can then navigate to Monolith in a web browser using the IP address of the host system running Monolith:
https://{host_server_ip}
To remove the docker containers, you can use the following command:
docker compose down
NOTE: If deploying Monolith inside of a virtual machine, you must enable "nested virtualization" for Docker to work.
Once deployed, Monolith will store data in a folder called "data". This folder contains log files, files uploaded to Monolith, files uploaded to Relay, and database files generated by MySQL.
This data folder is important to maintain and create backups as the data that you store in Monolith will reside in this location.
All of the standard tables in Monolith have several features to help users find and export data quickly.
To sort rows within a Monolith table, click the column header. Monolith will then sort the data based on that column.
Table columns can be resized by hovering over the edge of the column that you wish to resize. Then just click and drag the column to the desired width.
Columns can be reordered by clic and dragging the column header to the desired position in the table.
Columns can be hidden or shown by using the "Column Selector" which is a button that is typically located in the top right menu of a table. This button has an icon that looks like 3 vertical columns.
Most tables in Monolith are "paginated" which means that only a certain number of records are loaded at one time. The default is 20, but you can use the page size selector to increase that amount to 100.
The table may also have a Page Selector that allows you to navigate to specific pages within the table data.
Table data may be searched if there is a search box associated with it. To search the table data, just enter your search string into the text box and press enter.
Most tables can be exported to a Microsoft Excel document. to export the table data, use the table export button which is usually located in the top right table menu.
The table export is a "What you see is what you get" export, which means that the only columns and rows included in the export are based on the filters and table orientation.
All pages are included with the export.
When running MySQL in Docker or as a container, you may need to update the version of MySQL from time to time.
To update MySQL within Docker using Docker compose, you need to update your "docker-compose.yml" file.
Find this line in the MySQL block:
Update the MySQL version in this line to the next version:
This will tell Docker which version of MySQL to use when deploying Monolith.
Redeploy Monolith using the standard Docker compose command syntax:
This will stop the current Monolith deployment and restart it fresh containers. You should see the new version of MySQL download as a Docker image during this process.
Once redeployed, MySQL will go through a breif process of updating itself that may last a minute or two, so it may take a minute or two for Monolith to be available for use.
After completing steps 1 and 2, you should have a new version of MySQL installed and deployed for use with your Monolith deployment.
To use an external database instead of using the MySQL Docker container that is included with the default Monolith deployment, just set the following values in the .env file to the connection details for your external MySQL database:
If you have deployed Monolith with the Watchtower container, the Monolith API server, Monolith web app, and Relay web app will automatically update if the host system has internet access.
Watchtower checks for updates to these container every 30 seconds.
You may disable these automatic updates by simply removing the Watchtower container from your Monolith deployment.
If you don't want to wait for Watchtower or if you want to buld updates into a recurring script, you can force an update with a couple of commands.
The following commands use Docker compose to pull down the latest Monolith images, and rebuild the entire Monolith deployment with the new images.
Be sure to run these commands from the same directory as your Monolith docker-compose.yml file.
You can imbed these commands within a bash or batch script if you would like to implement your own scheduled updates instead of using watchtower.
You can also update the Monolith server containers manually. This can be useful in air-gapped environments or if you do not wish to deploy with automatic updates.
Run the following commands to download the latest container images for Monolith deployment or updates:
Run the following commands to export the container images to TAR files that can be transferred to the the host running the Monolith server:
You can now transfer these TAR files to the host system that runs your Monolith deployment.
To import the TAR files, run the following commands on the host system that is using Docker to deploy the Monolith containers:
To restart Monolith with the new containers, run the following commands on your Monolith host and from the directory that includes your docker-compose.yml file:
Filtering a table is handled by the Monolith Query Filter, which is discussed .
Monolith supports integration with various hardware devices such as Signature pads, USB barcode scanners, and Dymo Label Printers
Single sign on is an authentication process that allows a user to log into Monolith using thier organization's authentication mechanism and identity management system. This authentication process is used in place of Monolith's default login system.
For example, if configured, a user may login into Monolith using Microsoft Azure AD credentials instead of using the default Monolith user credentials.
SSO integration with Monolith uses the SAML 2.0 open standard to connect to your identity provider.
Identity and service provider are common terms used when configuring an SSO connection. The identity provider is the service your organization uses to manage it's employees' credentials to provide access to IT resources.
The service provider is the vendor or software that relies on the identiity provider ro authentication and identification.
In this case, Monolith is the service provider.
When logging in with SSO, the Monolith MFA process is not used - MFA is passed onto the identity provider that is used in the SSO process.
When a user authenticates into Monolith via SSO, a Monolith session is created that matches our default session standards.
To integrate SSO with Monolith, you must have purchased an Enterrpise license to Monolith.
In order to setup SSO with Monolith, your organization should provide a SAML metadata file that is in XML format. This metadata file will contain specific information related to the SSO connection with Monolith that we need for integration.
Monolith will then provide your organization with 2 key pieces of information to complete the SSO connection:
ACS URL:
https://monolith-app.monolithforensics.com/api/auth/saml/acs/{{UNIQUE ORG ID}}
Service Provider Entity ID:
https://monolith-app.monolithforensics.com/{{UNIQUE ORG ID}}
These values are used by your identity provider to create an SSO connection with Monolith.
In order for Monolith to properly identify the user after SSO authentication, we need the user's email to be included with the SAML response.
This is typically included as a "NameID", but may also be added as an "email" attribute.
To setup SSO with your Monolith account, please contact support: support@monolithforensics.com
The first step of configuring your DYMO printer with Monolith is to ensure you have the latest DYMO software installed on the machine that is using Monolith.
Latest versions of the DYMO software can be downloaded here.
MacOS:
After install, ensure that the DYMO.WebAPI.Mac.Host software is running in your menu bar (it is a small blue DYMO connect icon on the menu bar on the top of your screen.
If it is not running, find "DYMO.WebAPI.Mac.Host" in your Applications folder and launch the program.
Once running, when you go to print labels in Monolith you will see your DYMO printer as an available printing option.
When troubleshooting DYMO issues, we have found a complete uninstall and re-install fixes most issues. It's essential to remove all of the supporting files and certificates before re-installing the DYMO software.
Remove printer(s)
Open System Preferences > Printers & Scanners. Click the – button to remove the printer. (Do this for each DYMO printer shown)
Delete Application and Folder
Go to your Applications folder and delete all instances of DYMO applications
Open the Library/Extensions folder and Delete DYMOUsbPrinterClassDriver.kext, if found.
Open the Library/Frameworks folder and Delete the DYMO folder, if found.
Open the Library/LaunchAgents folder and Delete com.DYMO.dls.webservice.plist, if found.
Open the Library/LaunchDaemons folder and Delete com.DYMO.pnpd.plist, if found.
Open the Library/Printers folder and Delete the DYMO
Delete all DYMO Certificates from Keychain
Open the Utilities folder (Finder>Go>Applications>Utilities)
Double-Click Keychain Access to open keychain
Type “DYMO” in the search field on the upper right
Right-Click the certificate item (if found) and select Delete
Type “localhost” in the search field on the upper right
Click any item that appears and verify its properties show “issued by DYMO …” If so, then Right-Click and select Delete
After these steps are complete, re-install your DYMO software and try printing from Monolith.
All customers are assigned a Monolith "Tenant" - a tenant is a logical unit that separates every set of customer data into their own silos.
In Monolith, each customer is given thier own database and logical file storage area in our block storage. This means that data you enter into Monolith is not commingled with data from other customers.
The same idea applies to files uploaded into Monolith. Files stored in Monolith are stored in thier own logical silo based on the cutsomer tenant.
This Multi-tenant infrastructure also means that it is very easy to get a copy of your data - just make a support request!
All data stored in Monolith is encrypted at rest using AES-256 bit encryption algorithms. This includes data stored in databases, on servers, and in file object storage.
All data in transit to, from, or wihtin Monolith is also encrypted using HTTPS and TLS encryption standards/protocols.
While this data is encrypted, the encryption is controlled by us, which means a few select people from the Monolith team have access to customer data. This access is only granted for support and maintenance purposes.
Monolith has an internal Security Operations Policy and Data Management Policy that covers our internal standards in more detail. If you would like to see it, please submit a request to support.
Our Monolith infrastructure is currently hosted in AWS.
More specifically, we currently have 3 cloud infrastructure endpoints, which are all hosted on AWS: US East, London (UK), and Sydney (Australia)
Our United States endpoint is currently hosted in the AWS GovCloud East Region.
The AWS GovCloud infrastructure has some specific security policies in place that differs from normal AWS regions. These policies can be reviewed at the link below:
Monolith data within our databases is backed up every 24 hours. We keep a 30 days of backups which allows us to recover data from up to 30 days in the past.
We also typically create manual database backups for any major updates that require database maintenance.
These backups are stored in an encrypted format within a separate region from the current database. This allows for recovery of data in the event of an AWS region outage.
Files uploaded to our Object Storage system implement typical object storage versioning. This means that a deleted file can be recovered by restoring one of its versions. A new file version is created and stored in the event of a file overwrite, which can occur when a file with the same name and path of another file is uplaoded.
These file versions are kept for up to 90 days after deletion.
The following diagram illustrates the basic cloud infrastructure of the Monolith cloud environment. This is just an illustration to show how nodes communicate and share data/information:
The Monolith cloud infrastructure has network and system level scans that occur every 24 hours to test for network and system vulnerabilities. These scans produce reports that can be review for any issues or characteristics that are not inline with our security baseline.
All of our endpoints, including employee systems, are monitored using Crowdstrike Falcon. This provides continious 24/7 monitoring of our endpoints for threat detetion and allows for immediate remediation.
We conduct annual pentests of Monolith that test for common infrastructure vulnerabilities, configuration issues, and application vulnerabilities. These pentests are conducted by an independent 3rd party. The testing targets our development and staging environments and not the customer facing production system to avoid interrupting services and prevent any potential access to customer data.
Customer may request a copy of our latest pen test reports by contacting support at support@monolithforensics.com
Various system logs are currently managed by logging services within AWS and Datadog. These logs are currently aggregated within Datadog, which allows for periodic review.
The Query Filter is a system used throughout Monolith that allows you to create complex queries for data using a simple user interface.
The filter uses conditional logic to construct a query that will result in records that match the filter.
Example:
The above filter has three conditions:
Open Date is sometime after January 1, 2023
The Case Lead is Matt Danner
The Case Type is Consultation
This filter combines those three conditions into an "exclusive" filter, which means that a record must match all three conditions. This can also be referred to as an "AND" statement:
"Show me all cases WHERE the open date is after January 1, 2023 AND the case lead is Matt Danner AND the case type is Consultation."
The query filter options are defined based on the type of records that your are filtering. So case data will have different filter options from evidence data.
Each condition within the filter may have different options as well.
The following condition filters are available"
Date filters
Text Filters
Multi-select Filters
Monolith can be integrated with Topaz Signature tablets.
Topaz T-S460-HSB-R model signature pad
Other Topaz pads may work, but have not been tested.
You must install the Topaz SigWeb software on the host system to use this feature. You can download the software from the Topaz website: https://topazsystems.com/sdks/sigweb.html
This feature only works on Windows systems.
Monolith allows you to make use of report templates, so you can create any reports you wish based on data within a Monolith case.
The template document must be a Microsoft Word document (DOCX).
In order to use a template, you must insert placeholders that Monolith recognizes as case variables that can be replaced with case data:
Be mindful of the placement of spaces within the template syntax - spaces matter.
Here is standard syntax for inserting basic values into a template -
Please ensure that there is a space at the start and end of the variable name.
At the time of report generation, Monolith will replace this template variable with the chosen data from the case:
Some data in a Monolith case consists of a list of items. For example, you may want to reference data from evidence items associated with a case. You may have ten evidence items in a case and you want that evidence data to be included in your templated report.
To do this, we need to use some special syntax to loop through the list of evidence items and output each item's data into the template report.
Here is the basic syntax to loop through a list of items in a template document:
The above syntax will loop through a list of evidence items (stored in the "evidence" variable} and output a vertical list of evidence numbers.
Loops are a very powerful way to create complex report templates and display just about any data that you want.
There is special syntax used to iterate through table rows - similar to the looping syntax above, you may want to iterate through a list and create table rows with data.
Lets create a table that contains rows for each evidence item and columns for the evidence number and evidence provider (manufacturer, make, etc...)
Given the following evidence data passed to the template from a case:
Template Syntax for table -
Generated Document Result -
The "tr" prefix denotes that we are creating a loop through table rows.
You'll notice that the table rows that have the start loop syntax and end loop syntax are not included in the final rendered table.
Using this syntax you can create tables with templated lists pulled in from Monolith.
There is more syntax available for templates, but the item listed about are the most common. If you need help with this or have more questions, reach out to us at support@monolithforensics.com.
Monolith works exclusively with DYMO printers to print labels. Here are printer model recommendations:
Monolith works well with USB based scanners. Here is the scanner we recommend to use with Monolith.
Tera Pro 8100 Wireless Barcode Scanner
This scanner conectst via Bluetooth or USB dongle, works with Windows and MacOS, scans barcodes and QR codes, and has several other useful features.
This endpoint retrieves basic details about your Monolith tenant and the API key currently being used.
Use the endpoint as a quick test to ensure your call to the API is working.
GET
/api/v1/info
This endpoint retrieves basic details about your Monolith tenant and the API key currently being used.
No parameters are required for this API.
Response
Authenticating your API Requests
In order to submit an authenticated API request to the Monolith API, you need to include an API key in the following header value with the request.
This header must be present in all Monolith API HTTP requests and have a value that is a valid Monolith API key.
The Monolith API is still under development, so if you would like access, please reach out to support to request an API key.
Use the "info" endpoint to get details related to your API key. This example shows how to make a simple API request to Monolith using an API key in the headers of the request.
Documentation coming soon
GET
/api/v1/evidence/:uuid?
Retrieves a list of evidence items. Calling with no parameters returns a paginated list of all evidence items in your Monolith database. Use the uuid
query param to get details for one item or use the case_uuid
param to get a list of evidence items for one Monolith case.
Query Params
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|
uuid
String
Unique value that identifies a specific case.
uuid
String
Unique value that identifies a specific case. This value will take precedence over the UUID URL param if passed.
Monolith Desktop - MacOS Download
Monolith Desktop - Windows Download
| string | Monolith unique identifier for evidence item. |
| number | Monolith unique identifier for evidence item. |
| string | Monolith unique identifier for a Monolith case. |
| number | Monolith unique identifier for a Monolith case. |
| number | Unqiue identifier for a user. |
| number | Unique identifier for an evidence location. |
| ISO Date | Date that the evidence was entered into Monolith. |
| ISO Date | Evidence items that were created before this Date. |
| ISO Date | Evidence items that were created after this Date. |
| ISO Date | Evidence items that were created on this Date. |
| ISO Date | Evidence items that were created before this Date. |
| ISO Date | Evidence items that were created after this Date. |
| ISO Date | The initial intake date of the evidence. |
| ISO Date | Evidence items that were initially received before this Date. |
| ISO Date | Evidence items that were initially received after this Date. |
The following endpoints can be used to access the Monolith API
More regions will likely be added in the future.
Name | Type | Description |
---|---|---|
Region | Endpoint |
---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
uuid
string
Unique ID of the evidence to be updated. REQUIRED
evidence_number
string
Evidence number of the evidence being created.
item_name
string
Name of the evidence item.
type
string
The type of evidence item: (Smartphone, Server, Email, etc...)
provider
string
Service provider or manufacturer of evidence.
model_number
string
Evidence model number.
unique_id
string
Unique ID associated with the device - usually a serial number or account name.
size
number
Capacity of the evidence
size_unit
string
Unit of capacity: KB, MB, GB, TB, PB
description
string
Description of the item
United States/North America
https://monolith-app.monolithforensics.com/api/v1
United Kingdom
https://monolith-app.monolithforensics.co.uk/api/v1
case_name*
String
This is the name of the case.
case_number
String
Unique case number.
description
String
This is a basic description of the case.
case_status
String
This is the status of the case.
case_type
String
This is the type of case.
case_lead_id
Integer
This is the user id of the Monolith user you wish to set as the case lead for the case.
case_open_date
Date
The date the case was opened.
client_id
Integer
This is the id of the client that is associated with the case.
client_id
integer
Monolith unique identifier for the client.
created_on
ISO Date
Date that the client was entered into Monolith.
created_before
ISO Date
Clients that were created before this Date.
created_after
ISO Date
Clients that were created after this Date.
uuid
string
Unique ID of the evidence to be updated. REQUIRED
This section describes the basic access requirements for using the Monolith REST API via HTTPS.
Cases in Monolith are where you consolidate and manage evidence, tasks, documents, and other workflows when conducting forensic examinations.
Coming soon
To create a case in Monolith
POST
/api/v1/evidence
Use this API endpoint to create evidence items within Monolith.
Either case_id, case_uuid, or case_number is required.
If evidence_number is not provided, Monolith will automatically generate a value.
Request Body
To create custom fields for your evidence in an API request, you must include a custom_fields
value that consists of an array of JSON objects in the following form:
The field_id
is the numeric identifier for the custom field you are setting a value for.
These are the endpoints used by Monolith and Relay
These endpoints can be used to manage whitelisting for your firewall systems. These endpoints may be updated or we may add new entries over time.
Monolith uses HTTPS over TCP to access and transmit data. RESTful APIs are utilized that typically send and receive data in JSON format, Base64, or Form Data.
Monolith also uses the following HTTP methods: GET, POST, PUT, PATCH, DELETE, OPTIONS.
We also utilize web sockets for some operations and may use them more in the future.
The Overview page contains a series of widgets that can help you get a sense of your recent workflows and other pieces of information that may help you gain your bearings.
These widgets can be rearranged and resized to meet your preferences. The widgets can be moved by clicking and dragging the title bar of the widget. They can be resized by clicking and dragging the bottom right corner of the widget to the desired size.
This is a pie chart that shows the current distribution of non-closed cases across all of your case leads.
This is a line chart that shows the amount of cases, evidence, and acquisitions that has been created over a 12 month period.
This is a list of the 15 most recent cases that you have accessed.
This is a list of the 15 most recent evidence items that you have accessed.
This is a list of the 15 most recent activity logs for your account.
This is a list of inquiries that have a current status of "New".
These are Quality Assurance reviews that are currently assigned to you and are not complete.
This is a list of tasks that are due within the next 7 days.
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|
Usage | Region | Endpoint |
---|
uuid
String
Unique value that identifies a specific inquiry.
uuid
String
Unique value that identifies a specific inquiry. This value will take precedence over the UUID URL param if passed.
inquiry_id
String
This is a unique integer value that identifies a specific inquiry. \nThis serves the same purpose as the uuid value.
status
String
This is the status of an inquiry.
request_id
Integer
This is the request_id of the inquiry. This value is usually associated with a Relay request, but can also be associated with external request systems if utilized via API when creating an inquiry.
x-api-key*
String
Monolith API Key
name
string (requried)
Full name of the client
email
string
Email address for this person
title
string
Professional title of this client
organization
string
Agency or Company that the client is employed with
unique_id
string
A unique identifier for this person. (Employee ID, DOB, etc...)
description
string
Notes about this client.
address
string
Street address of client
city
string
City or town of client
state
string
State or Province
province
string
Alternative field for "state" value.
country
string
Country of client
postal_code
string
Postal code related to client address
office_number
string
Office phone number of client
mobile_number
string
Mobile phone number of client
case_id
number
Unique ID of a case to link evidence.
case_uuid
string
Unique ID of a case to link evidence.
case_number
string
Case number to link evidence.
evidence_number
string
Evidence number of the evidence being created.
item_name
string
Name of the evidence item.
type
string
The type of evidence item: (Smartphone, Server, Email, etc...)
provider
string
Service provider or manufacturer of evidence.
model_number
string
Evidence model number.
unique_id
string
Unique ID associated with the device - usually a serial number or account name.
size
number
Capacity of the evidence
size_unit
string
Unit of capacity: KB, MB, GB, TB, PB
description
string
Description of the item
custom_fields
array
Array of custom field objects
field_id
integer
Unique id of the custom field
value
string
This is the value to be set for the custom field
x-api-key*
String
Monolith API Key
client*
JSON
A JSON object with client info.
request_name
String
A name for this inquiry.
request_id
String
This is the request_id of the inquiry. This value is usually associated with a Relay request, but can also be associated with external request systems if utilized via API when creating an inquiry.
client_ref_number
String
A case or matter number related to the requestor.
description
String
A description of the inquiry - usually the details of the request being made.
inquiry_type
String
Type of inquiry - should map to the case types in your Monolith database.
referred_by
String
Source of inquiry - defaults to "API Request"
evidence
Array
This is an array of evidence objects.
client.name*
String
Name of the requestor.
client.email*
String
Email of requesting client.
client.org
String
Organization of requestor.
client.phone
String
Office phone number of requestor.
client.mobile
String
Mobile phone number of requestor.
client.address
String
Address of requestor.
client.city
String
City of requestor.
client.region
String
State or province of requestor.
client.postal_code
String
Postal code for requestor.
client.type
String
Type of client
evidence.evidence_number
String
Evidence number for requestor
evidence.item_name*
String
Name of evidence item.
evidence.provider
String
Manufacturer or service provider.
evidence.evidence_type
String
Type of evidence - should map to evidence types in Monolith.
evidence.unique_id
String
Serial number or account identifier for evidence item.
evidence.description
String
Description of evidence.
contacts
Array
Array of contact objects
contacts.name*
String
Name of person.
contacts.type
String
Type of contact/person.
contacts.unique_id
String
Identifier of person.
contacts.description
String
Description or notes related to person.
documents
Array
Array of document objects
documents.name*
String
Filename of document
documents.data*
String
Base64 encoded string of file data.
task_name
(required)
string
Name of task.
case_id
(required)
number
Case to be linked to task.
description
string
Description of task.
due_date
Date
Due date of the task "YYYY-MM-DD"
assignees
number array
Array of user_id values used to assign users to the created task.
| string | Unique ID of task. |
| number | Unique ID of task. |
| number | Unique ID of case linked to tasks. |
| string | Unique ID of case linked to tasks. |
| boolean | A flag indicating whether a task is archived or not. |
| boolean | A flag indicating whether to include archived tasks or not. |
| boolean | A flag indicating if tasks are completed or not. |
| number | ID of user that is assigned to a task or created a task. |
| number | ID of user that is assigned to a task. |
| number | Selected page of results. |
| number | Number of task items to include in list. Default (10000) |
Monolith | US | https://[www]monolith-app.monolithforensics.com |
Monolith | US | https://[www]api.monolith-app.monolithforensics.com |
Monolith | UK | https://[www]monolith-app.monolithforensics.co.uk |
Monolith | UK | https://[www]api.monolithforensics.co.uk |
Relay | US | https://[www]relay-app.monolithforensics.com |
Relay | UK | https://[www]relay-app.monolithforensics.co.uk |
File Management | US | https://monolith-cloud-east.s3.us-gov-east-1.amazonaws.com |
File Management | UK | https://monolith-cloud.s3.eu-west-2.amazonaws.com |
File Management | US | https://monolith-cloud.s3.us-west-004.backblazeb2.com |
App Updates | ALL | https://monolith-cloud.nyc3.cdn.digitaloceanspaces.com |
In Monolith, storage items are considered to be devices that are used for the purpose of storing forensic data that has either been collected, processed, or provided.
External Hard Drives
USB Drives
Network Attached Storage devices
FTP Servers
Cloud Storage Systems (AWS, Google Drive, etc...)
Forensic Images
Smartphone Extractions
Case Data
Forensic Reports
First, everything in Monolith is considered evidence, but for the puposes of organization and management Monolith tracks evidence and storage items separately.
Evidence typically represents the original source of forenisc evidence or data. Usually, this includes hard assets like smartphones or laptops and soft assets like email or cloud accounts. You should track anything that is considered as the original or "best" evidence as an evidence item.
Storage represents the vessel that collected forensic data is stored on. So when tracking storage items in Monolith, you are essentially tracking all the device you use to store forensic data.
Monolith tracks two categories of storage items: "General" and "Assigned".
General storage items are meant to represent large storage arrays that are used as a permenant cache for all case data. This is typically a NAS array that stores pristine copies of all your case data and forensic images. It is also a fixed asset that usually stays in the lab and does not move.
Assigned storage items represent storage that is associated with a specific case and stored very specific data. These devices are usually smaller and portable devices that move around a lot and may even be wiped, destroyed, or recycled at the end of a case or matter.
General Item Rules:
Cannot be assigned to a case.
Monolith does not track chain of custody for these items.
Tracks data from multiple cases.
Assigned Item Rules:
Must be assigned to a case to use.
Can only track data from one case.
Chain of custody is only logged when assigned to a case.
Can be removed from a case and reused/re-assigned.
Removing from a case will destroy its chain of custody and unlink any tracked acquisitions.
There are two ways to assign a storage item to a case: Create or Assign.
You an create a storage item from the "Storage Items" tab of a case. This will both create the new item and assign it to the case at the same time.
You can also assign a storage item that already exists to the current case. This option is available in the "Storage Items" tab of a case and in the "Actions" menu as shown in the screenshot below.
View table of all contacts associated with your organization
Audits allow your team to reconcile physical items under your control with their digital references in Monolith.
You can create audits to check and verify the locations and details of items currently recorded within your Monolith database.
Use the "+ New Audit" button to begin creating a new audit.
The above screenshot shows the Audit Creation Menu:
Audit Name - This is the name of the audit, enter something simple and descriptive of the audit.
Assignee - This is the Monolith User/Person that will be assigned to run or administer the audit.
Start Date - This is anticipated start date of the audit.
Due Date - This is the expected due date of the audit.
Item Type - Select the type of items that will be included in this audit. Currently only Evidence and Storage items can be selected. You can only select one option.
Description - Provide a detailed description of the audit so that other users will know what this audit is for.
Cancel - Closes the menu and cancels the audit creation process.
Create Audit - Submits the completed form and creates a new audit with the supplied parameters.
When conducted an audit of items your organization is tracking, you will likely only want to audit a subset of all the items in Monolith. For example, you may only want to audit items from a specific year or quarter, or items of a specific type or location. The audit filter allows you to do this.
Upon making a selection within the "Item Type" field, a new section within the audit creation menu will appear:
This filter will match the query filter you have seen in the Evidence and Storage items tables. Depending on the item type you selected, the filter will contain fields for either evidence or storage items.
You can apply any filters that you want, and this will dictate which items will be included in the audit you are creating.
The example filter below will include any evidence items that are "Smartphones" and were created in 2023:
If you do not apply a filter, all items will be included in the audit.
Upon clicking the "Create Audit" button, the audit will be created and will appear in the audit table:
As you can see in the screenshot above, this audit includes 29 evidence items based on the filter that was applied.
Each of the status tabs can be used to navigate through the items being audited.
Auditing an item typically involves at least two procedures:
One type of audit requires the auditor to compare the location of the item listed in Monolith with its actual location in the forensic lab or designated evidence storage.
For Example, consider the following item:
According to Monolith, this item is currently located within the Calgary office, at the Evidence Room group, and at the AAA location.
Verify the location by finding the physical item in your posession and check if its actual location in reality matches the location recorded in Monolith.
The other type of audit requires the auditor to verify all the item's details and not just the location. This type of audit requires more work but can be useful in maintaining accurate data in your Monolith database.
If the item's location or other details are incorrect, use the status selector of the item to mark it as "Failed". This will open a meu where you can enter a note about why the item failed.
You can then fix the item right away by updating the location or details in Monolith, or you can wait until you have audited all items first.
Once the status update is submitted, the audit item card is moved to the "Failed" tab.
If you determine that the details and location of the item are correct, you can then mark the item as having passed its audit.
This may also occur after you have failed the item and then updated the item with accurate information.
The process to pass an item is identical to failing an item. You simply update its status to "Passed" and enter a note about why it passed.
When updating an audit item's status, the audit method will update whenever you pass or fail an item.
The audit methods currently used are "Manual" and "Scanned". Using the status selector to update the item's status will set the audit method to "Manual" as it represent that the auditor manually passed or failed the item without using a scanner.
The "Scanned" method is discussed in more detail here: Using a scanner
The audit logs record each time and audit item's status is updated. These logs include a timestamp, auditor, and the notes entered at the time of audit.
These logs can be used for documentation or to keep track of why items did not pass an audit and then repair the items as needed.
The audit logs can also be viewed within the audit items detail's page.
Here is an example of the audit logs from this evidence items details page:
Currently, audits are only accessible by Monolith user with the "Admin" role. This will likely be updated in the future.
Audits in Monolith can be viewed by clicking the "Audits" section in the Monolith sidebar under "Evidence Management".
Within the "Audits" section, audits are listed in a standard Monolith table.
An audits can be viewed and accessed by clicking the name of an audit within the table, which should be highlighted as a blue navigation link.
The main audit view contains two tabs for navigation.
Audit Items - This is where the audit process takes place and contains the audit details and items.
Audit Logs - Contains a table of logs related to auditing items.
This sub-tab contains the details about the audit you are viewing.
This section shows you the current status of the audit, "Open" or "Complete", along with other details such as the audit due date, assignment, and filter used to select the audit items.
The remaining tabs: All, Pending, Passed, & Failed, list the audit items included with the audit. The items are group by thier current status.
These tabs are used when conducting the audit process.
View information about individual clients associated with your organization
On the left hand side of the clients page you can view and edit all of the details associated with your client.
At the top of the client details section you can also print labels using the information in client details
You can also see a table view all of the cases associated with this client in two views:
My Associated Cases: Cases associated with this client that you are assigned as a user.
All Associated Cases: Administrator view for all cases associated with this client.
Administrators can also delete a client from the client page.
In this section you can see a list of all clients associated with your organization in a view.
Coming Soon