Owners not assigned correctly in bulk member add & inconsistent response behavior

Describe the bug

When creating a Team and adding members using the Microsoft Graph SDK for Java, there are two issues:

1. Bulk add does not correctly assign owner roles
   When using the bulk member add endpoint (/teams/{id}/members/add), users specified with the role "owner" are not assigned as owners.
   Instead, they are added as regular members, even though the request payload explicitly defines the owner role.

This behavior occurs without any error or exception, making it difficult to detect programmatically. As a result, affected users do not receive the required owner permissions.

2. createTeam does not return the created Team
   The SDK method used to create a Team suggests that a Team object will be returned. However, the response does not contain the created Team resource.
   Instead, the Team ID must be retrieved indirectly (e.g., via response headers or additional handling), which is not aligned with common framework expectations.

Expected behavior

1. Correct role assignment in bulk add
   When adding members via the bulk endpoint, the roles provided in the request (e.g., "owner") should be correctly applied.
   Users specified as owners must be assigned owner permissions within the Team.

2. Ability to define members and roles during Team creation
   It should be possible to fully define all desired members and their roles (including owners) directly during Team creation, without requiring a separate bulk add step.

3. Consistent and intuitive SDK response behavior
   The createTeam operation should either:

• return the created Team entity, or
• clearly reflect (through API design and SDK behavior) that no resource is returned.

Ideally, the SDK should align with common framework standards and not imply a return value that is not actually provided.

How to reproduce

Create Team
POST https://graph.microsoft.com/v1.0/teams
Content-Type: application/json

{
"template@odata.bind": "https://graph.microsoft.com/v1.0/teamsTemplates('standard')",
"displayName": "Test Team",
"members": [
{
"@odata.type": "#microsoft.graph.aadUserConversationMember",
"roles": ["owner"],
"user@odata.bind": "https://graph.microsoft.com/v1.0/users('john.doe@xy.com')"
}
]
}
Retrieve Team ID
The Team ID is extracted from the response (e.g., via response headers / response options).
Bulk add members
POST https://graph.microsoft.com/v1.0/teams/{team-id}/members/add
Content-Type: application/json

{
"values": [
{
"@odata.type": "microsoft.graph.aadUserConversationMember",
"roles": [],
"user@odata.bind": "https://graph.microsoft.com/v1.0/users('some.user@xy.com')"
},
{
"@odata.type": "microsoft.graph.aadUserConversationMember",
"roles": [],
"user@odata.bind": "https://graph.microsoft.com/v1.0/users('the.user@xy.com')"
},
{
"@odata.type": "microsoft.graph.aadUserConversationMember",
"roles": [],
"user@odata.bind": "https://graph.microsoft.com/v1.0/users('john.smith@xy.com')"
},
{
"@odata.type": "microsoft.graph.aadUserConversationMember",
"roles": ["owner"],
"user@odata.bind": "https://graph.microsoft.com/v1.0/users('one.owner@xy.com')"
},
{
"@odata.type": "microsoft.graph.aadUserConversationMember",
"roles": ["owner"],
"user@odata.bind": "https://graph.microsoft.com/v1.0/users('another.owner@xy.com')"
}
]
}

SDK Version

6.62.0

Latest version known to work for scenario above?

No response

Known Workarounds

No response

Debug output

The log contains no errors, which is also a real problem.

Configuration

• OS: Windows Local and a Debian on the production VM but the behavior is on both systems the same
  -Within a permission management workflow implemented in a Spring Boot 3.5.x application, Teams are programmatically created and populated in a Job with members using the Microsoft Graph SDK for Java.

Other information

No response

Start by tracing the SDK entry points for createTeam and /teams/{id}/members/add, using the reproduction requests and response headers as the baseline. Compare the owner-role handling and create response with Microsoft Graph behavior, then establish whether each discrepancy belongs to the SDK or the service. Done means both reported behaviors have a confirmed, testable fix scope.