ExamFinch.com My Study

Study guide

15.1 Leveraging the Debug Pages for Debugging

Practice this exam

SailPoint Certified IdentityIQ Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: The IdentityIQ Engineer Exam

1.1 Exam Format, Official Blueprint, and Study Strategy

2 Chapter 2: Infrastructure, Installation, and Extended Attributes

2.1 IdentityIQ Infrastructure Components 2.2 Installation Steps and Procedures 2.3 Creating Extended Attributes and the Objects That Support Them

3 Chapter 3: Build, Deployment, Patching, Access, and Email

3.1 Ongoing Build and Deployment 3.2 Installing Patches and Performing Upgrades 3.3 Configuring End-User Access 3.4 Email Server Settings and Email Redirection

4 Chapter 4: Lifecycle Manager Configuration, Provisioning Policies, and Workflows

4.1 Configuring Lifecycle Manager 4.2 Identity Provisioning Policies 4.3 Configuring LCM Workflows

5 Chapter 5: Lifecycle Events, QuickLinks, Batch Requests, and Rapid Setup

5.1 Lifecycle Events and Their Workflows 5.2 QuickLinks and QuickLink Populations 5.3 Configuring and Using Batch Requests 5.4 Rapid Setup in Lifecycle Events and Identity Operations

6 Chapter 6: Certification Campaigns and Certification Rules

6.1 Configuring and Scheduling Certification Campaigns 6.2 The Purpose of Common Certification Rules

7 Chapter 7: Policies and Policy Violations

7.1 Configuring and Leveraging Policies 7.2 Responding to Policy Violations

8 Chapter 8: Reporting, Advanced Analytics, and Auditing

8.1 Executing and Leveraging Reports 8.2 Leveraging Advanced Analytics 8.3 Configuring and Using Auditing

9 Chapter 9: Rules, Rule Libraries, and the SailPoint API

9.1 The Purpose and Use of Rule Libraries 9.2 Rule Input and Output Arguments 9.3 Common SailPoint API Objects and Methods

10 Chapter 10: Workflow Development

10.1 Workflow Variables, Transitions, and Step Conditions 10.2 Workflow Steps That Generate Work Items 10.3 The Different Workflow Step Usages 10.4 Leveraging Sub-Workflows

11 Chapter 11: Email Templates, Branding, and Localization

11.1 Customizing and Using Email Templates 11.2 Branding the SailPoint User Interface 11.3 Localizing the SailPoint UI

12 Chapter 12: Application Definitions, Connector Settings, and Rapid Setup Aggregation

12.1 Configuring Application Definitions 12.2 Configuring Common Connector Settings 12.3 Configuring Rapid Setup Aggregation Settings

13 Chapter 13: Data-Loading Tasks and Application and Connector Rules

13.1 Scheduling Tasks for Data Loading and Processing 13.2 Common Application Rule Types 13.3 Common Connector Rule Types

14 Chapter 14: Debugging with log4j, Syslog, and the IdentityIQ Console

14.1 Configuring and Leveraging log4j 14.2 Configuring and Leveraging Syslog 14.3 Leveraging the IdentityIQ Console for Debugging

15 Chapter 15: Debug Pages and the Administrator Console

15.1 Leveraging the Debug Pages for Debugging 15.2 Leveraging the Administrator Console for Debugging

16 Chapter 16: Role Model and Identity Attribute Mappings

16.1 Default Role Models and Role Types 16.2 Configuring Roles and Role Options 16.3 Configuring Identity Attribute Mappings

17 Chapter 17: Data Objects, Relationships, and Group Types

17.1 Common IdentityIQ Data Objects 17.2 Relationships Between Common Data Object Models 17.3 The Difference Between Group Types

15.1 Leveraging the Debug Pages for Debugging

Key Takeaways Explain This Topic AI

The Debug pages are reached through the wrench menu or http:// host:port /identityiq/debug and require the System Administrator capability; from 8.4, a Debug Pages Read Only Access capability can be granted.

The Object Browser is the most-used page: it views and edits the XML of any object and exposes many console-style actions in the UI.

About shows the host, IdentityIQ version, schema version, locale, time zone, and Java properties; Threads, Memory, Call Timings, Database, and Connections help diagnose performance.

Saved Debug-page edits have no rollback, so export or check out an object, change a copy, and import it instead.

Enable the Debug Object Browser Change audit action to record who changed what class through the Debug pages.

Last updated: September 2026

Leveraging the Debug Pages for Debugging

