In order for Access to know WHICH customer you wish to view when you press the command button, it needs to know WHICH customer is active on the record you are viewing. Placing the customerID field on your open form identifies the customer.

In older versions of Access, you were required to have the ID on the Form.
In modern versions, this isn't always the case.

The ID was usually put on the form if you were referring to the ID from somewhere else, like a query or VBA code. Like Kevin says, it’s usually on a case by case basis.

Lisa and Alex are on the right track: the button needs the CustomerID value for the current record so it knows which Customer Form to open. But Kevin is also correct that the ID does not necessarily have to be displayed, or even have a control on the form.

The important distinction is between a field in the form's Record Source and a control on the form. If CustomerID is in the form's Record Source, the form's current record has that value whether or not you put a textbox on the form. In VBA, I would normally refer to it explicitly like this:

Me.Recordset!CustomerID

Then use that value to build the WhereCondition for DoCmd.OpenForm.

However, if you want to refer to it externally with something like Forms!CallbackF!CustomerID, that generally refers to a control named CustomerID, so you would need a textbox control on the form - it can be hidden.

Deleting a control does not permanently leave a CustomerID property behind on the form. Access can resolve field names from the form's Record Source in some contexts, which makes this behavior seem a little magical, but it is not a substitute for a control when you specifically need to reference the control from elsewhere.

This is a good question, and I have been planning to cover the field-versus-control distinction in an upcoming Quick Queries video, or perhaps give it a full lesson.