Writing Power Automate results to SharePoint lists: create, update, and error handling

How do you reliably write results from Power Automate back into a SharePoint list without creating duplicates, corrupting data types, or losing traceability in case of errors? Writing Flow results back into SharePoint—also known as Writeback—is one of the most common requirements in automated processes. Whether it's approval decisions, calculation results, status updates, or form data: using Power Automate SharePoint Lists as persistent data storage requires a clear decision between creating new items, updating, and upserting, along with thoughtful error handling.

Without these considerations, typical problems arise in operations: duplicate entries after timeouts, incorrect field values due to type conflicts, silent errors without feedback, and lists that fill up with incomplete or contradictory entries within a few months. The foundational article Power Automate SharePoint Processes assesses when Writeback should even be part of the operating model.

Typical writeback scenarios for SharePoint lists

Before describing the technical patterns, it's worth taking a look at typical use cases. The scenario determines which write pattern makes sense.

Create new items

A Flow receives data—for example, from a form, an external API, an email parser, or an approved request—and creates this as a new entry in a SharePoint list. Typical examples include:

• Survey results from Microsoft Forms are stored in a response list.
• Approval decisions from an Approval Flow land in a log list with timestamps and justifications.
• Error logs from other Flows are recorded in an error list.

In these cases, "Create Item" is always the right pattern. Each record is unique, and duplicate checking is only necessary if the Flow could be executed multiple times for the same input.

Update existing items

A Flow processes data that already exists as an entry in a list and updates that entry with a new status, result, or timestamp. Typical examples include:

• The processing status of a request changes from "Submitted" to "Approved".
• A calculated value from an external source is written back into a list field.
• A completion date is set after a task is finished.

In these cases, "Update Item" is the right pattern. Prerequisite: The ID of the entry to be updated must be known.

Upsert: create or update depending on existence

The upsert pattern makes sense when an entry may or may not already exist. The Flow first checks whether a matching entry is present and then decides whether to create or update it.

Typical scenarios include:

• Daily status updates for projects: If the entry for today already exists, it is updated; otherwise, it is created anew.
• Synchronization from an external system: If the object with a specific external ID already exists, it is updated; otherwise, it is created anew.

The upsert pattern is more complex and error-prone than simple Create or Update. It should only be used when the use case truly requires it.

Create item versus update item versus upsert patterns

Create item: safely create new entries

The Power Automate action "Create item" adds a new entry to the specified SharePoint list and returns the ID of the new entry. This ID is important for later steps in the flow and should be stored in a variable.

Important points for Create item:

• List required fields must always be filled. If a required field is missing, the action fails.
• Read-only fields such as "Created by" or "Created" cannot be set directly.
• If the same flow can be run multiple times for the same input data, a duplicate check should occur before creating the entry.

Update item: update existing entries

The action "Update item" requires the SharePoint ID of the entry to be updated, as well as the site URL and list name. All other fields are optionally overwritten.

An important behavior: Update item in Power Automate overwrites all specified fields. Fields not specified in the form remain unchanged. This is different from an HTTP PATCH request, which only changes the specified fields. For complex updates where only a single field should be changed, using the SharePoint HTTP request with a PATCH call may be more appropriate than the standard action.

Implement upsert

An upsert pattern in Power Automate consists of the following steps:

1. Query: "Get items" with a filter on the unique key field (e.g., external ID, email address, project number).
2. Condition: Is the result of the query empty or not?
3. If no: Create item with all necessary fields.
4. If yes: Update item with the ID of the found entry and the fields to be changed.

The query in step 1 should always include a $filter parameter to limit the result set to the expected entry. An unfiltered "Get items" query that returns all entries and then searches for the correct entry in the flow is slow and error-prone for large lists.

Example of an OData filter in "Get items":

ExterneID eq 'AUF-2024-0815'

The filter value must be formulated as an OData expression. Column name and comparison value are based on the internal column name of the SharePoint list, not the display name.

Unique keys, queries, and avoiding duplicates

Unique key as foundation

The most important means against duplicates is a unique key in the list. SharePoint can enforce unique values for suitable columns, but this setting must be consciously activated and considered together with indexing, permissions, and error handling:

• Indexed text field with unique values: A custom field such as "ExternalID" or "ApplicationNumber" that contains the external key and is configured as an indexed field with unique values.
• Calculated field as helper column: If multiple fields together should result in a unique value (e.g., date + person), a calculated field can generate a combined key from them.
• SharePoint validation: SharePoint can reject an input via column validation rules if a certain pattern is not met. This is helpful for business plausibility, but it does not replace a unique key.

