An Edm.Int32 error means SharePoint expected a 32-bit integer but the request supplied a different type. The fix is to identify the exact field and send the value shape that SharePoint expects.
The old article blamed Person fields broadly, supplied a malformed dynamic URI and invented a 70% failure statistic. None of that was defensible.
Start with the simplest action
If the destination list is known at design time, use SharePoint's Create item action. It loads the list schema and reduces the amount of REST metadata you must handle yourself.
Use Send an HTTP request to SharePoint only when the standard action cannot meet a real requirement, such as a destination list selected at runtime.
Find the field that expects an integer
Common candidates are:
- Number fields configured for whole numbers
- Lookup fields, which normally need the referenced item ID
- Person fields when using their ID-based REST representation
- system properties accidentally included in a copied object
Open the failed action's inputs in run history. Compare each value with the destination list's column type. A value that looks numeric can still be a JSON string such as "42".
Convert only after validation
For a value that should be an integer:
int(variables('SourceValue'))
Do not call int() on arbitrary input. Check for null, blank text and decimal values first, then send invalid records to an error branch.
For lookup and person columns, retrieve or resolve the correct destination ID. An email address, display name and source-list ID are not interchangeable with the destination value.
Build the REST request deliberately
Microsoft's SharePoint REST list-item guide documents the list endpoints and explains that list-item entity metadata matters when creating or updating items.
A title-based endpoint has this shape:
_api/web/lists/GetByTitle('Destination List')/items
If the list name is dynamic, construct and inspect the final string in Compose before using it. Do not embed encoded quote characters around a flow expression and hope the result is valid.
Use internal field names in the JSON body. A column renamed in SharePoint can keep its original internal name.
A practical diagnostic sequence
- Send only the required Title field.
- Confirm that the item is created.
- Add one destination field at a time.
- Inspect the first field that reintroduces the error.
- Verify its internal name, type and required representation.
- Add an error scope that records the source item ID and response body.
This takes longer than guessing once, but it produces a request you can explain and maintain.
Permissions and safety
The flow connection must be allowed to add items to the destination list. Test in a non-production list first. Do not use broad site permissions to hide a missing list permission, and do not log personal values unnecessarily when recording failures.
Bring a redacted request body and the destination column types to Power Automate Builders.