The variables FramesToAction and Length need to be stored per unit, so the unit would be the logical place for them to reside (could be elsewhere as long as they are per unit, putting them in the unit avoids indirection and should be preferred unless you have good reason to put them somewhere else).
As to how to implement it in Blueprint (or C++ for that matter) it of course depends on how you are doing other things (the ‘actions’ in particular). While your first post suggested you had something implemented, I gather from the conversation since this is probably not the case, so instead of asking how that is implemented (because I’m guessing it’s not) I’ll just make assumptions.
The big assumption being that your actions are a bp class (or a class zoo with a common base class) containing a function that takes a Unit as parameter and has that unit perform whatever action it represents.
Start new action on Unit:
Logical Update of Unit:
[Oops… Warning: the last
set above should be for Frames to Action, not Action Length]