Single Responsibility Principle states that every class or module should have one reason to change. To restate it for clarity. A module should be responsible to one, and only one, actor.
I disagree with this statement, i.e. I don't think it's a good rule to follow. And I know Uncle Bob says something very similar or even the same, still.
Let's just think about this a little. Say I have a simple Amount class that has add() and subtract(). What if one "actor" only needs add() and another subtract(). Should I split this class? Would that make the code more maintainable? I don't think you would argue that it would.
Before you say it all depends and you should always exercise judgement, I don't think a rule is a good rule when it doesn't even apply in simple cases.
To your question: You're sort-of right, I would also try to separate the data collection from the actual workflow implementation if that is possible. For example if the Workflow is an interface and all data for the data collection is available through the parameters, then I would create an implementation that collects data and delegates the calls.
If however there are internal data to the workflow that needs collecting, that is not available through the public parameters, then I would have no problems with putting the data collection into the implementation itself, because in this case I am actually interested in the actual implementation's behavior.
So, you did not yet manage to convince me either :)