SailPoint IIQ Web Service Connector: Stop the Unwanted “Add Entitlement” After Create

You create an account via your Web Service connector and (by design) you already send the entitlement in the create payload. Smooth. Then IIQ helpfully fires a second call: Add Entitlement. Not needed. Not welcome. Let’s turn that off.

Scenario

• Operations implemented: Create account, Add entitlement, Remove entitlement, Account aggregation, Update account.
• During Create, your JSON body already includes the entitlements to attach to the new account.
• After Create succeeds, IIQ auto-queues Add Entitlement… which duplicates work (and sometimes fails or spams your target API).

Why It Happens

By default, IIQ treats “account create” and “entitlement grant” as separate provisioning steps. Many targets require two calls. In our case, the target API supports create + entitlements in a single request—so the follow-up grant is redundant.

The Fix (One Setting)

Enable single-request add/remove behavior on the Application object:

<entry key="createAccountWithEntReq">
  <value>
    <boolean>true</boolean>
  </value>
</entry>

Result: When you send entitlements in the Create payload, IIQ won’t auto-trigger the Add Entitlement operation afterward.

How to Set It (Debug UI)

• Go to Debug → Browse.
• Select object type Application and open your Web Service application.
• Find (or add) attribute createAccountWithEntReq and set it to true.
• Save.

Payload Pattern (Example)

Make sure your create body truly contains the entitlements the target expects:

{
  "user": {
    "username": "jsmith",
    "givenName": "John",
    "familyName": "Smith",
    "email": "jsmith@example.com"
  },
  "entitlements": [
    { "type": "group", "value": "FINANCE_READ" },
    { "type": "role",  "value": "AP_INVOICE_APPROVER" }
  ]
}

If your target uses a different schema (e.g., groups, roles, scopes), map accordingly in your connector’s Create template.

Validation Checklist

• Before: Create → followed by an automatic Add Entitlement call.
• After: Create only. The account appears with the requested entitlements, no second call fired.
• Confirm by checking target system audit logs and IIQ Provisioning Transaction history.

Notes & Gotchas

• Target must support it: The API has to accept entitlements during account creation; otherwise, keep the default two-step behavior.
• Provisioning Plan mapping: Ensure your Create operation template maps IIQ entitlements to the correct JSON fields; otherwise, nothing will be granted.
• Mixed-mode scenarios: If some entitlements can’t be added at create-time (e.g., async approvals on target), those specific grants may still require a separate call.
• Rollbacks: If Create fails mid-way, confirm the target leaves no partial grants; handle cleanup in your error path.

TL;DR

Set createAccountWithEntReq=true on the Application. Send entitlements in the Create payload. IIQ won’t auto-call Add Entitlement afterward. Cleaner logs, fewer API calls, and no duplicate grants.

Seen this behavior in the wild? Did the single-request setting save you from noisy double-calls? Drop your experience below—curious how different APIs handle this pattern.