Process of a secure duplicate check

Before a new record is created, the flow performs a query:

1. "Get items" with a filter on the key field.
2. The expression length(body('Get_items')?['value']) checks whether the result set is empty.
3. If the length is greater than 0, the record already exists → either update or log an error.
4. If the length equals 0, create a new record.

This check also protects against timeouts and retry attempts. If a flow runs again after a timeout, no duplicate is created because the first run may have already created the record.

Race conditions in parallel flows

If multiple flows simultaneously check and create for the same key field, a race condition can still occur: both flows check at the same time, find nothing, and create a record simultaneously. With small data volumes and asynchronous processes, this risk is usually low. For time-critical, high-frequency flows, consider implementing a parallelism limit or using a database-level solution (e.g., Dataverse instead of SharePoint).

Error handling, retry, logging, and status fields

Error handling with "run after"

Every action in Power Automate can be configured to run only after the previous action succeeds, fails, times out, or is interrupted. This setting is called "Run after". It is essential for robust error handling.

A sensible pattern for write-backs:

1. Attempt the write-back (Create or Update Item).
2. On error: Write an error record to a separate error log list with timestamp, error message, flow run ID, and the original input value.
3. Optionally notify an administrator via Teams message or email.

Error log entries should never be written to the same list as successful records. A separate error list makes monitoring significantly easier.

Retry logic

Power Automate has a built-in retry function for HTTP actions. For SharePoint list actions, there is no automatic retry function by default. A flow that should automatically retry writing to a list after an error must build this logic explicitly:

• Use a Do-Until loop with a condition that checks whether the write-back was successful.
• Set a maximum number of iterations to prevent infinite loops.
• Insert a short delay action after each failed attempt to reduce load.

Status fields as monitoring tools

A simple but effective approach is a status field in the list that reflects the current processing status of the record:

When the flow starts, it sets the status field to "In Progress." Upon successful completion, it sets it to "Completed." In case of an error, it sets it to "Error." This makes it clear at any time which records were processed correctly and which need to be rechecked.

Typical issues with data types, person fields, and multi-values

Data type conflicts

SharePoint fields expect values in a specific format. Power Automate outputs that are sometimes not directly compatible:

• Date fields: SharePoint expects data in ISO-8601 format (e.g., 2024-06-15T00:00:00Z). If a flow receives a date from a form as text, it must be converted.
• Number fields: Decimal numbers with a comma instead of a period as a separator are not accepted.
• Boolean field (Yes/No): Power Automate uses true or false (Boolean), not "Yes"/"No" as text.

Person fields

As already mentioned in the description of task workflows: Person columns in SharePoint require a valid Claims representation. In Power Automate, a JSON object with the email address or the value Claims is passed for person columns:

{"Email": "user@domain.com"}

Alternatively, the action "Get Office 365 User" can be used, which returns a compatible user object.

Multi-value columns

SharePoint lists support columns that can hold multiple values (e.g., multiple tags, multiple categories). Writing to multi-value columns is done via an array:

{"results": ["Wert1", "Wert2", "Wert3"]}

A simple text value is not enough. If the flow passes a multi-value text from an input, it must first be split into an array (e.g., using the split() function).

Lookup columns

Lookup columns refer to records in another list. When writing, the numeric ID of the referenced record must be passed, not the displayed text. The value must be passed as an Integer or as a Lookup Value object:

{"Id": 42}

How to keep writeback robust even with errors and duplicate entries

A reliable Writeback process depends on three things: a unique key, clean error handling, and a testable runtime control. All three can be implemented without much effort if planned from the start.

For load and runtime: SharePoint lists are well suited for moderate data volumes and write frequencies. If a Flow generates very high write loads, such as hundreds or thousands of entries per hour, consider Dataverse as an alternative. Dataverse offers real constraints, better indexing, and an API designed for higher loads. For standard business processes in SharePoint-based environments, a well-structured list with status fields and an error log is sufficient in most cases.

If the Writeback into a list is part of a task workflow, the trigger and status models explained in the article Connect SharePoint tasks with Power Automate cover the upstream side of the process. For process solutions involving apps, automation, and analysis, Power Platform with SharePoint shows how Writeback, the interface, and reporting fit together.