That will take some sneaky scripting. I suggest that you do not allow the user to actually delete the record. Instead make their "delete" action change a value in a status field, marking the record as deleted. You can then design your interface so that records with a "delete" status cannot be pulled up on their layouts--maintaining the illusion that the record is actually deleted. Then a script set to run on regular intevals--possibly a server schedule can pull up a report of deleted records and email it--keeping this activity hidden from the user.
An alternative to "marking" records as deleted is to import the records into a second table before deleting them.
If you have FileMaker Advanced, you can use custom menus to replace the normal delete action with a script that handles the "delete" with the added steps need to either mark or export the deleted record.
Actually I wanted to create a audit log as well, in which it would be easy for me to track which records the user deleted or modified along with the datae and time.
yes, but you indicated that you wanted all the data from that record as well so the last post suggests two ways to preserve the data in the deleted record. (And one incidental advantage to this approach is that you can "undo" a delete record option by changing the delete flag or importing the record back from the second table.)
Since you want to also preserve data edits, you may want to export the original version of a record before it was edited to that secondary table.
Another option is to set up script triggers on every field, one to capture the original value, one to append that original value to a list of changes, along with a second list of the field names. Then when the record is committed, another trigger performs a script to take the lists of field names and previous values and logs them in a change log record. Logging a record delete then becomes a manner of logging every field's value in the change log, identifying the change as a 'delete' and then deleting the record.