preaccesstokenpreaccesstoken seems to only read ZITADEL user/user_grants/metadata. Our workaround is: v1 stores Entra group IDs in metadata, then v2 maps them and appends custom role claims. Is this the recommended/future-proof pattern given v1 removal in v5?entraid_groupsentraid_groups.function.preaccesstokenfunction.preaccesstoken calls our group-mapper service. The service:append_claimsappend_claims with the mapped rolesappend_claimsappend_claims appears unable to set urn:zitadel:iam:*urn:zitadel:iam:* claims or override existing claims, so we use a custom claim like org:project:{projectId}:rolesorg:project:{projectId}:roles. We also stopped requesting the built-in ZITADEL roles scope to avoid stale/duplicate role claims.preaccesstokenpreaccesstoken approach reasonable, or is there a better pattern?Join the Discord to ask follow-up questions and connect with the community