“filter” can be implemented using the search API or list identities API to get a list of identities based on certain criteria. With this list of identities, you can perform any of the above actions on each identity in the list.
Can you tell me more about your use case for promoting attributes in all identities? Usually, you would only run these tasks on a filtered list of identities that need it.
Hi @colin_mckibben we have a similar use case where we are using this API to do calculations on a termination date we are receiving from our source connector, we need it to run all of our identities so they evaluated multiple time a day.
Assuming the termination date is an identity attribute, you can use the identity attributes changed trigger to be notified when the termination date of an identity has changed. You can then process that single identity. This can also be done via Workflows quite easily, and would be more efficient than processing all identities. You would only need to process the identities that actually change.
If you need to process all identities for a particular source, then you can use the search API to get all of the identities and then run each identity through the process identity endpoint. Here is the search query you would run to get the IDs for all identities for a single source
“Usually, you would only run these tasks on a filtered list of identities that need it.”
IF you want to go to that much trouble as an administrator. Being able to just run the 'refresh-identities" command saves valuable administrator time. Can you provide an example of how you can accomplish the same action as the deprecated ‘Refresh Identities’ command using this ‘start-identity-processing’. Most of the time I really do not want to have to manufacture a filtered list of identities for this.
Depending on the the reason for why you need to refresh identities, there are a few options. However, I encourage you to read this document on identity processing. IdentityNow has several layers of identity processing that may not require you to manually invoke the processing.
However, going forward, there will no longer be a single API to refresh all identities in the system. This type of behavior can be achieved through a script that calls several endpoints, but it is recommended to follow the approach in the above doc before resorting to a script.
So given the limit of the 250, we can just do a script that will fetch all the identities and send the start-identity-processing in chunks of 250 … not so big of a deal to script, so if someone needs to refresh all can be done this way …
However, it will be likely less efficient and more costly, it might be better if the option to refresh all is also offered and is optimized for that.
If you use the search API to find identities, then that limit is 10,000 before you need to start paginating.
Agreed. Manually refreshing identities is not the ideal approach. However, it may be worth reading the updated identity processing documentation. There have been some changes to how IDN processes identities that may not require you to manually process them anymore.
Hi @colin_mckibben, I noticed that using /beta/identities/process to process an identity results in a different behavior that clicking the process button on an identity in the identity page (which triggers the endpoint ...identitynow.com//mentos/v3/identities/process. Clicking the process button through the UI results in direct processing, whereas using the API to process an identity did not. Either the API is actually not working or the task takes way longer than desired.
Can you confirm if this different behavior is done purposefully? If so, is there a way how we can call the API to have it work in the same way?
PM said that the API and the UI button should have the same behavior. If you are noticing otherwise, please open a support ticket so they can investigate your tenant. It’s possible this is a bug, but it could also be an environment specific issue.
I’m encountering the same issue that Angelo described — when using the /beta/identities/process API, the call returns a successful 202 Accepted, but no actual processing activity occurs. There are no updates visible in the user’s event log or source accounts, whereas clicking the “Process” button in the UI (which hits the /mentos/v3/identities/process endpoint) processes the identity immediately as expected.
You mentioned earlier that both methods should behave the same. Could you please confirm if this discrepancy is a known bug, and if so, whether it has already been addressed or fixed? Just trying to rule out whether it’s something tenant-specific or still an open issue.
Happy to open a support ticket if needed — please advise.
Appreciate the clarification, that makes sense now.
Turns out it was on my end. I was initially using the deprecated /beta/identities/process endpoint, which wasn’t triggering the processing tasks as expected. After switching over to the newer /v2025/identities/process API, the identities are now processing correctly, and I can see the corresponding “Manual Identity Processing Passed” events as expected in the identity event logs.
