Yes, you could use a combo box for the CustomerID field instead. The Command Button Wizard just needs a control on the CallbackF that contains the CustomerID value so it can match it to CustomerF.

However, since this is a callback list and you are not normally choosing or changing the customer from that form, I would not use a combo box there. A hidden CustomerID text box is simpler and prevents someone from accidentally changing the CustomerID on an existing ContactT record.

The combo box would make more sense on ContactF when you are creating a new contact and need to select which customer the contact belongs to.

But do whatever works for you. They're your Legos.

Richard Richard, are you saying that the CustomerCombo combo box that's already present in the footer of the CallbackF form at ~16:20 shouldn't have been a combo box in the first place?

That the display of the customer name in the footer of the Callback F form should really have been done within an non-editable Text Box, and not within a combo box, because that combo box allows the user to change the CustomerID on an existing ContactT record?

Yes, that's exactly what I mean. In this particular CallbackF, the CustomerCombo isn't really necessary because you're not selecting a customer. You're just displaying the customer associated with the existing ContactT record.

A non-editable text box displaying FullName is better for that purpose. Keep the hidden CustomerID text box on the form so the command button wizard has the ID value it needs to open CustomerF.

The combo box is useful on ContactF when creating a new contact record, because you need to choose which customer that contact belongs to. On CallbackF, however, allowing the user to change the combo would potentially reassign an existing callback/contact to a different customer by accident.

So: combo box for data entry, text box for display-only.

Thanks so much for the detailed explanation. (And sorry about belaboring the point, I just wanted to make sure I had things straight in my own head.)

So here's what I did to CallbackF:
1) Converted CustomerCombo to a Text Box
Right-clicked on the Combo Box, then selected "Change to", then "Text Box"
2) Changed "Control Source" in that Text Box's "Date" Properties to "FullName"
3) Changed "Name" in that Text Box's "Other" Properties to "CustomerTxtBox"
4) Changed the background color of that Text Box to gray

Any gotchas for that approach?

That approach is fine. Since FullName is already in CallbackQ, binding CustomerTxtBox to FullName will display the customer's name for the current record.

The main thing I would add is to set the text box's Locked property to Yes. Gray is a good visual cue, but Locked prevents someone from clicking into the box and changing the displayed value. You can also set Tab Stop to No so users tab past it.

Keep the hidden CustomerID control on CallbackF for the command button wizard relationship. The FullName text box is just for display; CustomerID is still what links that callback/contact record to CustomerF.

And no need to apologize for asking questions. Making sure you understand why something is set up a certain way is exactly how you avoid headaches later.

Richard Thanks for the pointers w.r.t. the Text Box's Locked property and removing its Tab Stop, much appreciated.

I have Yet Another Question. :-)
Because we've converted CustomerCombo to an non-editable Text Box, should we also set the CallbackF's "Allow Additions" and "Allow Deletions" to "No"? I'm getting some funny behavior in the (New) record row, and of course now I can't set the Client field there at all.

Yes, for this particular CallbackF, I would set Allow Additions to No.

CallbackF is really a work list for existing callbacks, not the place where you normally create a new ContactT record. Since CustomerTxtBox is now display-only, there is no way to assign a new callback/contact to a customer from the (New) record row anyway.

Also, because CallbackQ only shows records where MustCallBack is True, a newly added record can behave oddly if its default MustCallBack value is False. Once the record is saved, it no longer meets the query criteria and may disappear from the callback list. That's probably some of the funny behavior you're seeing.

I would leave Allow Edits set to Yes, since you still want to update the CallbackDateTime, add notes, or uncheck MustCallBack after you have completed the call.

For Allow Deletions, I would normally set that to No too. Contacts are history, and it is usually better to keep the record and simply uncheck MustCallBack when the callback is complete. You can always delete records later if you truly need to, but it is hard to recover information after someone accidentally deletes it.

So for CallbackF, my preference would be:

Allow Additions: No
Allow Deletions: No
Allow Edits: Yes

Create new contacts and callbacks from ContactF, where the CustomerCombo is available to select the customer.

Plus, I really prefer handling deletions myself with a delete button. I almost never let my users delete records using the normal record selector hit delete trick. I'll make a button with an "Are you sure?" prompt and then handle it myself with a background SQL call. But now we're talking VBA developer-level material. You'll get there.