With the rise of Power Automate as the low-code automation backbone of the Microsoft Power Platform, many developers and architects are questioning the future of older technologies like custom workflow activities.
So the big question is:
Are workflow activities still worth investing in, or are they headed for the history books?
Let’s explore the answer through the lens of capability, architecture, extensibility, and the roadmap.
🏛️ A Quick Recap: What Are Workflow Activities?
Workflow activities are custom .NET components that extend the classic Dataverse (Dynamics 365) workflows. These components are built using the CodeActivity class and can be plugged into traditional workflows to perform advanced logic beyond the out-of-the-box options.
They are often used to:
- Perform complex server-side operations
- Call external services securely
- Reuse logic across multiple workflows
- Handle scenarios that can’t be achieved through declarative workflow steps
📚 Official Docs: Create Custom Workflow Activities
🔁 The Power Automate Takeover
Power Automate flows are now the de facto standard for automating business logic in Power Platform. With their visual interface, API connectors, and cloud-native execution model, flows offer:
It’s clear that Power Automate is Microsoft’s go-forward strategy for automation.
So… where does that leave custom workflow activities?
⚔️ Workflow Activities vs Power Automate Flows
Let’s weigh the two.
| Feature | Custom Workflow Activity | Power Automate Flow |
|---|---|---|
| Execution Location | Server-side, can run synchronously or asynchronously | Cloud-hosted; generally asynchronous (some triggers can be near real-time but not true sync for Dataverse row changes) |
| Performance | Runs in-process on Dataverse server potentially faster for simple logic, but can add load; better for short ops | Executes via Microsoft cloud infrastructure; adds network/service latency; performance depends on cloud and network |
| Security Context | Executes under the security context defined at registration often as “SYSTEM”, providing high privilege | Runs as the user who created the flow or the connection reference typically user-level permissions |
| ALM & Deployment | Deployed by registering plugin assemblies, then adding to solutions; supports manual and solution-based deployment, but not as CI/CD-friendly | Fully supports CI/CD pipelines and modern ALM practices via solutions/export/import and Power Platform DevOps integrations |
| Reusability | Reusable in classic workflows only; not available outside legacy context | Highly reusable can create child flows and custom connectors for modularity and extensibility |
| Complex Logic | Full .NET Framework power advanced logic, external assemblies, access to SDK | Limited to Power Fx, expressions, built-in actions; complex logic requires external APIs or Azure Functions |
| Debugging & Logging | Requires manual logging/tracing; debugging is difficult and error tracing can be manual and tedious | Modern built-in logging, run history, error handling, and Flow Checker make troubleshooting easier |
| Availability in UI | Available only in the classic workflow designer; not supported in modern UI | Available in unified Power Automate designer (modern browser UI) |
| Supportability | Considered legacy by Microsoft still supported but no new investments; on roadmap for replacement | Modern automation technology with active feature development and strategic focus |
🧠 So… Do Workflow Activities Still Have an Edge?
Surprisingly, yes, in specific scenarios:
✅ Use Cases Where Workflow Activities Shine:
- Need for synchronous execution: Especially when operations must complete before the transaction continues (e.g., real-time validation).
- High performance internal logic: Minimal latency for small, high-volume tasks.
- Full control with .NET: Want to avoid external APIs? Workflow activities let you run optimized server-side code in your solution boundary.
- No external dependencies: No connector throttling, no cloud execution delay, no flow limits.
- Secure execution context: Can run under system context to access protected records.
For these reasons, many ISVs and enterprise solutions still ship workflow activities today and they work seamlessly in Dataverse-based apps.
🚨 Will Workflow Activities Be Deprecated?
As of today:
Microsoft has not announced any deprecation of workflow activities.
However, classic real-time workflows and background workflows have taken a backseat to Power Automate in terms of investment. The tooling for workflow activities still works, but:
- Workflow Designer is legacy
- Power Automate is the strategic path
- Plugin Packages and Power Fx-based logic are getting more attention
⚠️ Custom workflow activities are supported, but not innovated upon. Use them where they bring unique advantages not by default.
🔮 Future-Proof Architecture: What Should You Do?
Here’s a recommendation matrix:
| Scenario | Recommendation |
|---|---|
| Need server-side logic with .NET and full control | Use custom plugins or workflow activities |
| Want no-code/low-code workflows for business teams | Use Power Automate flows |
| Need reusable logic in flows | Use child flows or custom connectors |
| Want secure, isolated server-side code in a managed solution | Use Plugin Packages, consider workflow activities if flow isn’t suitable |
If you’re starting new development today:
Favor Power Automate for flow-based logic and Plugin Packages for .NET-based execution.
But don’t be afraid to mix both, hybrid architectures are common and encouraged.
Custom workflow activities still matter, but they’re now a niche tool in a broader Power Platform toolkit.
If you’re in an environment with legacy workflows, don’t panic. They’re supported and still powerful. But for greenfield development or modern cloud-first projects, bet on Power Automate and Plugin Packages.
💬 What’s your take?
Are you still using custom workflow activities? Have you migrated to Power Automate fully or are you juggling both worlds?
My Trial 