Internal working

Beneath the UI, IdentityIQ is an object-oriented Java application with a consistent internal model: everything is an object, objects are defined in XML and persisted to the database, background work runs through a scheduler, and behaviour is extended at well-defined hook points by rules. Grasping these internals is what separates someone who can click through the UI from someone who can genuinely customise and debug the platform.

Every entity in IdentityIQ, an Identity, a Role (Bundle), an Application, a Rule, a Workflow, has an XML representation and a mapped database table. The Hibernate ORM layer translates between the two. This design has direct practical consequences:

• Import and export of configuration is done as XML, which is why version-controlling your XML is the standard deployment practice.
• The object model is queryable; understanding class names (Identity, Link, Bundle, ManagedAttribute) is essential for rules and reporting.
• Changes made through the UI ultimately serialise to the same objects, so UI and XML are two views of one model.

Because Hibernate mediates all database access, query patterns and caching matter. Large objects (an identity with hundreds of links, or a huge role) are expensive to load and commit. Well-written customisations fetch only what they need and commit deliberately; poorly-written ones load enormous object graphs in loops and bring the system to its knees.

Background work is orchestrated by a Quartz-based scheduler. Tasks such as aggregation, identity refresh and certification generation are defined as objects, scheduled, and executed by task/request servers. Heavy tasks can be partitioned, split into units of work distributed across threads and servers, which is the primary lever for scaling batch throughput.

When access must change, IdentityIQ runs a consistent pipeline:

• Compile a provisioning plan describing the intended account and attribute changes.
• Evaluate policy (for example separation-of-duties) against the resulting state.
• Route any required approvals as work items.
• Execute the plan through the relevant connectors.
• Record the outcome in the audit trail.

IdentityIQ is customised primarily through rules, snippets of BeanShell (a Java-like scripting language) that run at defined hooks: correlation rules, build-map rules, provisioning rules, refresh rules and many more. Rules receive a documented context (relevant objects and a SailPointContext handle) and return a result the engine uses. Keeping rules small, null-safe, tested and version-controlled is the single most important habit for a maintainable deployment, because heavy or buggy rules run in the hottest paths of the system.

• Loading huge object graphs in rules, a frequent performance killer.
• Editing generated XML without understanding references, which corrupts object relationships.
• Business logic scattered across many rules with no documentation, making the system unmaintainable.