IIQ Engineer common mistakes
IIQ Engineer · Understand the traps and how to avoid them.
Treating an IIQ version upgrade as a plain WAR redeploy: dropping the new WAR on the running instance and starting it without performing the documented database schema upgrade, without exporting/backing up custom objects (rules, workflows, task definitions, plugins), and without re-validating custom Java classes against the new API.
This happens because the candidate's lower environment was already on the target schema (it was upgraded earlier or rebuilt from scratch), so the missing upgrade step never manifests until the production-like environment throws schema or class-loading errors after startup.
What to do instead
Memorize the ordered upgrade checklist: export/back up the database and all custom objects (init.xml / object export), stop the app server, deploy the new WAR, run the supported schema-upgrade step, then start and smoke-test (login, aggregate one app, run one refresh, run one workflow). Recompile custom Java against the target version's libraries before cutover.
Leaving platform sizing and scheduler settings at defaults for a large deployment - default JVM heap, default connection pool, and multiple aggregation/refresh tasks scheduled to fire at the same time - then diagnosing the resulting timeouts and out-of-memory errors as connector bugs.
Candidates focus on functional configuration because it is what the UI exposes most visibly, and single-record lab tests never stress heap, pool, or task concurrency.
What to do instead
Before touching connector config, check the System Configuration (task scheduler threads, max concurrent tasks, connection pool), JVM heap, and task schedules. Stagger heavy tasks (aggregation, refresh, role refresh, certifications) and re-test with a realistic data volume; only then investigate the connector.
Onboarding an application by filling in host/credentials, saving, and immediately running a full account aggregation - skipping Test Connection, schema retrieval, attribute type/key verification, and a single-account or filtered test aggregation.
The wizard makes it feel like a linear form-filling exercise, and the candidate wants to see data appear quickly, so schema problems and parsing settings are discovered only after a long failing run.
What to do instead
Onboard in a fixed order: Test Connection → retrieve/verify schema (attribute names, types, keys, multi-valued and entitlement flags) → aggregated a filtered subset or single account → inspect the raw account in the debug pages → run full aggregation. That isolates whether a failure is connectivity, parsing, or data.
Assuming account aggregation also brings in groups/entitlements; the candidate then builds roles or access reviews on entitlements that do not exist in the system, or that exist but are not promoted/managed on the application schema.
Group aggregation is a separate task with its own options, and entitlement attributes must be flagged appropriately on the schema and in the correlation/group definition before they are usable downstream. The UI gives no error - the entitlements simply are not there.
What to do instead
Confirm the object model first: run group aggregation as its own task, verify the group/entitlement objects exist and are linked to accounts, and confirm the attribute is marked as managed/entitlement on the application schema. Only after that build role profiles or certification scopes on those entitlements.
Expecting lifecycle events to act automatically - assuming a joiner gets accounts created or a leaver gets accounts disabled across every application just because the identity's status changed or a role was assigned.
Lifecycle Manager only executes what is configured; provisioning requires a create/disable policy (provisioning policy) per application and the correct lifecycle event/workflow wiring, and missing policies fail silently or produce 'no plan' results rather than an obvious error.
What to do instead
For each application, verify the provisioning policy forms (create, update, enable, disable, delete) and the attribute mappings, then simulate the event (promote/refresh the identity, or use the workflow test facility) and inspect the provisioning plan before approving. Treat 'no plan generated' as a configuration defect, not a data issue.
Treating an approved access request as a completed provisioning transaction: the candidate closes the work item once approval is granted and never verifies the provisioning plan executed, or never distinguishes a rejected/failed plan from a successful one.
Approval, planning, and actual provisioning are distinct stages; a plan can be compiled, approved, and still fail at execution (connector error, invalid attribute, missing policy), and the UI's request view often shows only the approval state.
What to do instead
Follow the request end to end: request → compiled plan → approval → provisioning execution → account state on the target. Check the provisioning transaction/result for each plan and confirm the entitlement or account actually changed on the target before marking it done.
Modeling roles as entitlement containers only - building role profiles that reference entitlements, then assuming assignment happens, without distinguishing business roles from IT roles/profiles and without running role refresh with the assign/remove options enabled.
Roles do not self-assign from profiles; detection and assignment are computed by the role refresh process with specific options, and business roles vs IT roles carry different membership semantics. Candidates test on a single manually-assigned identity, which masks the gap.
What to do instead
Build the model bottom-up (entitlements → IT role/profile → business role), then run role refresh with role assignment and unassignment options enabled. Verify membership by inspecting a test identity's detected roles and the role's assigned identities, not by manual assignment.
Running a certification campaign with a scope and options chosen by label rather than by object model - for example certifying entitlements when the reviewer's decision cannot be resolved to a revocable account entitlement, or leaving certifier fallback/reminder/escalation unset - then being surprised that revocations never reach the target systems.
Campaign scope, certifier resolution, and revocation behavior are separate configuration surfaces; a revocation decision generates remediation work rather than instant removal, and a scope mismatch produces a decision that has nothing concrete to revoke.
What to do instead
Before activation, state explicitly what object is being certified, who certifies it, and what a revoke will do. Test with a small phase: activate, have a certifier revoke one item, then trace the decision through to the remediation work item and the resulting provisioning plan.
Customizing behavior with rules or workflows without a compile/validation step - writing a rule that references a variable or context object that is not present in that rule's execution context, or returning an improperly constructed/null result from a pre-provisioning rule, and then deploying it straight to the live system.
Rule contexts differ by hook point (the variables available in one rule type are not the same in another), and a rule that silently returns null or swallows an exception produces a plausible-looking but empty result rather than a visible failure.
What to do instead
Write against the documented rule variables for that hook, test with the rule/workflow test facility or console against a real identity, and log the inputs and returned object. For pre-provisioning rules, always return a valid plan object and handle exceptions so failures surface instead of silently blocking provisioning.
Troubleshooting from the UI only - reading the summary status of a failed task and immediately editing connector or refresh settings - without opening the task result's underlying exception, the application server log, or enabling targeted debug logging for the failing component.
The task summary shows a generic failure; the root cause (correlation failure, unique constraint, expired credential, timeout, object-modified concurrency error) is only in the exception detail and logs. Candidates pattern-match the symptom to the config they changed most recently.
What to do instead
Work the evidence chain in order: task result exception/message → application server log around the same timestamp → targeted debug logging for the relevant package, reproduced on a filtered/single-object run → only then change configuration, and re-run the minimal test to confirm the fix.