Apply both search query and filter to a certification

[Ramiro (Ramiro Fernandez)]

I have long been frustrated with the limitations of certification campaigns in IdentityNow. The main issue is that you can only apply a search query for EITHER identities OR access to include in a campaign, but not both.

While you can apply a search query to one and then select individual items for the other, this does not lend itself to automating the process where the list of identities/access is regularly changing.

This is such a source of frustration that I raised an idea for fixing it, which is currently sitting under “Future Consideration”: https://ideas.sailpoint.com/ideas/GOV-I-1802

However, while attempting to figure out how we can have a campaign controlled with a filter assigned to an individual, I noticed something interesting in the campaign-templates API:

create-campaign-template | SailPoint Developer Community

While the “searchCampaignInfo” object required the campaign type to be SEARCH, the “filter” object did not have any specific campaign types it would be allocated to. It just says “the default campaign filter will be used if this is blank”. From what I understand, the default campaign filter includes everything. So by default, the filter object does nothing. But looking at the documentation it seems like the filter would apply to all campaign types.

The UI does not give any option to assign a campaign template to a certification campaign in search. However, via API, anything that isn’t expressly forbidden is permitted right? So I tried creating a SEARCH type campaign with a search query AND a campaign filter applied. And what do you know? It worked! I used the search query to restrict what access to include, and the campaign filter to restrict what identities to include. And the end result was a campaign which was limited in both identities AND access.

Well this changes everything!!! Literally so many flows and business requirements I’ve written off as impossible are now possible.

However, I’ve discussed my requirements with SailPoint many times in the past and the response from them has always been “raise an idea via the ideas portal”. Nobody has ever mentioned this particular solution. This seems to suggest that nobody actually knows this, and that this isn’t actually intended. That’s also backed up by the fact that the UI gives no option to populate a filter. It seems like it’s just a result of the same data model (and presumably the same backend service and a lot of shared code) being used for both types of campaigns.

So before I go tell all my business partners their impossible requirements are possible again I need to validate: is this functionality likely to disappear in the future? If I build our workflows on this existing capability, am I going to be in big trouble six months from now as this unknown and unintended benefit disappears because of an unintended consequence of some change in the future?

How much can I rely on this?

[chirag_patel]

@Ramiro

of an unintended consequence of some change in the future?

We are using this workflow anyway in our campaign generation. This was specifically needed in uncorrelated account certification. We get all accounts irrespective of enabled/disabled status so we are filtering them using old filter mechanism.

We never contacted Sailpoint to validate we should use old filter with new search based certification generation or not because looks like UI was allowing that so we thought it is supported.

[colin_mckibben]

I have spoken to the product team, and they are aware of the existence of this capability. They don’t officially support it, but they allow it because it doesn’t interfere with the current design for certification generation. There are no plans to remove it at this time, but that is not a guarantee that it will be supported long term. That being said, this feature won’t be deprecated without advanced notice. In the event that it does get deprecated, we will do our best to make sure there is a path forward that meets or exceeds the current capabilities.

[Ramiro (Ramiro Fernandez)]

Thanks Colin! I appreciate the info. While I believe this would be better solved with the approach suggested in my idea, this gives us enough confidence to go ahead with this approach for now.