I would caution against doing it that way and here is one (there are many)
example of the types of problems you can encounter.

Let's suppose you have an auditor named Bill Smith. If you let your users just
type the name into an unbound text box and use code to add the name to
your audits table, then over time you will end up with values like this in
your
table;

Bill Smith
B. Smith
Bil Smith
Billl Smth
Bill Smitg
Vill snith

etc., etc.

Now sometime in the future, when you want to determine how many audits
were done by Bill Smith, it will be difficult, if not impossible, to get
accurate
results.

I suppose you could have someone else go through records and do spell
checking if your company enjoys paying people to do unnecessary work.

The info about Bill Smith, and your other auditors/employees
(First Name, Last Name, hire date, etc.) should be stored in a table with
a unique ID number. The only value that should be stored in the Audits table
is his unique ID number, not his name. Then you would have your users select
his name from a predefined list like a combo box.

The same goes for Departments, Audit Teams, etc.

Now, if for some reason you're not concerned about data integrity, I see no
reason to use unbound text boxes. Just set up a form or subform with text
boxes bound to those fields in the table, an allow them to just type
whatever value they want directly into the table via the form. That is
essentailly what you would be doing anyway, so why add the extra work
of having to write an insert or update SQL statement behind your button?

If you are determined to use your current method, post back to get examples
of how to code your button, but I don't think it's a good idea.