packages/go/ein/azure.go (1)

299-331: Group/User → App AZGrant edges look consistent with existing schema

Using PrincipalId as the source (typed as azure.Group/azure.User) and AppId as the target (typed as azure.App) with azure.Grant aligns with how AZApp nodes are keyed (AppId) elsewhere and matches the PR’s goal of exposing which principals can access an app. Uppercasing IDs and using NewIngestibleRelationship keeps this consistent with the rest of the converters.

If you later need to distinguish specific app roles, you could optionally extend these helpers to incorporate AppRoleId into the RelType (similar to RelationshipKindByAppRoleID for SP→SP), but that’s not required for the current feature.

cmd/api/src/services/graphify/azure_convertors.go (1)

213-236: App role assignment branching by principal type looks correct; consider a constant for "Group"

The new control flow in convertAzureAppRoleAssignment looks solid:

• Returning immediately on JSON unmarshal error avoids processing a zero-valued AppRoleAssignment.
• Handling the MS Graph + ServicePrincipal case in its own branch (with an early return) keeps the SP↔MS Graph modeling clean and prevents user/group principals from being treated as service principals.
• The new Group and User branches correctly delegate to the EIN helpers and only append relationships when IsValid() passes, which matches patterns elsewhere.

Two minor follow‑ups:

• For consistency with PrincipalTypeServicePrincipal / PrincipalTypeUser, you might want a PrincipalTypeGroup constant instead of the string literal "Group".
• This function still ignores app role assignments where PrincipalType == ServicePrincipal and AppId != azure.MSGraphAppUniversalID; if that’s intentional (same as previous behavior), nothing to change, but it’s worth double‑checking that no desired edges are being dropped.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

cmd/api/src/services/graphify/azure_convertors.go (1)

227-237: Consider using else if for mutual exclusivity and adding logging for unhandled types.

The separate if statements for Group and User handling work correctly but using else if would make the mutual exclusivity of principal types more explicit and prevent any theoretical edge case where both conditions could match.

Additionally, consider adding a log warning for unhandled principal types (anything other than ServicePrincipal, Group, or User) to aid debugging and ensure visibility when unexpected data is encountered.

Apply this diff to use else if and add logging for unhandled types:

 	if data.PrincipalType == PrincipalTypeGroup {
 		if rel := ein.ConvertAzureGroupAppRoleAssignmentToRel(data); rel.IsValid() {
 			converted.RelProps = append(converted.RelProps, rel)
 		}
-	}
-
-	if data.PrincipalType == PrincipalTypeUser {
+	} else if data.PrincipalType == PrincipalTypeUser {
 		if rel := ein.ConvertAzureUserAppRoleAssignmentToRel(data); rel.IsValid() {
 			converted.RelProps = append(converted.RelProps, rel)
 		}
+	} else {
+		slog.Warn(fmt.Sprintf("Unhandled principal type in app role assignment: %s", data.PrincipalType))
 	}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro