we run IdentityIQ 8.4 Patch 2 in a hybrid setup: on-premise Active Directory plus Microsoft Entra ID. For AD we already have a working IQService on a Windows Server, and we now want to use PowerShell before/after provisioning rules for the Entra ID application as well.
Can we simply point the Entra ID application at the existing IQService instance, or is a dedicated instance per application the better approach?
Interested in your experience regarding:
Technical limitations when sharing one IQService across applications
Throughput during large aggregations / bulk provisioning
@mlangerdz - Hi Michael — Yes. In most cases you can point the Entra ID application to the same IQService instance already used for Active Directory. IQService isn’t bound to a single application; one instance can support multiple connectors, and SailPoint documents this as fully supported.
The real limits are shared execution context and shared resources. Sharing works well when workloads are moderate, scripts are lightweight, and both integrations can run under the same service account. A dedicated IQService host makes sense only when the connectors need different privileges, have heavy or overlapping workloads, require separate maintenance windows, or must remain operationally isolated.
Performance depends entirely on connector operations, PowerShell runtime, IdentityIQ task concurrency, network latency, and Microsoft Entra/Graph throttling — there’s no fixed “accounts per minute” metric. IQService is simply a shared execution bottleneck.
My practical rule: start with one shared IQService, and split only if testing or operations show contention. High‑availability design (two IQService hosts with failover/load‑balancing) is a separate architectural decision, not a requirement per application.