HI All,
I have an list of application which i have onboarded the there is an applications those are not coming in the dropdown when i’m trying to run the Account Group aggregation. For this do i need to enable any additional setting to get that application in the AGA.
Hello Shubham, IIQ only shows applications in the Account Group Aggregation dropdown if they have a group schema defined. If an app only has an account schema, it simply won’t appear there.
Go to your application > Configuration > Schema tab and check if a group schema exists. If it’s missing, that’s your answer. Once you add the group schema, also make sure:
- The entitlement attribute in your account schema (like
memberOf) has its Type set to match the group schema’s Native Object Type (usuallygroup). - The connector-level group config is in place. For AD/LDAP, that means the group Search DN and filter. For JDBC or Web Services, the group aggregation query or operation needs to be defined.
Save the app, then check the Account Group Aggregation task again.
If your connector doesn’t support group objects at all, then AGA won’t apply. Entitlements in those cases get pulled during regular account aggregation as long as the attributes are flagged as entitlements in the account schema. (Schema docs | Aggregation docs).
in your application do you have the Object Type:Group? @Gutte_Shubham
Not every application will appear in the Account Group Aggregation task. Only applications/connectors that support account group (entitlement) aggregation are listed.
Please check if the application schema configured with Object Type:Group.
Hi @punna0001 ,
Thank you for the information.
This is JDBC connector. I don’t see any Group schema mapping. If i need to add the that what configuration changes need do?. What about the Access attribute what we have in the account schema that is pulled during regular account aggregation task. How do we mark that is and entitlement.
Hey Shubham, from your screenshot, Access = DB Creator is already coming through during regular account aggregation. So if your goal is just to treat that value as an entitlement, you do not need Account Group Aggregation for this.
Go to Configuration > Schema > Account schema, open the Access attribute and mark it as:
-
Entitlement so IIQ tracks it as access
-
Managed if you want it managed in the Entitlement Catalog / requestable
-
Multi-Valued only if one account can have more than one access value
Then save the application and run account aggregation again.
You only need a group schema and AGA if your database has a separate table/query that stores all possible access values as separate objects, something like an ACCESS_MASTER table with ACCESS_ID, ACCESS_NAME, DESCRIPTION, etc.
In that case, create a group schema for that object, configure the JDBC group aggregation query under Group Query Settings, and set the Access attribute’s Type in the account schema to match the group schema’s Native Object Type.
But based on your screenshot, I would first mark the existing Access account attribute as Entitlement/Managed and test. That is likely all you need here.
Hi @Gutte_Shubham ,
Create an object Type group in Application → Configuration → Settings → Add Object Type ‘group’
Enter the username, password and URL and SQL queries to get the groups details.
Now go to the account schema, and mark the Access Field as Managed, Entitlement and set the type as group.
And in the group schema, click on discover schema to get the group or access related attributes and set identity and display attributes
Dids you created the Group object in the APP? JDBC normally comes with OOTB but it could be missing.
Hi @punna0001 ,
Thank you information. Now account attribute is reflecting as and i can see in the both place Entitlement catalog and manage user access.
Another issue occurred. I have configured the created account provisioning policy. when i was trying to submit the access request for the new user getting below error msg.
- An unexpected error occurred: Cannot access field: get, on object: sailpoint.object.Identity@1ceaa4c3[id=c0a82c019f3d177e819f45379e2e037f,name=Aditi Mehta] : at Line: 1
Below is the crate account policy configuration.
Can you share Provisioning Policy xml by hiding sensitive information
For this new error, the issue might be coming from one of the field scripts in your Create Account provisioning policy. The message:
Cannot access field: get, on object: sailpoint.object.Identity
usually means one of the fields is using something like identity.get("employeeId"), which will fail because Identity does not work like a map object there. For standard identity fields, use direct property access:
return identity.firstname;
return identity.lastname;
return identity.email;
For custom/extended identity attributes, use:
return identity.getAttribute("employeeId");
return identity.getAttribute("department");
return identity.getAttribute("city");
The value inside getAttribute() must match the internal identity attribute name exactly, including case. Check all the fields in the policy, not only the selected one. Even if First Name looks fine, the error could be coming from Department, City, EmployeeID, or JoiningDate.
Also, the field Name in the provisioning policy should match the actual JDBC column or attribute expected by your create account query. Display Name can be friendly, but Name should match the target side.
Review each field script, fix any identity.get(...) usage, save the policy, and test the access request again.
HI @punna0001 ,
Thank you for your response.
This has been fix but now when i was submitting the access request that was failing the without any error msg. i don’t see any Provisioning Transactions as well.
Please check if your policy has the native identity / account ID field populated. JDBC needs a value that maps to the account identity column in the schema. Without it, IIQ builds the plan but cannot execute the create on the JDBC side.
Go to the application Rules tab and confirm a JDBC Provisioning Rule is assigned. The policy only collects values. The provisioning rule is what actually runs the SQL INSERT against your database. If that rule is missing or not handling the Create operation, the request will fail silently like this.
Also check identityiq.log right when you submit the request. The UI sometimes just shows Failed without the actual error.
If you can share the provisioning policy XML (sanitized) and what is selected on the Rules tab, it helps narrow it down further.
HI @punna0001 ,
Policy not having any attribute called native identity. in the rule tab i have not assigned the specific provisioning rule, because the global provisioning rule has already selected. i have attached the snapshot for and XML as well.
JDBC_Application_XML.txt (7.3 KB)
Thanks
Thanks for sharing the XML and screenshot. I can see two things here.
When I said native identity, I meant the account schema identity attribute. In your XML, that is already EmployeeID, so you do not need a separate attribute called native identity. That part is fine. But the Create Account policy field names do not match the account schema attribute names. The schema has:
EmployeeID, FirstName, LastName, Email, Department, City, JoiningDate
The policy has:
employeeID, first name, last name, email, department, city, joiningdate
IIQ expects the provisioning policy field Name to match the native application attribute name. I would treat that as exact, including case and spacing. first name is not the same as FirstName. Display Name can be friendly, but Name should be the real schema/native column name. (Provisioning Policies docs)
The other thing is the provisioning configuration. Selecting Global Provision Rule is only choosing the rule type. The actual Provision Rule dropdown in your screenshot still shows -- Select Rule --, so it does not look like a provisioning rule is assigned.
For JDBC, the Create Account policy only builds the values into the provisioning plan. The actual database update still has to be handled by JDBC provisioning logic, either a selected provisioning rule or configured JDBC provisioning query/stored procedure settings. (Provisioning Query Settings docs)
I would suggest:
- Fix the policy field names to match the schema names exactly:
FirstName,LastName,Department,Email,EmployeeID,City,JoiningDate - Configure the JDBC create provisioning logic that performs the actual INSERT into the database
- Also handle the Modify/Add logic for
Access, since entitlement add may come as a separate plan item - Save the app, test again, and check
identityiq.logat the same time if it still fails
The entitlement configuration looks fine now. This looks more like a create-account provisioning setup issue, not an AGA or Entitlement Catalog issue.