Updated recently
Last updated:
Quick Answer: A SailPoint IIQ developer configures applications, writes BeanShell rules, builds workflows, troubleshoots aggregation and provisioning, and supports certifications. The role is less about writing the most code and more about making access changes safe, repeatable and auditable. Java basics, SQL, connector knowledge and a clear understanding of the identity lifecycle matter more than framework trivia.
What a SailPoint IIQ Developer Actually Does
The title covers a wide range of work. At one company, an IIQ developer spends most of the day onboarding applications. At another, the role is 70% production support and 30% configuration. Before you accept a title, read the job description for verbs: design, configure, troubleshoot, own. Those words predict the actual work.
| Level | Typical responsibilities | What proves you are ready |
|---|---|---|
| Junior developer | Application configuration, simple rules, task monitoring, defect fixes | One application onboarded end to end with documented evidence |
| Mid-level developer | Correlation and provisioning logic, workflows, connector troubleshooting | Owned a production change and handled its rollback |
| Senior developer | Design reviews, complex integrations, performance tuning, mentoring | Solved a cross-system failure and explained the trade-offs |
| Lead / architect | Deployment design, upgrade strategy, security model, client communication | Owned a workstream and managed technical risk |
Skills That Get You Hired
Java and object-oriented basics. BeanShell is Java-like. You need to understand classes, methods, collections, exceptions and null handling. You do not need to build a Spring service, but you do need to read a stack trace.
SQL. You will query the IIQ database, investigate orphan accounts, reconcile counts and debug slow reports. Joins, indexes and execution plans are useful even if a DBA owns the production database.
Identity lifecycle. Joiner, mover, leaver, access request, approval, provisioning, certification and revocation. If you cannot explain the lifecycle without IIQ, you will struggle to design a workflow.
Connector and integration knowledge. JDBC, LDAP, Active Directory, SCIM, web services and flat files behave differently. Learn one deeply and understand the common patterns: authentication, pagination, schema, error handling and rate limits.
BeanShell and workflow logic. Rules are not scripts you run once. They execute inside a governed process, sometimes on a hot path. Null checks, logging, idempotency and rollback matter.
Debugging. The best developers are not the ones who never break things; they are the ones who can read a task result, correlate it with an application log and find the failing component without guessing.
How to Build a Portfolio Before You Have a Job
You do not need a production employer to produce credible evidence. You need a licensed lab and the discipline to document what you did. Build four artifacts around one application: an onboarding diagram, a correlation rule with before/after orphan counts, a provisioning plan with a rollback note, and a completed certification with audit evidence.
Then write a one-page case study. State the context, the constraint, the action and the result. For example: “A flat-file HR feed had 12% orphan accounts because the correlation rule matched on display name. I changed the match order to employee ID, then email, and routed the remainder to review. Orphans fell to 1.4% in the test data set.” That is more convincing than a list of IIQ features.
Keep proprietary code out of public repositories. Use sanitized snippets and describe the pattern, not your employer’s configuration. In an interview, you can walk through the sanitized version without exposing client data.
Tools and Environment Checklist
| Tool | What you should be able to do | Why it matters |
|---|---|---|
| IIQ console | Configure an application, run a task, inspect a plan | Core daily interface |
| Tomcat / IIQ logs | Find a task result and correlate it with an exception | Most debugging starts here |
| SQL client | Query identities, links and task history | Reconcile what the UI shows |
| LDAP browser | Inspect AD/LDAP attributes and group membership | Validate source and target state |
| API client | Test a REST or SCIM endpoint before configuring a connector | Separate connector issues from target issues |
| Git or a versioned folder | Track rule and workflow changes with an owner | Rollback and review |
A Real Project Lifecycle
- Discovery: understand the target system, source of truth, account schema, entitlements and business owner.
- Design: choose the connector, correlation key, provisioning policy, approval path and rollback plan.
- Build: configure the application, write rules, build workflows and document the object model.
- Test: happy path, duplicate accounts, missing attributes, target-system failure and permission denial.
- Cutover: migrate configuration, run a controlled aggregation, reconcile counts and monitor the first joiner/mover/leaver.
- Hypercare: watch task failures, orphan accounts, provisioning errors and user tickets for the first two weeks.
The build is usually the shortest phase. Discovery and testing take longer because that is where the assumptions surface. A developer who can run a discovery workshop is worth more than one who only writes rules.
Sample Job Description
SailPoint IdentityIQ Developer — 3+ years of IAM experience. Configure and maintain IIQ applications, connectors and provisioning policies. Write BeanShell rules and workflows. Troubleshoot aggregation, correlation and provisioning issues in production. Work with application owners to define access models and certification campaigns. Required: Java, SQL, LDAP/AD, IIQ object model, strong documentation and incident communication.
Notice what is missing: a list of every connector on the market. Most teams need someone who can learn a system, ask the right questions and own a defect through closure. The specific connector can be taught.
Salary and Career Path
In India in 2026, junior IIQ developers typically sit around ₹8–14 LPA, mid-level developers around ₹14–22 LPA, and senior developers or leads higher. The band depends on implementation ownership, connector depth and whether you have worked in a regulated environment. See the SailPoint IIQ salary guide for the full table.
The career path is not only managerial. You can move into architecture, identity security engineering, IAM product ownership or cloud identity. The common thread is ownership of access risk, not just code.
Interview Prep
Expect questions on the object model, aggregation and correlation, provisioning plans, rules, workflows and a production failure. Bring one project story with numbers: how many identities, which applications, what broke, what you changed, what improved. The IIQ interview questions guide covers 30 likely questions.
If the role is senior, expect a design discussion: how would you onboard a system with no connector, how would you prevent role explosion, how would you upgrade without breaking custom code. There is no perfect answer; the panel is testing judgment.
Common Hiring Mistakes
Accepting a title without reading the work. “IIQ Developer” can mean a build role or a ticket queue with a developer label. Ask what percentage of the week is configuration, troubleshooting and design, and who owns production changes.
Leading with certification. A certificate is a filter, not a story. Interviewers want to know what you built, what failed and what you changed. If your resume lists the exam but no application, you will be treated as a fresher regardless of the title.
Ignoring SQL and logs. Many candidates can describe a provisioning plan but cannot find the failed task in a log or write a join to check orphan accounts. Those are daily skills, not DBA work.
Taking a bond without a scope guarantee. A bond is not automatically a deal-breaker, but a two-year bond with no project ownership and a low salary is a bad trade. Ask for the training plan, the project type and the review cycle in writing.
Questions to Ask the Hiring Manager
Interviews are two-way. Ask what the team owns, what a typical production incident looks like and how changes are approved. The answers tell you more about the role than the title does.
- Is this a build, support or hybrid role, and what is the split?
- Which applications are in scope, and who owns the connectors?
- How are rule and workflow changes reviewed and promoted?
- What does the on-call or hypercare rotation look like?
- What would success look like in the first six months?
A 90-Day Plan to Become Interview-Ready
- Days 1–20: complete one application onboarding in a lab and document the schema, correlation key and aggregation result.
- Days 21–40: write two rules, break one on purpose, and fix it using the logs. Record the before/after.
- Days 41–60: build an approval workflow and a small certification. Capture the audit evidence.
- Days 61–75: practise a 10-minute project walkthrough and a 20-question mock interview.
- Days 76–90: apply to roles that mention build ownership, not only support. Tailor the resume to the project evidence.
Do not wait until day 90 to apply. Start interviewing after day 60, while the project is still fresh. Each rejection tells you which part of the story is weak: the architecture, the rule, the provisioning plan or the business outcome. Fix that part, then try again.
War Story: The Custom Connector That Passed UAT
A developer built a custom connector for a legacy HR system. UAT passed with 50 test accounts. Two weeks after go-live, the nightly aggregation started failing at 2 a.m. The connector had no pagination and the production data set was 40 times larger than the test set. The target system timed out, IIQ marked the task partial, and the identity warehouse slowly drifted.
The fix took a week: add pagination, cap the batch size, add retry with backoff and alert on partial results. The lesson is not “never write a custom connector”. It is “test with production-scale data and treat partial success as a failure until proven otherwise”.
Training Resources
If you want to build the project evidence employers ask for, SkilBrill’s SailPoint IdentityIQ training covers application onboarding, rules, workflows, provisioning and troubleshooting. For the broader IAM context, the IAM training track is a good foundation.
Read next: IIQ architecture, BeanShell examples, and workflow examples.
FAQ
Do I need to be a Java developer to work on SailPoint IIQ?
You need Java fundamentals for BeanShell rules and debugging, but you do not need to be a full-stack Java developer. Object-oriented basics, collections, exceptions and SQL are the practical minimum.
What does a SailPoint IIQ developer do daily?
Typical work includes application configuration, aggregation and correlation fixes, provisioning troubleshooting, rule and workflow changes, certification support and documentation. The mix depends on whether you are on a build or support project.
Is SailPoint IIQ a good career in 2026?
It remains a durable niche in large enterprises, especially BFSI, telecom, pharma and shared-service programmes. Cloud identity is growing faster, but IIQ skills are still hired for complex on-premises estates.
How do I move from support to a developer role?
Own one application change end to end, document the before/after, and get your rule or workflow reviewed by a senior developer. A concrete project story is more persuasive than another certificate.
What salary should a junior IIQ developer expect?
In India in 2026, junior developers with relevant lab or project exposure typically sit around ₹8–14 LPA. Support-only roles can be lower; implementation ownership and connector experience push the band up.
