From SharePoint List Item to Azure DevOps Tasks

Automating backlog creation with Power Automate (Microsoft Learn–aligned, client-neutral)

Organizations that use SharePoint as an intake or request system (ideas, demands, PMO requests, incident triage, migration requests, etc.) often want the same request to instantly become work items in Azure DevOps Boards—including a parent backlog item (User Story / Product Backlog Item) and a set of child Tasks ready for execution.

This article shows a clean, repeatable pattern using Power Automate with the SharePoint connector and the Azure DevOps connector. Everything below is written with neutral placeholders so you can safely reuse it in a public blog.

Why this pattern works

Power Automate is built around triggers and actions. A SharePoint trigger can fire when a list item is created, and then Azure DevOps actions can create and link work items. Microsoft’s documentation describes SharePoint list triggers (like “When an item is created”) and the general trigger/action model. (Microsoft Learn)

On the Azure DevOps side, work items (User Stories, PBIs, Tasks, Bugs) are the foundation of Boards tracking, and links (relations) provide traceability and hierarchy. (Microsoft Learn)

Scenario (generic)

• A SharePoint list named “Requests” receives a new item with fields like:
  • Title
  • Description
  • RequestType
  • Priority
  • TargetIteration
  • Owner
• When a new item is created:
  1. Create a User Story (or Product Backlog Item) in Azure DevOps
  2. Create several Tasks
  3. Link each Task to the parent backlog item using the correct hierarchy relationship
  4. Optionally update the SharePoint item with the created Azure DevOps ID/URL

Architecture overview (Flow design)

Trigger (SharePoint) → Create parent work item (Azure DevOps) → Create child tasks (Azure DevOps) → Link tasks to parent (Azure DevOps) → Update SharePoint item

Step-by-step configuration (Power Automate)

Step 1 — Create an Automated Cloud Flow

1. Go to Power Automate → Create → Automated cloud flow
2. Choose trigger: SharePoint – When an item is created
3. Select:
   • Site Address: https://contoso.sharepoint.com/sites/ExampleSite
   • List Name: Requests
     Microsoft documents this trigger pattern for SharePoint lists. (Microsoft Learn)

Step 2 — Add a guardrail (optional but recommended)

If your list includes multiple request types, add a Condition to only proceed when it matches the scenario you want (ex: RequestType = “Migration”).

Power Automate supports trigger customization and conditions to control when a flow proceeds. (Microsoft Learn)

Step 3 — Create the parent work item (User Story / PBI)

Add action: Azure DevOps – Create a work item (Microsoft Learn)

Configure it like:

• Organization: https://dev.azure.com/ContosoOrg
• Project: ExampleProject
• Work Item Type: User Story (or Product Backlog Item, depending on your process)
• Title: Title (from SharePoint)
• Description: Description (from SharePoint)
• Area Path / Iteration Path: map from SharePoint fields if you store them, or use defaults

Practical tip: If your org uses strict iteration governance, store the iteration value in the SharePoint item so requesters choose it up front.

Step 4 — Create a “task template” list (recommended approach)

Instead of hardcoding 10 task actions, define your tasks in an array and loop.

Add action: Initialize variable

• Name: varTaskTitles
• Type: Array
• Value (example):

[
  "Validate prerequisites and access",
  "Collect inputs and confirm scope",
  "Run pilot execution",
  "Execute migration batch",
  "Post-execution verification",
  "Documentation and closure"
]

Step 5 — Loop through tasks and create them

Add: Apply to each → input = varTaskTitles

Inside the loop:

5.1 Create Task

Action: Azure DevOps – Create a work item

• Work Item Type: Task
• Title: Current item (from the loop)
• Iteration Path: inherit from the parent or use the same as the parent
• Area Path: inherit from the parent or use a fixed value

Step 6 — Link each Task to the parent (Hierarchy-Reverse explained)

Now the critical part: making the task appear under the parent backlog item.

Azure DevOps uses work item link types to represent relationships. The hierarchy relationship is represented by forward/reverse link directions. Microsoft documents link types and how they’re used to manage relationships. (Microsoft Learn)

Rule that works reliably in Power Automate:

• If you are adding a link from the Task (child) to the User Story/PBI (parent), use Hierarchy-Reverse.

Why? Because from the child’s perspective, the relationship points “back” to the parent.

Add action: Azure DevOps – Add a link to work item

• Work Item Id: the newly created Task ID
• Link Type: System.LinkTypes.Hierarchy-Reverse
• Target: the created Parent ID (User Story/PBI)

This establishes a proper parent/child relationship.

Step 7 — Update the SharePoint item with tracking data (optional)

Add action: SharePoint – Update item

• Write back:
  • AzureDevOpsWorkItemId = Parent ID
  • AzureDevOpsUrl = parent work item URL (if you store it)

This gives requesters a direct cross-system trace.

Permissions and reliability notes

Azure DevOps permissions/scopes

If you automate via connectors, the connection user must be able to create work items. In REST terms, Azure DevOps exposes scopes such as vso.work_write for creating/updating work items. (Microsoft Learn)

Traceability

Linking work items (and optionally linking to commits/builds/releases later) is part of Azure DevOps end-to-end traceability guidance. (Microsoft Learn)

Recommended field mapping (generic)

Common pitfalls (and how to avoid them)

1) “Hierarchy-Reverse” confusion

If your “Add a link” action uses the Task as the “Work Item Id”, then Hierarchy-Reverse is typically the correct choice to point to the parent.

2) Iteration/Area path mismatch

If the Task is created with invalid Area/Iteration, creation may fail or place work items in unexpected backlogs. Prefer inheriting from the parent.

3) Multiple task sets for different request types

Use a Condition or Switch-like branching:

• If RequestType = “Migration” → use migration tasks
• If RequestType = “New Feature” → use feature tasks

Final Summary Tables

Steps Summary

Technical Reference Summary