I am trying to create a certification campaign using the Search tool.
When I perform an identity search using the * query, all existing identities are returned correctly. However, when I try to configure the campaign using the access items filter and search for a specific entitlement, it does not appear as an available option.
The entitlement exists and is currently assigned to several identities, but I am unable to select it when searching by access items.
Does anyone know why an entitlement with assigned identities might not appear as an option in this filter? Is there any additional condition or configuration required for the entitlement to be available for use in the campaign?
Hello Maria. The Entitlements tab in your campaign builder is showing exactly 10,000 results, and that’s the cap. The campaign creation UI only loads a maximum of 10,000 access items when you use Refine Access. The search box on that screen filters within those 10,000, not across your full entitlement set. Since GG_CCWF_ADM-FLUJO_PROD falls outside that first batch, it won’t show up no matter what you type. This is a known limitation in the campaign builder UI.
To get around this, you can create an Access Items campaign instead and choose “All Access Items Returned by a Query” rather than the manual picker. A query like name:"GG_CCWF_ADM-FLUJO_PROD" targets the entitlement directly and bypasses the 10k cap. From there, select “Certify This Access” and then “Certify All Identities.”
ISC only includes identities that hold the entitlement as standalone access. If the two identities received it through an access profile or role, that access profile or role needs to be selected for certification instead. You can verify by opening one of the identities’ access details and checking whether the entitlement sits on its own or under an access profile.
I ran into this limitation myself building campaigns, as you can see in the “known Limitations” link provided above. Unfortunately, there are no plans to change this, and the Certifications 2.0 closed the one undocumented method that I had to get around this.
I would recommend creating an Idea for this (If I haven’t already from previous) and also contacting your CSM to see if they can find out if there is a method to handle that used internally.
I tried creating the campaign from the Search tool, starting with the access items. I selected the corresponding entitlements and generated the campaign, but the system indicates that there are no identities to certify.
However, I confirmed that these entitlements are currently assigned to three identities. The entitlements are also assigned directly to the identities and not through a role.
Does anyone know why the campaign might not be identifying these identities? Is there any additional condition that the assignments must meet for the identities to be included in the campaign?
Hi @MichaelCastillo7 This should work actually, I did such campaigns, I just created the steps and you can follow the same.
To generate this campaign, you must flip your search query so that it returns Identities who hold those specific entitlements:
certification campaigns → New campaign → Access items → Specific access items →
put the entitlement id or name “ID01” OR “ID02” OR “ID03” → Select that access item → add to campaign → certify This Access → Then you will get 2 options certify all identities or Refine identities. you need to seclect one of them accordingly.
Give all the details and start the campaign. In the preview you can see all the details that you were expecting. You can download the status report and check the same.
Based on the behaviour you’re describing, could you please confirm whether the entitlement is assigned directly to the identities or is encapsulated within an Access Profile or Role?
In ISC, search-based certification campaigns only include identities that have the selected entitlement as a standalone entitlement. If the entitlement is granted through an Access Profile or Role, the corresponding Access Profile or Role must be selected for certification instead. Likewise, if an identity’s entitlements fully match an Access Profile, ISC automatically represents that access as the Access Profile rather than individual entitlements.
If possible, could you also share:
Whether the entitlement belongs to an Access Profile or Role.
This will help determine whether the behaviour is expected or if there’s an issue specific to your tenant.
@MichaelCastillo7 has confirmed this in their response that they are directly assigned to the users:
@MichaelCastillo7 When you are creating your campaign from the search, are you selecting the the 2 Entitlements (Assuming that’s what “Anadido a la Campana” is) using the check boxes and then clicking “Certify this access” from the top? If you don’t select them, they won’t be available to the campaign, even if they show up in your search.
If you have the JSON of the certification itself from the API/Postman that you could share, it might be helpful to see how it was configured.
The identities do have the entitlements assigned, and they also have the access profiles that contain those entitlements. As you mentioned, I created the campaign using the access profiles, and now the corresponding identities are displayed correctly.
However, I have another question. If I have three access profiles that contain the same entitlement, but each access profile has different metadata, does ISC consider that metadata when determining which access profile should be associated with the identity?
Or, because all three access profiles contain the same entitlement, could ISC represent or assign all three access profiles to the identity even though their metadata is different?
Verify that the entitlement has been aggregated successfully and is visible under Admin → Access Model → Entitlements.
Ensure the entitlement is indexed/searchable. Newly aggregated entitlements may take some time to appear in certification search filters.
Confirm the entitlement is not filtered out by the campaign scope, source selection, or entitlement type restrictions.
Try searching by the exact entitlement name, value, or source combination.
If identities have the access but the entitlement object itself is not present or indexed correctly in ISC, it will not be available in the Access Items filter.
As a troubleshooting step, re-aggregate the source, verify the entitlement exists in the Entitlements page, and check whether it can be found through the global search before creating the certification campaign.
Association of the access profile and identity takes place by means of detection; the system merely determines whether the identity has all the entitlements needed to make up the access profile. If yes, the profile is associated. Metadata attributes serve only as context for the reviewer and have nothing to do with the above process.
Thus, regarding your scenario: if the identity has all the entitlements necessary for the three access profiles, each with its own entitlement set (including the one common for them all), ISC can detect/associate those three profiles with the identity simultaneously regardless of metadata. ISC does not select “the right” one among the three according to metadata. The process is merely additive with respect to entitlements.
If the three access profiles have different entitlements other than the common one, then only those access profiles that have all the entitlements are detected/associated with the identity.
