Life after SharePoint workflows is a reality organizations must now prepare for Microsoft is ending support for SharePoint 2010 workflows, including those created with SharePoint Designer 2010 or built-in SharePoint Workflows.

SharePoint 2010 workflows will no longer be supported after July 14, 2026.

In other words, SharePoint on-premises users need to plan for a future without relying on legacy workflow engines, including Nintex workflows, which are still built on the SharePoint 2010 workflow platform.
For more information:
Microsoft – What’s Deprecated or Removed in SharePoint Server
Nintex – Microsoft End of Support

Given these changes, organizations must rethink their approach to approvals and business processes.

For those who still rely on SharePoint workflows or plan to use Workflow Manager, it is useful to review the different SharePoint on premises workflow models.

SharePoint on-premises workflow models

SharePoint 2010 workflow engine

The SharePoint 2010 workflow engine runs directly within the SharePoint farm.
It is embedded in SharePoint and does not require external services.

It is used by:

SharePoint Designer 2010 workflows.
Built-in SharePoint approval processes.
Nintex Workflows.

This engine is genuinely internal to SharePoint.

Microsoft documentation explaining SharePoint workflow fundamentals:
https://learn.microsoft.com/en-us/sharepoint/dev/general-development/sharepoint-workflow-fundamentals

SharePoint 2013 workflow platform, external via workflow manager

The SharePoint 2013 workflow platform is architecturally different.
It requires a separate product called Workflow Manager, which must be installed and configured independently from SharePoint. Workflows execute in Workflow Manager, not inside the SharePoint process itself.
If Workflow Manager is not installed and properly connected, 2013 workflows cannot run.

Microsoft documentation describing this architecture:
https://learn.microsoft.com/en-us/sharepoint/dev/general-development/what-s-new-in-workflows-for-sharepoint

This distinction matters because solutions built on the 2013 workflow platform depend on external infrastructure and lifecycle support.

SharePoint 2013 workflows seem to still be supported on-premises, but since they are removed for SharePoint Online on April 2, 2026.

So, I would not recommend using this platform for new workflows.

What this means for Nintex Workflows

In on-premises environments, Nintex Workflows extends SharePoint workflow capabilities but relies on SharePoint 2010 workflow infrastructure.
As Microsoft retires legacy SharePoint workflow technologies, organizations that rely on these engines must evaluate the long term viability of their solutions.

One of our practical alternatives

Recently, one of my clients requested a software approval management system.

The traditional approach would have been:

Create a workflow.
Generate approval tasks.
Send notifications.
Maintain task lists.

However, in real environments we frequently observe:

Users confused between the Requests list and the Tasks list.
Duplicate visibility issues.
Over engineering for simple approval scenarios.
Long term maintenance challenges.

Instead of introducing workflow complexity, we built a clean and efficient architecture using native SharePoint capabilities only.

To take a broader view and understand all existing workflows in your SharePoint environment before deciding which ones to modernize or replace, you can read our follow-up article on SharePoint workflows mapping.

Content approval instead of workflow automation

For this purpose, we simply enabled Content Approval on the list.

This allows approvers to:

Approve.
Reject.
Add comments.

No workflow engine required, any task list generated and without external infrastructure.

The approval status is stored directly in the list item.

Personalized visibility using filtered views

To ensure that users see only their own requests, we created a view called My Requests with filter:

Created By = [Me]

This ensures:

Users track their own software requests.
Requests from other employees remain hidden.
The interface stays simple and intuitive.

In this specific case, visibility of other requests was not strictly prohibited, but limiting views improves usability and clarity.

For approvers, we set other views like pending requests, we may set also approved and denied request views.

Optional notifications without workflows

If notifications are required, SharePoint alerts can be configured:

Alerts on item changes.
Alerts limited to items created by the user.

This avoids building a full workflow engine just to send emails.

Important note when configuring alerts :
You cannot use alerts, if you set “Read items that were created by the user” in the list settings.

So creating a dedicated view such as My Requests is typically sufficient for this scenario.

What to do if I really need workflows?

If a business process truly requires workflow automation, options include:

Paid external workflow systems or BPM solutions.
Use SharePoint 2013 workflow platform, I do not recommend this approach.
Since SharePoint designer is deprecated and not supported after July 14 2026 and as introduced these workflows will be removed from the online platform.
Custom development, like event receivers or coded solutions in SharePoint, to handle approvals and notifications.
Use one of my solutions. Here, I show you only one and it evolves depending on the project.
Indeed, we offer more solutions that do not require workflow engines.

We recommend contacting us to design the best workflow process for your organization, whether or not it uses a workflow engine.

We design and implement solutions without relying on paid or deprecated workflow platforms.

In many real business cases:

Workflow engines are unnecessary.
Content approval is sufficient.
Metadata + views solve the problem.
Alerts replace automation.
Custom logic can be implemented without licensing overhead.

This approach provides:

✔ Lower licensing costs
✔ Reduced infrastructure complexity
✔ No dependency on deprecated workflow technologies
✔ Easier long-term maintenance
✔ Better user adoption

Workflow engines should be used when truly required, not by default.

Why FluentSP?

FluentSP is designed precisely for organizations facing this transition.

Rather than replacing one complex workflow engine with another, FluentSP provides elegant, lightweight alternatives built on native SharePoint capabilities, no Nintex, no Workflow Manager, no additional licensing costs.

With FluentSP, you get

✔ Ready-to-use approval solutions without deprecated workflow engines.
✔ Clean architecture based on native SharePoint features.
✔ Faster deployment and easier long-term maintenance.
✔ No dependency on paid or end-of-life platforms.
✔ Solutions tailored to your organization’s specific needs.

Whether your organization runs SharePoint on-premises or is planning a migration, FluentSP helps you build reliable business processes, without the complexity.

Ready to move beyond legacy workflows?

Conclusion

SharePoint on-premises supports multiple workflow architectures, some internal and some external. Products like Nintex, extend these capabilities but still depend on the underlying workflow infrastructure.

However, not every approval process requires a workflow engine.

By leveraging: