How to Build Custom Workflows in Microsoft SharePoint Designer

Migrating Projects from Microsoft SharePoint Designer to Power AutomateMicrosoft SharePoint Designer (SPD) has long been a go-to tool for creating workflows, customizing SharePoint sites, and automating processes. However, SharePoint Designer is legacy software and Microsoft recommends moving modern automation efforts to Power Automate, which offers cloud-native capabilities, richer connectors, improved maintainability, and better integration with Microsoft 365. This article provides a comprehensive, practical guide to migrating projects from Microsoft SharePoint Designer to Power Automate, covering planning, assessment, design patterns, step-by-step migration, testing, and governance.

Why migrate from SharePoint Designer to Power Automate?

• Cloud-first architecture: Power Automate is built for cloud services and integrates natively with Microsoft 365, SharePoint Online, Teams, OneDrive, and third-party services.
• Long-term support: SharePoint Designer is deprecated and receives no new features; Power Automate is actively developed.
• Richer connectors and triggers: Power Automate supports hundreds of connectors, advanced triggers (including events from Microsoft Graph), and premium connectors when needed.
• Better maintenance and visibility: Flows can be monitored, versioned, and organized within the Power Platform environment.
• Improved UX and extensibility: Power Automate offers low-code building, HTTP/webhook capabilities, nested flows, and integration with Power Apps and Azure.

Pre-migration assessment

1. Inventory existing SPD artifacts

   • List all SPD workflows (site workflows and list workflows), custom actions, data sources, and any SPD-driven page customizations (e.g., customized .aspx pages or web parts).
   • For each workflow capture: associated list/library, trigger (manual, on item created/changed, scheduled), actions performed (create item, update item, send email), conditions, lookup fields, variables, SPD stages, and any impersonation steps (elevated permissions).

2. Classify workflows by complexity and priority

   • Low complexity: single-list, few steps, simple email notifications, status updates.
   • Medium complexity: multi-list interactions, lookups, parallel branches, moderate conditional logic.
   • High complexity: loops, custom code, impersonation/elevated permissions, long running, external system integrations, or heavy use of SPD-only actions.

3. Identify unsupported patterns and external dependencies

   • SPD-only actions (e.g., “Collect Data from a User” with task process that relies on SPD task forms) may need redesign.
   • Any workflows relying on server-side code, custom web services, or custom .aspx form modifications need special handling.
   • Authentication patterns—if on-premise using NTLM/Kerberos or custom service accounts—will need rework for cloud connectors, gateway, or hybrid solutions.

4. Determine target environment

   • SharePoint Online with Power Automate (recommended).
   • Hybrid scenarios: On-premises SharePoint with Power Automate using On-premises Data Gateway for on-prem data sources.
   • Decide if premium connectors or Dataverse will be required.

Design considerations and patterns in Power Automate

• Triggers and scopes

  • Replace SPD list item triggers with Power Automate triggers: “When an item is created”, “When an item is modified”, or “When an HTTP request is received” for inbound webhooks.
  • For site-level scheduled jobs, use recurrence triggers or Power Automate desktop/flows scheduled flows.

• Actions and branching

  • Use built-in actions for SharePoint (Get items, Get item, Create item, Update item, Delete item).
  • Replace SPD lookups with “Get item”/“Get items” and filter queries (OData) to fetch related data.
  • Use Condition and Switch actions for branching logic. Use Parallel branches for concurrent steps.

• Loops and pagination

  • Use “Apply to each” for looping across arrays returned by Get items. Configure pagination and top count for larger datasets, or use Do Until for conditional repeat.

• Approvals and tasks

  • SPD task processes need to be migrated to Power Automate Approvals or to a custom task list pattern using adaptive cards in Teams or Outlook actionable messages when appropriate.
  • Power Automate Approvals supports multi-stage approvals, responses, comments, and integration with Teams.

• Error handling and retries

  • Use Configure run after, scopes with Try/Catch pattern (Scope + parallel Scope for failure handling), and built-in retry settings to manage failures robustly.

• Permissions and elevated actions

  • Power Automate runs in the context of the user who triggers it by default; use service accounts with appropriate licensing, or use HTTP actions with managed identities via Azure AD, or configure flows to run as connections with required permissions.
  • Consider using Power Automate service accounts with least privilege and auditability.

• Reusability

  • Use child flows (called “Run a Child Flow”) or solution-aware flows to encapsulate reusable logic.
  • Consider moving data and business logic into Dataverse or Azure Functions for complex operations.

Step-by-step migration process

1. Prepare environment and governance

   • Ensure Power Platform licenses are available.
   • Register and configure environments, data loss prevention (DLP) policies, and connection policies.
   • Create a migration backlog and assign owners for each workflow.

2. Migrate simple workflows first

   • Start with low-complexity workflows to build patterns and templates.
   • Recreate the trigger in Power Automate, re-implement actions using SharePoint connectors, add conditions, and test.

3. Translate lookups and data operations

   • Convert SPD lookups to Get items/Get item with appropriate OData filter queries.
   • Use expressions (workflow expression editor) for string/date/number manipulation. Example: formatDateTime(triggerBody()?[‘Created’], ‘yyyy-MM-dd’).

4. Rebuild approval/task processes

   • Replace SPD collect/task patterns with Power Automate Approvals or adaptive cards.
   • Map SPD task fields to Approval details and ensure task completion updates the original SharePoint items.

5. Handle complex sequences and long-running workflows

   • Break monolithic SPD workflows into smaller, modular flows (child flows) that are easier to maintain.
   • For long-running processes, use status fields on items and trigger flows on item updates (state machine pattern).

6. Replace custom forms and UI

   • Move SPD custom forms to Power Apps or use modern list forms with Power Apps integration.
   • If pages were heavily customized with SPD, evaluate using SharePoint Framework (SPFx) or modern web parts.

7. Integrate external systems

   • Replace direct SOAP/legacy integrations with HTTP actions, custom connectors, or premium connectors.
   • For on-premises systems, install and configure the On-premises Data Gateway.

8. Add error handling and monitoring

   • Implement Configure run after for actions, wrap operations in Try/Catch scopes, and log errors to a central SharePoint list or Dataverse table.
   • Use Power Platform admin center for analytics, flow runs, and alerts.

9. Test thoroughly

   • Unit test each flow with positive and negative cases.
   • Perform integration tests covering all branches and error paths.
   • Do user acceptance testing (UAT) with real users and data.

10. Cutover and decommission

    • Schedule cutover during a maintenance window if needed.
    • Disable SPD workflows after verifying Power Automate flows behave correctly for a defined validation period.
    • Archive SPD workflows, export definitions and documentation, and remove legacy SPD customizations.

Common migration challenges and solutions

• Impersonation/elevated permissions

  • Challenge: SPD allowed actions like “System Account” behavior; Power Automate runs under connections.
  • Solution: Use service accounts, configure flows to use connection owners with appropriate rights, or implement Azure AD app-based authentication for HTTP actions.

• Complex SPD-only actions

  • Challenge: Actions such as “Set Workflow Status” or complex task forms.
  • Solution: Map workflow status to SharePoint fields and update them via Update item. Replace task forms with Power Automate Approvals or Power Apps forms.

• Lookup performance and large lists

  • Challenge: Get items on large lists can cause throttling and slow performance.
  • Solution: Use indexed columns, filter queries, pagination, or push data into Dataverse/Azure SQL for higher performance.

• Long-running workflows/state persistence

  • Challenge: SPD could keep state; flows may time out.
  • Solution: Implement state machine pattern using item status fields and multiple flows, or use durable functions/Azure Logic Apps for extreme cases.

Testing matrix (example)

• Functional: trigger, happy path, conditional branches, edge cases.
• Integration: external services, gateway connectivity, connectors.
• Performance: large volumes, concurrency, throttling scenarios.
• Security: permission boundaries, least privilege, DLP policy compliance.
• UAT: business sign-off and rollback plan.

Documentation and training

• Create clear runbooks for each migrated flow: purpose, trigger, owner, inputs/outputs, error recovery steps.
• Provide training for business users and admins on how to view run history, re-run flows, and approve requests.
• Maintain a migration log with status, issues encountered, and mitigation steps.

Post-migration governance

• Maintain DLP policies and environment controls.
• Use solution-aware flows for lifecycle management, ALM, and source control (export flows as solution components).
• Schedule periodic reviews of flows for optimization and to retire unused automations.
• Use monitoring tools in Power Platform admin center and set alerts for failure thresholds.

Example migration: simple approval workflow

Scenario: SPD workflow that triggers when a new document is added to a library, sends an approval email to a manager, and sets a Status field to “Approved” or “Rejected”.

Power Automate approach:

1. Trigger: “When a file is created (properties only)” for the document library.
2. Action: “Start and wait for an approval” — configure approver (dynamic manager lookup via Office 365 Users connector).
3. Condition: If outcome is Approve, Update file properties — set Status = Approved; else set Status = Rejected.
4. Error handling: Wrap actions in scope and log failures to a SharePoint list.

This maps SPD actions to modern connectors, uses the built-in Approvals experience, and provides better traceability.

When to consider alternative solutions

• Extremely complex, code-heavy workflows — consider Azure Logic Apps or Azure Functions.
• Heavy data-transform or transaction needs — consider Dataverse or Azure SQL for structured processing.
• Full UI customization beyond Power Apps capabilities — consider SPFx and Azure-hosted services.

Checklist before decommissioning SPD

• All workflows migrated and validated.
• Users trained and documentation published.
• Logging and monitoring in place for new flows.
• Backup/archival of SPD workflows and custom pages.
• DLP and governance policies enforced in Power Platform.
• Stakeholder sign-off completed.

Migrating from Microsoft SharePoint Designer to Power Automate is both an opportunity to modernize automation and a careful engineering exercise. By inventorying existing workflows, prioritizing migrations, adopting modern design patterns (scopes, child flows, approvals, and robust error handling), and enforcing governance, organizations can reduce risk while gaining scalability, better integrations, and improved maintainability.