Study guide
3.1 Ongoing Build and Deployment
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
3.1 Ongoing Build and Deployment
Key Takeaways Explain This Topic AI
Configuration such as rules, workflows, and applications is exported as XML and promoted between environments; the -clean option strips id, created, modified, and lastRefresh values.
An IdentityIQ import file can contain many objects plus an ImportAction (merge, include, execute, or logConfig) that controls how they are processed.
The Services Standard Build (SSB) is an Ant-based build that combines the base product, patches, custom XML, and compiled Java into one WAR per environment.
SSB replaces %%TOKEN%% placeholders in custom XML with values from the target environment's env.target.properties file, chosen through SPTARGET or servers.properties.
Importing XML objects does not require a restart, but new Java classes, JARs, or changed .hbm.xml files require a rebuild and application server restart.
Last updated: September 2026
Ongoing Build and Deployment
Objective 1.4, understand ongoing build and deployment of IdentityIQ , covers the time after installation: new rules, workflows, applications, and Java code must move safely from a developer sandbox to production. The exam expects you to know what the product offers for moving objects and how SailPoint's standard build tooling packages them.
What Actually Gets Deployed
An IdentityIQ implementation has four kinds of change, and each moves differently:
Change type Examples How it reaches an environment
XML configuration objects Rules, workflows, applications, task definitions, forms, email templates, roles Imported into the database with the console, Import from File, or a build's import step
Java code Custom classes, JARs, plugin classes Compiled into WEB-INF/classes or WEB-INF/lib ; needs an application restart
Web and message files XHTML, JavaScript, CSS, images, message catalogs Copied into the web application directory; usually needs a restart
Schema changes *Extended.hbm.xml edits Regenerated with iiq schema , applied to the database, then deployed with a restart
Moving XML Objects Between Environments
The IdentityIQ console (section 14.3) has the core commands:
export writes all objects of one or more classes to a file. For example, export -clean workflows.xml workflow exports every workflow.
checkout writes a single object, for example checkout rule "Cert Signoff Approver" certrule.xml .
-clean removes values that do not transfer between installations. With no qualifier, it clears id , created , modified , and lastRefresh . You can also list specific fields.
import loads an XML file. import -noids removes all ID attributes before parsing. -noroleevents suppresses role-change events for role propagation.
Removing IDs matters because every database generates its own object IDs. References between objects should use names , which stay the same across environments. An object exported with its development ID can clash in production.
The first tag in an import file tells IdentityIQ how to process it:
<JasperReport> is a Jasper report.
<sailpoint> (the IdentityIQ import wrapper) can hold many objects plus an ImportAction that directs processing: merge (combine with an existing object, often used for UIConfig or SystemConfiguration entries), include (pull in another file), execute , or logConfig .
Anything else is treated as a single object.
Administrators without console access can use Global Settings > Import from File for the same XML import in the UI.
The Services Standard Build (SSB)
SailPoint's Services team publishes the Services Standard Build (SSB) , a set of Ant artifacts used on most professional implementations. The companion Services Standard Deployment (SSD) adds deployment helpers. What to know:
One source tree for all environments. A base folder holds the IdentityIQ release ( ga ), plus any patch and efix archives. config holds your custom XML (applications, rules, workflows, task definitions), src holds Java, and web holds UI overrides.
build.properties records the IdentityIQ version and patch level to build.
Environment selection. Set the SPTARGET environment variable (for example, sandbox , dev , test , or prod ) or map a machine name to an environment in servers.properties .
Tokenization. Custom XML uses placeholders such as %%AD_HOST%% . At build time, SSB replaces them with values from that environment's <env>.target.properties file, so one rule or application definition can serve every environment. <env>.iiq.properties supplies the environment's iiq.properties , and <env>.ignorefiles.properties excludes files that must not ship to that environment.
Outputs. build clean removes old output. build war produces build/classes (compiled Java), build/extract (the expanded application with tokens replaced), and build/deploy/identityiq.war . A deploy target can expand the WAR into a local IdentityIQ home and run the custom import. The generated import manifest ( sp.init-custom.xml ) lists the custom objects to load.
Check the extract. A leftover %% token in build/extract shows that a target property was never defined for that environment.
Loading diagram... SSB build and promotion flow
Operating Practices the Exam Rewards
Keep XML in source control. SailPoint's own console documentation describes storing workflows and rules in source control and importing them with import .
Restart only when needed. Importing a rule or workflow takes effect without a restart. A new JAR, a compiled class, a changed .hbm.xml file, or a replaced web file needs the application server restarted, and in a cluster every host must get the same build.
Build once per environment and test it. Promote the same source to test and production. Do not hand-edit objects in production's Debug pages, which have no rollback.
Keep patch levels identical. Because the build includes the base release and patch, every environment should run the same IdentityIQ version and patch level before objects are promoted.