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:
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?