I have a role containing one entitlement from a Webservice connector. I have tried using standard criteria and identity list assignment criteria to assign this role to a test user. The purpose of this role is to trigger new account provisioning.
The issue I am experiencing is the fact that this role is not appearing on the identity, so processing the identity naturally is not triggering account provisioning.
Has anyone else experienced this? I was able to test provisioning for a separate connector (not a webservices connector) earlier today using a similar test role and test identity, so I don’t think it is environment specific slowness or anything. Also worth noting is the test identity has 2 other roles appearing on the identity for other applications, so this is not an identity specific issue, either.
Have you tried manually assigning the entitlement (i.e., Web service connector one) via Manage Access → Manager User Access quick link to see if everything works fine.
Did you click the “Apply Changes” button at the top right of the Roles page after you made the changes to identity list or standard criteria. I have forgotten to do this step many times and wondered why my roles weren’t working.
I have tried deleting and creating a new, differently named Role and I have had no luck. Manually requesting the entitlement is not easy as this is a test account.
You mentioned that you have a test identity with 2 other roles, could you please check if they have any identity errors (like provisioning errors)? I had the same issue with one of my web services connector and my test accounts had an AD account with 1 role, but they had provisioning errors. So I created a new test identity (without AD provisioning) specifically for testing webservices provisioning and that worked fine.
Just make sure the identity you are testing with doesn’t have any provisioning errors with other applications.
The create provisioning policy exists and looks standard. No relevant event logs get created during this process. I even manually created a similar Webservices source and saw the same behavior. I met with SailPoint services and they agreed this is a bug.
