New Capability: Fusion Connector for Identity Security Cloud!

Description

SailPoint® is thrilled to announce the launch of Fusion Connector for Identity Security Cloud on the Developer Community!

Problem

Simplifying Identity Correlation with Fusion Connector

Many organizations struggle with managing duplicate identities across authoritative sources, leading to inefficiencies and security risks. Today, customers manually match identities based on attributes—a time-consuming and error-prone process. Fusion connector streamlines this by intelligently detecting potential duplicate identities and providing the flexibility to merge them or create a new, unified identity. This automation reduces manual effort, enhances data accuracy, and strengthens identity governance, ultimately improving operational efficiency and security.

Solution

Fusion Connector: Intelligent Identity Matching & Duplication Prevention

The Fusion Connector streamlines identity correlation by intelligently detecting and resolving duplicate identities before they are created in downstream systems. By aggregating data from multiple authoritative sources, Fusion applies advanced matching logic to identify potential duplicates based on attributes like first name, last name, and email.

When a potential match is detected, the system generates a custom ISC form and notifies designated reviewers to assess and confirm the identity match. Based on their decision, accounts can either be merged into an existing identity or assigned a new unique ID—ensuring data accuracy, reducing manual reconciliation efforts, and improving overall identity governance.

This proactive approach stops duplicate identities at the front door, preventing manual cleanup later and freeing up valuable IT and security resources.

  1. Once additional authoritative source is added to the connector, aggregation task will need to run in order to review the potential matches. If there are any potential matches, then reviewer for that source will receive an email similar to screen shot below.
  2. Identity Match Form: The custom ISC form is dynamically generated for each potential identity match. At the top, it displays data from the source that the system identifies as a possible match to an existing identity within the platform. All data attributes on the form are fully customizable and configured within the connector. The existing identities dropdown lists all potential matches, displaying their corresponding data on the right and a weighted match score at the bottom. If no match is found, there is an option to designate the entry as a new identity instead.Once the reviewer evaluates the information and confirms a match, they can submit the form for processing. Upon submission, the Fusion connector merges the identities ensuring accurate identity management and eliminating duplicates.

Who is affected?

  • Identity Security Cloud customers
  • SailPoint partners

Important Dates

Fusion connector is available to download on Developer Community for all beginning February 19, 2025.

Customer Communications

Download Fusion: Identity Fusion Connector

Documentation Link: GitHub

Join us Feb 19th for the live stream: Duplicate Detection with the SaaS Fusion Connector

Is this still considered a community-developed connector, or is it considered a first-party SailPoint connector at this point?

One of the biggest issues we have regarding this topic is that when our correlation steps don’t give a match, for example when the authoritative account has not been aggregated yet, we expect the account to stay uncorrelated until the authoritative account becomes visible.

However, SailPoint has a hardcoded correlation step added to each source, which is an undesired step as it caused correlation to occur to wrong identities (for example because the other identity happens to have the same name).

In other cases, where there is no such similarly named identity, the account does become uncorrelated, but when the authoritative account does appear, correlation is not happening after the fact. I believe we require unoptimised account aggregation each time this occurs (and since we don’t know when it occurs and want it to be fixed anyway, we have to schedule unoptimised aggregations).

Will this capability resolve either of these two problems?

1 Like

This is still considered a community developed connector. The only difference is that @developer_relations_team is the primary maintainer. We do not have an SLA on bug fixes and feature requests, but we will prioritize critical bugs. We also accept community contributions to the code.

1 Like

Is there any plan / timeline on having this becoming part of ISC OOTB with the same SLA?

Has any client deployed this in production (with 100k+ active identities) and having it actively in use with positive impact? e.g. Success story / case study / lesson learnt / customer experience.

There is no timeline yet on when this will become an OOTB supported connector, but it is something that we are considering with the connector team.

1 Like