Connect SharePoint tasks with Power Automate: triggers, status, and clean handoffs

How do you connect SharePoint tasks with Power Automate so that status changes trigger stable follow-up processes and no trigger runs twice? The connection between SharePoint task lists and Power Automate sounds technically simple. In practice, many implementations fail due to one or more of the same issues: flows are triggered twice, status changes create loops, permissions are missing at runtime, or follow-up processes run even though the initial condition is not met.

This guide shows how to connect SharePoint tasks with Power Automate so that triggers are clearly defined, status changes are reliably detected, and handoff to follow-up processes occurs in a controlled manner. For the upstream process decision, Power Automate assesses SharePoint processes to determine when task lists, sharing permissions, and status fields belong together.

Typical patterns for tasks in SharePoint

In SharePoint, tasks can arise at different levels. The basic pattern is a list—either the classic SharePoint Tasks list or a custom list with its own fields. Both can serve as the starting point for Power Automate flows.

SharePoint tasks list versus custom list

The built-in SharePoint Tasks list comes with a predefined data model including fields such as "Assigned To", "Due Date", "% Complete", and "Status". It is a good starting point for many simple task workflows, but it has limitations: the Status field has fixed values (Not Started, Completed, Postponed, etc.) and can only be adjusted to a limited extent.

A custom SharePoint list is more flexible. You can specifically add your own status values, custom fields for process steps, priorities, and links to documents or project lists. For more complex workflows, a custom list is usually the better choice.

Typical task workflows

In practice, the following patterns are encountered regularly:

• Task Assignment: A new task is created, a person is assigned, and that person receives a notification.
• Status Change as Trigger: When a task is set to "In Progress" or "Completed", an action should follow, such as a notification, a follow-up task, or an entry in another system.
• Escalation upon Deadline Expiration: If a task is not completed by the due date, the responsible person is reminded, and optionally, their manager is informed.
• Process Chain: A completed task triggers the creation of the next task in the process step.

All these patterns have their own trigger requirements, which must be carefully selected.

Trigger selection: created, modified, status change, manual

The correct trigger is the most important decision point when building a task flow. Power Automate offers three relevant standard triggers for SharePoint lists:

"When an item is created"

This trigger fires when a new list item is created. It is suitable for:

• Notifications for new task assignments,
• Automatic pre-filling of fields,
• Creating subtasks for a newly created main task.

What this trigger does not detect: later changes to the item. It is triggered exactly once per item, at the time of creation.

"When an item is modified"

This trigger fires for every change to a list item, regardless of which field was changed. This is its biggest problem: it reacts to every field change, including technically automatic changes such as setting a timestamp by another flow.

Without an explicit condition in the flow body that checks whether the relevant field has actually changed, a loop is easily created.

Status change as a targeted trigger

Power Automate does not have its own "status changed" trigger. Instead, the "when an item is changed" trigger is combined with a condition:

1. The trigger fires on every change.
2. In the flow, a condition follows: Is the new value of the status field "Completed"?
3. Only if this condition is true is the rest of the flow executed.

However, this alone is not enough to prevent multiple executions. If another flow updates the same item, the trigger fires again. The solution is a check field.

Check field for a controlled one-time condition

A proven method is a field such as "FlowTriggered" (type: Yes/No) in the list. The flow checks at the beginning whether this field is still set to "No". If yes, the field is immediately set to "Yes" before the actual flow actions are executed. This ensures that each status change is processed only once, even if the trigger fires multiple times.

Manual trigger and button flows

For tasks that are intentionally started by a manual action, either a Power Apps call or the button trigger in Power Automate is suitable. Button flows can accept user input and are not triggered automatically, which prevents loops and unexpected multiple executions.

Create, update tasks, and hand off to follow-up processes

Create task automatically

The Power Automate action "Create item" on a SharePoint list creates a new entry. When building a process chain in which completed tasks create new tasks, the following fields are particularly important:

• Title: Formulated uniquely and specific to the process step, so the recipient immediately knows what needs to be done.
• Assigned to: As an email address or as the UPN value of the person. Person columns in SharePoint expect a specific format – the most common error is passing a plain name instead of a valid email address or claims ID.
• Due date: As a UTC date. If the date is created locally, the tenant's time zone must be taken into account to avoid date shifts.
• Status: Set a defined initial value, typically "Not started".

