Mailmerge data would come from a query.
If you have the tables setup as they should in a database then you get all the data you need for whatever task you have in mind at the time.
Forms can allow you to view the seized items by date seized, by owners and by location seized if you have this field.
If you have a Seizure Report that starts the process then a form will head up the date, time and location of the seizure along with officers present etc.
A subform will allow you to list onto the TblProperty all the items as a new record for each item.
You will have a TblOwner and a further subform to select the owner of each entry in TblProperty.
TblSeizure holds info related to the Seizure.
TblProperty holds info related to an item - description, weight, size, estimated value etc.
TblOwner holds info related to the owner and may include a field to identfy if owner is confirmed or possible and you have owner record 0001 to be "Unknown" to cater for items seized without anyone standing up and claiming them.
Your forms will allow you to run queries as you wish that will generate, amognst other things, a mailmerge datasheet for letters to be sent out showing name of owner, seizure details, text fields related to this event and property details for that owner and that seizure ID. (you may have Owners appearing more then once)
We do a mailmerge and I have setup the data to create a temptable and then another database just has a mailmerge module that when run it generates the msword mailmerge letters. It gets it's data from the main database.
This seems to work better then just taking the table and exporting it out as mailmerge data.
Recap... use a query to collect data. If you then prefer a table to run mailmerge then have your last query a maketable query and you have your table.
Activate all this through a macro and the last entry could be to delete the temptable so you have no chance of sending letters out twice.