Share all details about your problem, including any error messages you may have received.
We have a llimited amount of space on our Sandbox DB, but we still want to deploy access history in our Sandbox Env for testing. I am trying to limit access history from pushing all identitycubes to the sandbox DB.
The attached Yaml file is the config I tried.
When I run the dispatch access history task it returns that 0 objects were dispatched with a success result.
Yeah I was trying something different I got the same resuts without the quotes for correlated.
Ill tried using the single user filters, but that never worked.
I can retry it and get back to you.
Hello Yaseen. Could you please check the following points in the filters?
correlated == "true" should be correlated == true (no quotes, it is a boolean). Same for identity.correlated == true on the related object types. Since you mentioned you already tried that and still got 0, the boolean fix alone may not be the only issue.
The attached config shows &&. That is normal when viewing the YAMLConfig through the Debug XML pages, because XML encodes && as &&. But if the YAMLConfig object itself literally contains &&, the filter would not parse correctly. It would be worth opening the YAMLConfig in Debug and confirming the stored value is plain &&.
To isolate whether the filter is selecting identities at all, you could try this from the IIQ console:
Replace <your-extract-YAMLConfig-name> with the exact name selected in your Dispatch Access History task. This prints the matching objects to the console without publishing them.
If that returns the matching identities, the filter is working. In that case, zero objects from the Dispatch Access History task would be expected when those objects were already captured and nothing significant changed since the previous run. Dispatch Access History is delta-based and skips unchanged objects.
If the console command also returns 0, it would be worth confirming that you have identities whose IIQ name (not the display name) actually starts with “X” or “x”, and that the stored filter uses && and not &&.
