I don’t see a reason why any of this logic would be written in the controller or character since we have ActorComponents, UObjects and other more fitting classes.
Use an ActorComponent for a character or UObject for generic use which tracks GUIDs of active quests. These GUIDs must be present in a Datatable which is made from a “quest” struct, which holds the GUID and quest completion requirements.
Assuming you went for the ActorComponent, The ActorComponent reads through the quest datatable and matches its current state against the completion state of the tracked quests in the datatable. A completion state could be a line of info like “DialogFinished_BlackSmith_FirstGreeting” or info like having an amount of a certain item, which should be tracked in an inventory system. The ActorComponent can perform this check any time it is relevant (observer pattern), such as when the inventory changes or a dialog finishes.
There is nothing wrong with doing so for hundreds of quests unless you (for some reason) run into memory or fps issues, which is just unlikely if you use datatables for most things.