Share all details about your problem, including any error messages you may have received.
Hello, I would like to set up a connector on Sailpoint for Sharepoint online to be able to manage user access to Sharepoint sites and groupes via Sailpoint.
I’ve been looking for an official Sailpoint documentation/guide that covers the steps to do. I’ve found many links and I’m not sure which one is correct.
For example, this one is from August 2026, Integrating SailPoint and Microsoft SharePoint Online SaaS mentions Sailpoint Agentic Fabric and Identity Security Cloud (ISC). I’m not sure what they are. There’s noting in the first link that talks about SAF or ISC.
Could you please provide me with the correct documentation to follow ?
For IIQ 8.1p5, I would not use the Microsoft SharePoint Online SaaS guide. That guide is for Identity Security Cloud / SailPoint Agentic Fabric.
The first Microsoft SharePoint Online link is the correct IdentityIQ connector family, but the current online documentation reflects newer IIQ connector versions, so I would not assume every configuration step applies exactly to 8.1p5.
For the 8.1 connector documentation, Compass was retired on September 4, but SailPoint has moved IdentityIQ downloads, guides, patches, and documentation to the SailPoint Support Portal. I would get the IdentityIQ 8.1 connector documentation from there and compare your SharePoint configuration against that version. If you have trouble locating it during the transition, SailPoint has provided compass-help@sailpoint.com for assistance.
The connector models SharePoint users as accounts and SharePoint groups from sites and subsites as entitlements. Sites themselves do not aggregate as entitlements.
I would test with one known site collection and compare a known user and their SharePoint group membership against what IIQ aggregates. That should help confirm whether this is a configuration issue or simply a different access model than expected.
Also, IdentityIQ 8.1 is already out of support, so if the 8.1 configuration is correct but aggregation still does not behave as expected, I would also consider testing on a supported IIQ version.
For IIQ 8.3p5, the Integrating SailPoint and Microsoft SharePoint Online guide (the first one you linked) is still the correct connector family. The Microsoft SharePoint Online SaaS guide is for ISC / SailPoint Agentic Fabric, so I would not use that for IIQ.
That online help tracks the latest connector version, so I would also pull the IdentityIQ 8.3 connector documentation from the SailPoint Support Portal and compare your configuration against that version.
The aggregation model also remains the same: SharePoint users are accounts and SharePoint groups from sites/subsites are entitlements. Sites themselves are not aggregated as entitlements.
If the results still look incorrect, could you share your account/group schema and a sample of the unexpected aggregation output with sensitive information removed? That should help narrow down the configuration issue.
Hello, thank you. Yes I have checked it. Indeed, it seems to cover half of the problem I’m facing. Yet, I didn’t really get how to do the customization. I wonder if it’s a code I should write or something I can configure in the UI.
Hello, I looked for the IdentityIQ 8.3 connector documentation from the SailPoint Support Portal and it’s almost the same as the 8.5 Integrating SailPoint and Microsoft SharePoint Online guide and both are similar to my configuration.
The result is actually entitlements that should be shown but are missing information / or entitlements that shouldn’t be there but are displayed. Here are examples (I have hundreds of entitlements like these):
The SharePoint Online connector, by default, pulls SharingLinks.* sites and Limited Access System Groups*, along with other site access assignments. I do not recommend excluding these from the user profile, as keeping them provides full visibility into the level of access users have within your organization.
If these access assignments are populated in the user profile, they can be deprovisioned during user offboarding. This helps ensure users no longer have access to any links within the organization when they leave, especially since the SharePoint connector does not support disabling or deleting users.
I would also recommend preventing this type of access from being requested by making it non-requestable and excluding it from the certification process. This can be done easily because these access typically starts with SharingLinks.* sites and Limited Access System* groups. You can utilize group customization rule for making the entitlements non-requestable
Hello, thank you for your answer. Can you please check the 2 screenshots I have uploaded in my previous comment above?
I’m not familiar with this, so I wonder if the entitlement syntaxes are correct. I thought that the aggregation task will pull group names that are readable and meaningful, but all I get are names in forms of URLs and long texts. Are there any examples provided so that I can have an idea about what to expect to see after aggregation?
In addition, when I click on the entitlement for details, I only find info about “value” (which is the display name as in the screenshots) and “members”.
It looks like most of your sites do not have a site name configured on the SharePoint side. As per my understanding a SharePoint site name is required in order to setup a site on SharePoint side.
To confirm this, run a preview and check what is displayed for the site name. If the name appears blank, the issue is likely related to the site naming configuration in SharePoint.
For any site showing a blank name, you can also reach out to the SharePoint team and verify whether the name is blank on their side as well. If so, they will need to add the site name in SharePoint.
From the SailPoint side, you can preview the Site Group by following these steps:
1. Open the application.
2. Go to Schema and scroll to the Object Type: Group.
3. Click Preview.
4. Check the value under the Name column for the sites.
It looks like Site B was aggregated through account aggregation with the “Promote managed attributes” option selected.
Please try the following:
- Delete the site B from the entitlement section or from Debug, then run Group Aggregation.
- Uncheck the “Promote managed attributes” option in Account Aggregation.
The difference is that sites with object properties are populated through Group Aggregation with the all group schema attributes including name, while sites without object properties are populated through Account Aggregation when “Promote managed attributes” is enabled which is not ideal.
If the site is populated correctly after these steps, you will need to delete all SharePoint sites from Debug and rerun Group Aggregation to aggregate with all the schema attributes.
@techuser Agreed ti @ab_sailpoint comment. Please uncheck the Promote Managed Attributes and let Group Aggregation take care of creating entitlements. You need to uncheck this option in Account aggregation task and in your Identity Refresh Task.
Hello @techuser. The behavior in the screenshots appears consistent with Akhilesh’s point. The complete entries appear to come from Account Group Aggregation, while the raw URL entries may have been created by Promote managed attributes during Account Aggregation. That option can create ManagedAttributes from entitlement values seen on accounts. (Account Aggregation)
I would try:
Uncheck Promote managed attributes on the SharePoint Account Aggregation task.
Check whether one incomplete entitlement gets the expected Display Value and group properties.
If not, I would test with only one affected ManagedAttribute before any bulk cleanup.
Since Site B does not appear in Group Preview, I would also check Manage All Site Collections / Include Site Collections / Exclude Site Collections and the SharePoint permissions for that site. I would start with this before changing the schema.
I unchecked “Promote managed attributes” option in Account Aggregation.
I ran Account Aggregation
I ran Group Aggregation
After aggregation, the site that is deleted is no longer in the entitlement catalog.
Also, all other sites that have the same issue (no display value, no object properties) are not updated with additional information after aggregation.
Actually, I’m not even sure if they are sites or groups that allow users to access the sites as in the entitlement information the type is “group”, also in the value, the URL contains “SiteGroups”.
Is there a sailpoint official documentation that explains the integration in depth please along with clarification of both group/account aggregation and which results to expect, other than just the basic configuration steps?
What is the result of your group aggregation task? Did you see any new site groups populated in the format I shared earlier? In the group aggregation results, do you see the number of group objects scanned and updated count?
Please run the group aggregation again with the Detect Deletes option enabled. This will provide the exact count of groups populated through group aggregation and remove any groups that were populated through account aggregation.
If Site B is not being populated through group aggregation, it may indicate that the site is assigned to users but is being excluded during the group aggregation process. Do you have a siteExclusionList or siteInclusionList configured on the SailPoint side for this app? You can check for these keywords in the application XML through Debug.
@techuser Could you please share your application xml, that should give us some idea what have you configured? Also, you might want to connect with your Sharepoint team to understand how the access is managed for the sites.
