Based on your requirements I would suggest you to consider a design that in addition to objects Client and Product has an intermediary object called, say, ProductAction. This new object would have attribute Status to register the nature of the action (i.e. 'Interested', 'Not Interested', 'Purchased' or 'Rented') and attribute TakenOn to register the date the action was taken. It would also have attributes Client (multiples not allowed) and Product (multiples not allowed) to capture the client and the product for the action. Business objects Client and Product would each have a corresponding matching attribute Actions (multiples allowed) to register actions against a product or a client.
This is how it will work. On the form for object Product you select Add New Item operation for attribute Actions. The system will show the form for object ProductAction. You select a client by clicking Add New Item for attribute Client, set the Status attribute to the appropriate value and the TakenOn attribute to the desired date (for convenience the system can be instructed to automatically set TakenOn to the current date). Once all the details are entered you click Create button to register the new ProductAction. Once registered the new ProductAction will appear on both the Client and the Product forms. You can repeat these steps to register more ProductAction records for the same or different products/clients. You will be able to change the status of any action at a later stage.
With this design you would register each action separately. For example, if a client first got interested in a product and then purchased the product at a later date, you would create two separate ProductAction records to register each of these actions.
In a more elaborate design, object ProductAction can have more attributes so you can track the action history without having to create multiple records. For example, you could add attributes like InterestedOn, PurchasedOn and RentedOn to capture the dates of particular actions the client took against the product. This would reduce the overall number of ProductAction records, which would make the data presentation more compact and convenient for you.
As for the queries, the forms for objects Client and Product would already show all the actions registered against the client/product. You can narrow down the list by entering various criteria, like date range, for the list on the form. If this proves to be insufficient for you, or if you want to have specially prepared reports, with Aware IM you can easily configure specific queries/reports at a later stage.
Please have a look at object Loan in the configuration of the Library sample application for an example of an object that registers interest (and action history) of a library member for a library item. This would be a very similar design to the one described above.
Note the importance of matching attributes. Please consult Aware IM User Guide for details.
Aware IM Support Team