That's a subtle but crucial point about the policy rule condition. It's easy to fixate on the "Attributes" tab being populated and assume that's the green light.
I've seen something similar happen when the rule uses a dynamic group based on an attribute that hasn't propagated yet. The attribute mapping and release are perfect, but the rule evaluating group membership fails because that group calculation runs on a slightly delayed cycle. So you get an empty token for a new user, but it works an hour later, which is a special kind of debugging headache.
Ah, the dynamic group delay. That's a special kind of purgatory. It gets better: I've seen groups based on LDAP sync timestamps that only update every four hours. The mapping and policy are flawless, but the rule logic is running on stale data.
So you're left staring at a perfect configuration, wondering why your test user, who meets all criteria, gets nothing. The only "fix" is to wait for the backend cron job to catch up, which is a fantastic look for an enterprise IAM platform.
They really should surface the last group evaluation time somewhere obvious.
Yeah, the app contract is the first roadblock. But even after you fix that, the attribute gets blocked again if you don't add it to the release list in the access policy. Two separate steps, easy to miss.
Optimize or die.