Objective 6.4 asks you to leverage the debug pages for debugging . The Debug pages give administrators direct access to the XML of every object and to live information about the running server.

Access

Use the wrench icon menu, if shown, or go straight to http://<host:port>/<context>/debug , for example http://localhost:8080/identityiq/debug .

Normally only users with the System Administrator capability can use them.

From IdentityIQ 8.4 , administrators can grant the Debug Pages Read Only Access capability. Read-only users can open the Object Browser and the other pages. They can view, copy, or download XML but cannot save, upload, or run actions such as Run Rule or Run Garbage Collector, which appear disabled. Finer-grained read-only rights can be grouped into custom capabilities, for example database pages only for a DBA.

The documentation warns that read-only users can still see every object, including sensitive data . Grant access with care.

Users without either kind of access get Access Denied .

The Pages

Page What it shows or does Typical debugging use

Object (Object Browser) Lists objects by class and shows or edits their XML. Many console actions are also available in the UI. Inspect an identity, Link, workflow case, application, or configuration exactly as stored

About Server host, IdentityIQ version and schema version , client locale and time zone, Java system properties Confirm patch level after patching (section 3.2), and check time zones

  • Memory Free, total, and maximum JVM memory Spot memory pressure during large tasks
  • Caches Buttons to manage the Hibernate caches Clear stale cached configuration
  • Count Object counts by class Sanity-check data volumes, for example after an aggregation
  • Beans JMX beans registered with the application server Advanced runtime inspection

Threads All Java threads and their states Diagnose hangs and slow tasks, alongside Administrator Console stack traces

Call Timings Time spent on certain database activities Find slow persistence operations

Logging Views or changes the path to the Log4j properties file Confirm which logging configuration is in effect (section 14.1)

  • Database Basic connection-pool information Check pool configuration
  • Connections Connections the server is currently using from the pool Detect pool exhaustion or leaks

ActiveMQ Monitoring Broker information, connectors, statistics, destinations, subscriptions Message-broker checks for Data Extract and Access History setups that use one

Using the Object Browser Well

Choose a class (for example Identity , Link , Application , Workflow , WorkflowCase , RequestDefinition , Configuration , or UIConfig ) and search by name.

Open the object to read its XML. This is the fastest way to answer questions such as what attributes did aggregation actually store on this Link? , which step is this workflow case waiting on? , or what is maxThreads on the Aggregation Partition request definition?

Several documented procedures happen here, for example editing RequestDefinition objects to set hosts and maxThreads (section 2.1), adding an AccountIconConfig to UIConfig (section 2.3), and reading a Capability's RightRefs (section 3.3).

Why Direct Edits Are Risky

The documentation is explicit: there is no rollback for edits saved in the Debug pages. The recommended practice is to export or check out the object, edit a copy, test it, and import it . That also keeps the change in source control (section 3.1). Treat a direct Debug-page save as an emergency fix that you must also copy back into the build. Otherwise the next deployment will overwrite it.

Worked Example: A Workflow Stuck in Approval

A requester says their access request has shown "pending" for a week, and the approver says there is nothing in their inbox.

Object Browser > WorkflowCase: find the case for the request and read its XML. The current step is Manager Approval , and the approval owner resolved to an identity that is now inactive .

Object Browser > WorkItem: confirm the open approval work item exists and is owned by that inactive manager.

Fix the cause, not just the symptom. Forward the work item in the UI to the right approver. Then fix the workflow's owner resolution, for example with a fallback approver (section 4.3), and add or check the inactive user work item escalation rule (section 10.2).

Do not hand-edit the WorkflowCase XML to "skip" the step. Direct edits have no rollback, and a corrupted case is harder to recover than a forwarded work item.

This pattern of reading the stored state in the Debug pages and then correcting it through supported UI actions is what the exam expects.

Auditing Debug Changes

Turn on Global Settings > Audit Configuration > General Actions > Debug Object Browser Change . Each save is then audited with the date and time , the source (who), and the target class (such as identity or bundle). The audit record does not show what changed , so use your own versioning for content. Find these records with Advanced Analytics > Audit , action DebugObjectBrowserChange , and export them as PDF, CSV, or CEF.

Debug Pages vs. the Console

  • Need Debug pages Console
  • View or edit one object's XML Easy, in the browser get , checkout , checkin
  • Server internals (threads, memory, pool) Yes threads , about , properties
  • Bulk operations and scripts Limited source , -f , piping
  • Available remotely without server login Yes No, needs server access
  • Read-only access for developers (8.4+) Yes No, requires System Administrator