My question is, does it make sense to handle this right inside my workflow?
I would encapsulate the code that you have inside the CodeActivity into an application service and have the workflow reference that application service:
class UserApplicationService{ public void ApproveMembership(string userEmail) { var user = userRepository.Get(u => u.Email == userEmail); if (user != null) { user.Activated = true; userRepository.Update(user); } }}public sealed class ApproveMembership : CodeActivity{ [RequiredArgument] public InArgument<string> UserEmail { get; set; } protected override void Execute(CodeActivityContext context) { var userEmail = UserEmail.Get(context); this.userService.ApproveMembership(userEmail); }}The motivation for this is that WWF is an infrastructural component in your architecture and it serves well to decouple infrastructure from domain logic. WWF could be replaced by something like NServiceBus in which you'd reference the same application service. Some would say this is a case of YAGNI but I think that separating infrastructure for domain code is very beneficial both in terms of code quality and the ability to reason about the domain.
I would also recommend that you push the unit of work code into the infrastructure as much as possible, so that application services don't have to call Commit explicitly.
Or is the better approach to use Dependency Injection in the workflow to get a CommandBus that will handle processing 2 new, almost identical command models that I will have to create, along with Validation and Submission handlers for them?
This seems more in line with my suggestion, however based on your code sample, I'd recommend going a step further and extracting most more of the logic inside the CodeActivity into an application service, or structure the application in such a way that you can dispatch a command without needed access to a repository.