@WarrenBelz
yes, warren. I made the correlation, but it wasn't what I was looking for-- as I didn't want to know how to transfer the information. The issue I was looking to resolve, specifically, was why the field was blank with the options I am already using. Basically, is there something wrong with the functions and/or formula I have already done. In theory, based on the searching I've done as well as various tutorials & specifically multiple tutorials that suggested this tactic, there wasn't a need to patch the data at all. The combobox was only viewable on the NewForm and EditForm, had the same name as the original text field name, and should have been saved without the need to use the Patch function which can be a bit exhaustive given the amount of fields I'd need to do this for in the form... I imagine, since I already have multiple screens, that this may make load times slower and PowerApps already tends to run on the slower side on our network with just minimal features for whatever reason.
Anyway, I also understand that dropdowns are saved as a record, presumably, if multiselect isn't turned on. This is why in the example above -- to ensure the output of the dropdown is saved as a textvalue if it is going to a text field -- I used the Concat function. What is confusing to me is that whether or not the dropdown/combobox is recognized as a table or record is temperamental. I tested the choice columns -- 3 -- all of which had multiselect enabled, and 2/3 fields were saved as tables which meant their Items property read as FieldName.SelectedItems. One of them was saved as a record and not a table for no rhyme or reason.
Thank you for your insights :).