Update task

The action "Update item" requires the ID of the entry. This can come either from the trigger output (on changes) or from a previous "Get items" action.

Important: The "Update item" action requires a complete and clean assignment for required fields. If dynamic values are passed empty or required fields in the flow are not controlled and mapped, existing values may be overwritten unintentionally or validations may be violated. To change only a single field specifically, the REST API action with a PATCH call may be more appropriate.

Handoff to follow-up processes

If a completed task triggers a follow-up process, the handoff must be clean. The following fields are important for a reliable handoff:

• Task ID: As a unique key for back-references in the follow-up system.
• Status: The current, already-verified status value.
• Assigned Person: For notifications, follow-up task assignments, or permission grants.
• Parent Reference: When tasks are in a hierarchy, a reference to the parent object (e.g., project ID, requirement ID).

Prevent loops, duplicates, and endless triggers

This is the technically most critical section. Many SharePoint and Power Automate task workflows fail not due to incorrect logic, but due to trigger loops or multiple executions.

Causes of loops

A loop typically occurs as follows:

1. Flow A is triggered when entry X changes.
2. Flow A changes entry X (e.g., sets a status field).
3. This change triggers Flow A again.
4. The cycle starts over.

Break loops with conditions

The most reliable method is a combined condition at the start of the flow that checks multiple criteria:

• Has the relevant field changed (new value ≠ old value)?
• Is the check field not yet set?
• Did the trigger account not have the "Automation Email" (to detect flow-on-flow trigger chains)?

If any of these conditions is not met, the flow ends without action.

Use "trigger conditions"

Power Automate offers a feature called Trigger Conditions (execution conditions) that checks whether certain conditions are met before the actual flow body starts. This allows many unnecessary trigger activations to be caught in the configuration:

@equals(triggerBody()?['Status']?['Value'], 'Erledigt')

This condition ensures that the flow starts only when the status field is "Completed." Power Automate completely ignores all other changes without starting the flow body.

Concurrency issues with simultaneous changes

When many users update tasks in a list simultaneously, it can happen that the same flow is started multiple times concurrently for the same item. The Concurrency Control setting in the flow trigger limits simultaneous execution. For workflows that update the same entry, set the concurrency control to 1.

Typical errors with permissions, concurrency, and trigger conditions

Missing permissions at runtime

Power Automate runs Flows by default in the context of the Flow creator. If the Flow creator lacks write permissions to the target data, the action fails. In enterprise environments, use a dedicated service account or a connection account with the necessary rights.

For Flows that must run "as a user," ensure that all users who can trigger the Flow have the required permissions on the respective SharePoint objects.

Fill person columns correctly

Person columns in SharePoint do not accept free-text entries. Power Automate expects either:

• the UPN email address (user@domain.com),
• or a Claims-Value object from a previous "Get-User" action.

A common mistake is directly passing a display name, which is readable for humans but lacks the expected data structure.

Date errors due to time zones

Date fields in SharePoint store values internally in UTC. Power Automate provides date expressions by default in UTC. If a due date must be calculated correctly, use the convertTimeZone() function to convert UTC values to the local time zone of the user or tenant.

Trigger does not fire

If a Flow does not trigger even though an entry has been modified, check the following causes:

• The Flow is disabled.
• The SharePoint connection has expired or is invalid.
• The trigger conditions exclude the specific case.
• The Flow was triggered in the context of a SharePoint group, not a specific user.
• The account used has no read permissions on the trigger list item.

How to keep the task flow traceable even in exceptions

A robust task workflow requires, in addition to the execution logic, an error and fallback strategy. The simplest measure: Assign every critical step a "Run after" configuration with the "Failed" branch. There, either send an alert to the Flow admin or set a status field in the list to "Error".

For test runs, it is useful to operate a separate test list with the same columns as the production list. Changes to Flow logic, trigger conditions, or update fields should first be executed against the test list.

If a task workflow is part of a larger process chain, for example in onboarding or an approval process, it is recommended to use Scope containers in the Flow Designer. Scopes allow clear logical grouping and significantly facilitate debugging. For the pattern of subsequently writing Flow results back into a SharePoint list, the article Writing Results from Power Automate into SharePoint Lists explains the necessary writeback steps.