Hello - I'm thinking about moving w/f logic from "processes" to plugins. Here's an example use case:
1. User saves a case with a value for a particular field
2. System recognizes that the case field has a value and, based on this condition, generates a case task for the owner
3. User clears the field value for the case after the task has been generated, and then saves the case.
4. System auto-closes the task, because without a value for this case field, the task is no longer needed.
This is logic I can move from "processes" to plugins, which should give me more flexibility. However, CRM has the concept of workflows that extend CodeActivity.
Although I could implement this logic in plugins that extend IPlugin, it feels like I should implement this logic in workflows that extend CodeActivity, since I'm assuming that's the intended role of CodeActivity.
What's the typical architectural approach on CRM projects, where a goal is to manage the workflows through C# classes programatically?
For example, would a case update event be wired up to trigger a plugin, as well as a workflow? Or would the plugin make a call to a related workflow class in order to delegate the responsibility of workflow-related processing?