# Finding Object Findings are the most common object in PlexTrac and contain data detailing an exploit. Findings also exist in client asset information in the form of an affected asset and contain the relationship information about which client assets are affected, which is tracked in the `affected_assets` field. For each client asset, the finding affects, an object exists in that field's list containing information and metadata about the client asset and how it relates to the finding. Since the objects stored in `affected_assets` contain this extra relationship metadata, these items are considered separate objects called *affected asset objects.*

## Finding Table The following table explains the fields and data types stored for a finding. Fields are presented in alphabetical order by object field name. {% hint style="info" %} The required fields when creating a finding are `title`, `severity`, `status` and `description`. {% endhint %}

object field name	description	data type
affected_assets	name of affected assets	dict {str, {AFFECTED ASSET Object}
assignedTo	email address of user that finding is assigned to	string
client_id	client that the finding belongs to	integer
closedAt	when finding was closed	integer of epoch milliseconds `1662588579026`
common_identifiers	includes CVE scores, CWE scores, and code that is related to the finding (added in the Code Sample tab when editing a finding)	"CVE": [{ "name": str, "year": int, "id": int, "link": str } ], "CWE": [ { "name": str, "id": int, "link": str } ] }, "code_samples": [ { "caption": str, "code": str, "id": str } ] }
createdAt	when finding was created in	integer of epoch milliseconds `1662588579026`
description	description of finding	string
doc_type	field in database to identify object	string
doc_version	version of PlexTrac when finding was created. Should not be added to create or update requests	string
exhibits	an image or video related to the finding (added in the Screenshots/Video tab when editing a finding)	array: {"assets": [ { "asset": str, "id": str } ], "caption": str, "exhibitID": str:, "index": int, "type": str: MIME type image, such as .png}
fields	includes any added custom fields, plus legacy place for CVSS 3.0 score, CVSS 2.0 score, and 'general' score values entered for a finding	dict {str, dict {label: str, value: str}, "scores": { "cvss", { "type": "cvss", "value": str, "label": str, "calculation": str }, "cvss3", { "type": "cvss3", "value": str, "label": str, "calculation": str }, "general", { "type": "general", "value": str, "label": str, "calculation": str } } },
flaw_id	the unique identifier of a finding and is generated based on the finding title, but since a finding with the same title can exist in different reports, this means `flaw_id` is not unique across the platform	integer
last_update	when finding was last modified	integer of epoch milliseconds `1662588579026`
repoenedAt	when finding was reopened	integer of epoch milliseconds `1662588579026`
report_id	ID of report finding is associated with	integer
report_name	name of report	string
risk_score	object to hold different scoring data, CVSS v4.0, CVSS v3.1, CVSS v3.0, CVSS v2.0, and Likelihood x Impact scoring	see example response payload for details
selectedScore	the identified selected score for the finding	string
severity	severity of finding	string
slaData	SLA status of finding	{"title": str, "timeToExpire": str }
source	source of finding	string
status	status of finding	string
subStatus	substatus of finding	string
substatusCuid	CUID of substatus	string \| null \| undefined
tags	any tags associated with finding	string array
title	title of finding	string
visibility	visibility of finding	string

## Finding Structure The finding object stored in the database is a nested JSON object. Below are screenshots and a sample downloadable file that displays the structure of different database objects.

*continued*

{% file src="" %}