New Capability: SailPoint® application onboarding – Assign

Announcements Product News
, ,
1

Description

SailPoint application onboarding introduces another key capability – Assign. A key advantage of SailPoint’s modern approach is the ability to delegate application onboarding responsibilities to application owners and subject matter experts, enabling rapid scaling for onboarding.

Problem

Scaling can slow when application onboarding depends solely on Admins or IT teams. While AI recommendations can streamline the process, they still require someone with the right access to configure sources. Subject matter experts can help, but only if permissions are managed appropriately.

Solution

SailPoint application onboarding - Assign capability empowers business and application owners to onboard their applications through intuitive interfaces.

  • It maintains centralized visibility and control for the admin and security teams.
  • Implements guardrails through approvals and configuration templates.
  • Reduces the bottlenecks by distributing the workload across the organization.

The combination of AI-driven automation and assign capabilities creates a multiplicative effect on time to value, allowing organizations to bring more applications under governance faster than ever before while maintaining security standards.

Who is affected?

All Business and Business+ customers will be able to experience the new Assign feature.

Limitations

  • There are 178 assignable connectors available today. More, coming soon.

Important Dates

General Availability: Sep 15, 2025

2 Likes
2

When will the documentation be published? Or I might have missed it looking on the documentation site.

3

Hi Alex,

Here is the link : Assigning Source Configurations - SailPoint Identity Services

It would be avialbale in the release noted too.

4

Hi @deepesh_kumar

First of all your announcement is too late. It does not mention when it will be deployed in sandbox environments and when it will be deployed in production, which would have allowed us to test this in sandbox, spot major security flaws or bugs and report them in an orderly manner to you before you deploy this to our production environments. Instead, this announcement was made 14 hours ago, which is already 2 days after the General Availability date of 15 September. For future changes, please announce this sooner here and give specific future release dates for sandbox and production, with enough time between it for customers and partners to test and prepare for this functionality.

Then regarding this functionality:
The UI of SailPoint ISC does not support basic functionality for sources such as triggering account deletion, setting up provisioning policies for update, enable, disable, applying a transform in the create provisioning policy.

it also does not support more complex things such as configuring nested entitlements, creating before provisioning rules to mitigate basic functionality gaps, turning off certain features you don’t want and many other things.

The longest time spend during application onboarding would be on topics like these. Not on setting up something easy such as account correlation which takes only a couple of minutes to figure out when not using AI. Biggest downside with account correlation is a hardcoded unremovable correlation step SailPoint has introduced which correlates based on the name and results in wrong correlations whenever you for example have multiple “James smith”s or “Wei Li”s in your organisation.

I also note two limitations of this functionality that does not make sense to me (happy to see these limitations are clearly documented though):

I don’t see why you are enforcing us to have a discovery source before we can use this assign functionality. Why shouldn’t I just be able to create a source with just the bare minimum (name+connector) and then assign this source to someone to draft details like description, VA cluster, URL, credentials et cetera, after which we can view and approve the changes? Similar for those sources without direct integration, or those excluded with specific types. Why is SailPoint not allowing us to make the decision ourselves to assign those sources or not?

And are assigned users able to edit the source and its related objects using API in ways that is not supported through the UI? If so, how will this be visible for the approver?

I think that this assign functionality, though it has potential and can be useful for some use cases, is quite limited and will definitely not enable rapid scaling for onboarding in its current form. To truly achieve rapid scaling for onboarding, SailPoint would need to build/fix other functionality, where I am happy to share my insights.

Kind regards,
Angelo

3 Likes
5

Hi Angelo,

Thanks for the elaborate feedback.

This is just the first version of this capability targetting users with basic knowledge of Identity Security. We will consider this feedback for our next phases of enhancements and those that are received across the board.

Regarding the “Assigning of sources’ topic, you can still use “Assign” without discovery. Once you have created the source, in edit mode, you can find the “Actions” button at the top right, which allows you to assign the source for configuration to anyone else.

Will reach out to you for a research session when we take up the next phase.

Thanks again for your review. It would really help improve our products.

Regards,

Deepesh

6

Cool! But why is the documentation then saying it is only possible to assign sources that were found through a discovery source? That seems to contradict to what you say here.

image
image781×123 5.61 KB

Also I checked in our non-prod environment, and did not see the option you mentioned, even though the corresponding connector is not mentioned in the documented exclusion list:

image

image
image332×332 5.34 KB

Based on the announced general availability of 3 days ago, I wonder why I am not seeing the “assign” option.

Kind regards,
Angelo

1 Like
7

Hi Angelo,

Will work with documentation to improve the document.

Can you raise a support ticket for us to check out the issue?

1 Like
8

Hi @angelo_mekenkamp!

I apologize for the confusion with the documentation. We’ve updated it to reflect that you can assign source configurations for existing sources and when creating a source from a discovered application.

As always, thank you for helping us improve our documentation!

9

That clarifies it! Thank you both and happy to read that the conclusion is that it is supported! :grin:

I wonder if this functionality, especially with its current limitations, truly enables rapid scaling, as I think it might only slightly speed up limited number of operations that already took little time, while the true time consuming tasks are not getting addressed here. But it is worth a shot to see if it works!

I wonder in what way can the assigned person test the configuration? Can they disable/enable accounts to see if the authorisation of the service account is setup properly? Can they create or simulate creation of a test account and perhaps delete it afterwards? Can they see the total number of accounts that would be returned on an aggregation to check if pagination is running smoothly? Can they (ignoring knowledge expertise) technically call those corresponding APIs?

1 Like
10

Agreed with everything Angelo said here. Generally not sure how this new feature even speeds up application on boarding. It looks like only the easiest pieces can be delegated here, like the kinds of information I can get from a single email to the application team. My org doesn’t really have a need for a feature like this in the first place though so I guess take that with a grain of salt. Is there a relevant idea that can be pointed to?

Seems to be another case of a “not sure who was even asking for this” feature pushed to production without proper communication or documentation on release. We’ve got to be able to do better than this.

1 Like