Sounds like you should have this set of tables and relationships:
Clients---<appointments---<sales>---Products (---< means one to many)
Take a look at the invoicing starter solution where one invoice can list multiple items sold in a portal to a related table.
You can set up your appointments table to function as an invoice table and sales can serve in place of "LineItems":
Appointments::__pk_apptID = Sales::_fk_apptID
Enable "Allow creation of records via this relationship" for Sales in this relationship.
Put a portal to Sales on your appoinments layout and you can log multiple sales simply by entering data into the rows of the portal.
With regards to your data "PROD1SALE1234, PROD2SALE1234, ..."
1234 is the value stored in __pk_apptID and _fk_apptID. This data will be entered for you each time you enter data into an empty portal row.
"PROD1" would be entered in a second field and could be a value list of your available items for sale--often taken from a Products tatble that would be linked to Sales by ProductID.
"SALE" would seem to serve no purpose here so I'm not sure why you would need it.
Would then that work to find out how many sales I have from each appointment?
If ( Appointments::__pk_apptID = Sales::_fk_apptID ), 1, 0)
No, but if you defined this field in the appointment table:
Count ( Sales::_fk_apptId )
you could get that count.
Also, a "count" summary field defined in Sales would return the same count.