Content Type resets back to default type after entering modern standard form

[Karstenve]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

Site designs & site scripts

Developer environment

Windows

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

Describe the bug / error

I have several content types in my list for an event scheduling app. Now when I add a new event through the form in a different content type than the default, it submits all the info like it should but changes the content type back to the set default.

Steps to reproduce

1. Have several overlapping content types in a list
2. Add an item through a form of a non-default type
3. Look at the content type column to see if it returns to default

Expected behavior

The expected behaviour is that after submission, the right content type is selected in the content type column instead of it always returning to the default content type

[Karstenve]

I'd like to add that I tested this with several new lists and other content types and it still occured

[Ashlesha-MSFT]

Hello @Karstenve,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.
If you don’t receive a reply within two working days, please use this escalation form to escalate.

[Ashlesha-MSFT]

@Karstenve,
We tested the reported scenario in SharePoint Online using a list with multiple custom content types. On our side, the issue could not be reproduced at any point. Both content types were created with Parent Content Type = Item and added to the list. Items created using a non-default content type through the modern form retained the selected content type after save. No reversion to the default content type was observed during testing. Based on our validation, the behavior appears to work as expected with a supported configuration.
Please let us know if we may have missed any steps or if there are additional details to review.