Web Services SaaS: provisioning not enabled and Create Unique Account ID pattern not working

shsakshi · April 27, 2026, 8:04am

I’m configuring a web-services-saas source for account creation and facing 2 issues.

In the source JSON, features only show:
[
“MACHINE_IDENTITY_AGGREGATION”,
“UNLOCK”,
“AUTHENTICATE”
]
It does not include PROVISIONING or ENABLE, and I do not see any Enable Provisioning option in Base Configuration.

Question:

How can I enable provisioning for this source?

For accountId, when I use:

Generator
Create Unique Account ID
Pattern: PB_USR_${uniqueCounter}

Provisioning is triggered but fails with:

Unable to generate a unique value for 'aman.bhojak'...
Response status :404 doesn't match to allowed success codes : 200,2**,2**
message":"Account not found for accountId: PB_USR_${uniqueCounter}"

It looks like SailPoint is sending PB_USR_${uniqueCounter} literally instead of generating a real value.

But when I change accountId to:

Identity Attribute → Username

Then, no API provisioning happens, and a manual task is generated.

Questions:

Is the manual task happening because PROVISIONING is missing from the source features?
Does Create Unique Account ID support patterns like PB_USR_${uniqueCounter}?
Do I need a Cloud Rule to generate something like PB_USR_?

baoussounda · April 27, 2026, 8:37am

@shsakshi

Regarding generation of account Id, you can use the usernamegenerator transform : Username Generator | SailPoint Developer Community

{
  "name": "accountId",
  "transform": {
    "type": "usernameGenerator",
    "attributes": {
      "sourceCheck": false,
      "patterns": ["PB_USR_${uniqueCounter}"]
    }
  },
  "attributes": {
    "cloudMaxSize": "100",
    "cloudMaxUniqueChecks": "10",
    "cloudRequired": "true"
  },
  "isRequired": false,
  "type": "string",
  "isMultiValued": false
}

It simple to add this by using vscode plugin or API in your Create Account provisioning policy

Regarding the provisioning feature, it is generally enabled by adding the PROVISIONING feature to the source’s features parameter.

For example:

From:

To :

If provisioning is not enabled, manual tasks are generally created instead.

However, for the Web Services connector specifically, I am not sure whether you only need to define operations or if additional configuration is required for enabling provisioning.

You should test the behavior both with and without the PROVISIONING feature enabled to confirm the expected behavior.

punna0001 · April 27, 2026, 8:56am

The problem is with the Create Unique Account ID generator.

How it works: When you use a pattern like PB_USR_${uniqueCounter}, ISC:

Generates a value (e.g., PB_USR_1)
Calls GET ACCOUNT to check if it exists
If not found → treats it as unique → uses it
If found → increments and retries (PB_USR_2, etc.)

In your case:

ISC generates: PB_USR_1
Calls GET ACCOUNT with ID: PB_USR_1
Target returns: 404 (not found)
ISC treats 404 as failure → stops generator

Result: generator never completes and the literal value PB_USR_${uniqueCounter} is sent in the request.

Fix:

Update your GET ACCOUNT operation and include 404 in allowed success codes:

200,2**,404

(or explicitly: 200,201,204,404)

For GET ACCOUNT, 404 = account not found. That’s expected during uniqueness checks & needs to be treated as success. Once you allow 404, the generator will resolve ${uniqueCounter} correctly.

The missing PROVISIONING feature in the source JSON is expected for Web Services SaaS. Provisioning is driven by account operations + Create Profile, not that flag.

Hope this helps

punna0001 · April 27, 2026, 9:15am

Yeah, @baoussounda , the usernameGenerator approach with sourceCheck: false is a solid alternative. It skips the GET ACCOUNT call and checks uniqueness within ISC.

Both approaches can work. It really depends on how you want uniqueness enforced:

The 404 handling approach keeps the check against the target system
The transform approach validates uniqueness only within ISC

In your case, since GET ACCOUNT is already part of the flow, updating the 404 handling seems like the better fit. It keeps your current setup intact while still validating uniqueness against the target system.

Give both a try & see what fits your setup best.

shsakshi · April 27, 2026, 9:32am

Hi @punna0001

I updated the success codes as suggested, but I’m still seeing an issue during account creation and I’m not clear on what exactly needs to be fixed in the response configuration.

Unable to generate a unique value for 'iruma.sama', action UniqueAccountIdValidator[nativeIdentity=PB_USR_${uniqueCounter},app=Permission Bridge] is not retry-able due to ConnectorException: [ConnectorError] Incorrect response confguration. Please add the correct configuration for response object. (requestId: 031b3f824c66494dab3fbce4f72e2dc6)

Current Setup:

Account Schema
- accountId
- identityId
- entitlementValue
- username
- email
- Account Type

My current GET OBJECT configuration is:

Method: GET
Context URL pattern: /…/accounts/$getObject.nativeIdentity$
Headers: Accept and Content-Type as application/json
Root Path: account
Success Codes: 200, 201, 204, 404

Current Response Mapping: [Schema Attribute → Attribute Path]

accountId → accountId
identityId → identityId
entitlementValue → entitlements
userName → userName
Account Type → accountType
email → email

Can you help me with:

What is incorrect in this Get Object response configuration?
Is something missing in the Root Path or Response Mapping setup?
When 404 is returned, there is no account object in the response.
Since Root Path is set to account, could that be the reason the connector is unable to parse the response correctly?

punna0001 · April 27, 2026, 10:05am

Yes, it looks like the issue has now moved from success codes to the GET OBJECT response configuration.

Adding 404 was the right step. But for successful calls (200), the connector still needs to parse the response, & that seems to be where it is failing now.

Your current setup:

Root Path: account

This means ISC expects the response to have an account object. When 404 comes back (no body), the connector still tries to resolve that path and fails, which is why you see “Incorrect response configuration”.

Before changing anything, I would check what the actual GET OBJECT response looks like in Postman for a valid account (when 200 comes back).

Two possible cases:

Case 1, if the response looks like this:

{
  "account": {
    "accountId": "PB_USR_1",
    "userName": "abc"
  }
}

Then keeping Root Path = account should be correct.

Case 2, if the response looks like this:

{
  "accountId": "PB_USR_1",
  "userName": "abc"
}

Then using Root Path = $ would be the right option.

"The Root Path must be common for all the attributes mentioned in the Response Attribute Mapping for a particular operation" & "the default value for root path is $". So Root Path should match the actual response structure for 200 responses, not just be changed to handle the 404 case.

Reference: https://documentation.sailpoint.com/connectors/saas/web_services/help/saas_connectivity/web_services/response_information.html

Once that lines up, the error should go away & the generator should complete.

Plz give this a try & see if it helps.

shsakshi · April 27, 2026, 10:57am

Hi @punna0001

The valid response will look like:

{
  "operation": "GET_ACCOUNT",
  "status": "SUCCESS",
  "message": "Account fetched from demo connected app.",
  "timestamp": "2026-04-27T10:33:41.116923200Z",
  "account": {
    "accountId": "PB_USR_1001",
    "identityId": "iruma.sama",
    "userName": "iruma.sama",
    "email": "iruma.sama@example.com",
    "accountType": "User Account",
    "status": "ACTIVE",
    "createdAt": "2026-04-27T10:33:40.936394700Z",
    "updatedAt": "2026-04-27T10:33:40.936394700Z",
    "entitlements": ["PB_ACCESS_SUPERVISOR", "PB_REQUEST_APPROVER"]
  }
}

I removed the Root Path = account and performed the Provisioning.

Note: Currently, I have no accounts in this specific

Now facing a different issue:


Error:
Request failed
An unexpected error occurred: org.apache.bsf.BSFException: The application script threw an exception: java.lang.IllegalStateException: Unable to find unique account ID after incrementing 50 on accountID = PB_USR_${uniqueCounter} BSF info: Create Unique Account ID at line: 0 column: columnNo
SHOW LESS

When I tried following the pattern: PB_USR_${userName}

A manual task was raised

Question:

How can I resolve this issue? Is there any simpler or recommended approach for this use case?
I need to provision the account and assign entitlements successfully during provisioning.
Or is there any supported pattern using a timestamp to generate a unique account ID?

punna0001 · April 27, 2026, 11:56am

Good to hear provisioning is executing now.

This error means the generator hit its retry limit without finding a unique value. cloudMaxUniqueChecks has a max allowed value of 50, so retries are limited. A few things worth checking:

1. Root Path and mapping alignment: You mentioned you removed Root Path = account, but your current mappings are still:

accountId → accountId
identityId → identityId
userName → userName
email → email

Since your response wraps everything inside an account object, the cleanest fix is to put: Root Path = account back and keep your existing mappings as-is. If you prefer to keep Root Path removed (or use $), then mappings need to reference the full path:

accountId → account.accountId
identityId → account.identityId
userName → account.userName
email → account.email

If Root Path and mappings don’t align, the connector won’t parse the 200 response correctly, which can break the uniqueness check.

2. Counter syntax: Your error still shows: PB_USR_${uniqueCounter}

For the Create Profile UI generator (Create Unique Account ID), use: $(uniqueCounter). If you’re using the UI generator, try: PB_USR_$(uniqueCounter)

For usernameGenerator transform: ${uniqueCounter}

Reference: https://documentation.sailpoint.com/saas/help/provisioning/create_profile.html

3. GET OBJECT behavior for missing accounts

You mentioned there are no accounts in this environment. In that case, PB_USR_1 should be accepted on the first attempt. Since it’s failing after 50 retries, likely causes are:

GET OBJECT is not returning a clean 404 for missing accounts
Or response parsing is failing due to the Root Path/mapping issue above

Test in Postman with a non-existing value like: PB_USR_99999

Expected: HTTP 404. If it returns 200 with empty or null data, ISC may treat it as “exists”.

Your sample shows PB_USR_1001. If your target uses higher ranges, a counter based generator will struggle because of the 50 retry limit. Starting from PB_USR_1, it won’t reach higher ranges.

That’s why UUID or target generated IDs are usually more reliable for this pattern.

On timestamp IDs, the Create Unique Account ID generator supports only counter based patterns per docs. For timestamp or UUID style values, a transform based approach is cleaner.

please give this a try & see if it helps.

punna0001 · April 27, 2026, 12:41pm

For a simpler approach, if ISC must generate the IDs, you can try using the transform approach suggested by @baoussounda using the usernameGenerator transform with sourceCheck: false.

This skips the GET OBJECT call and checks uniqueness only within ISC. This works well if ISC is the only system creating these accounts.

shsakshi · April 28, 2026, 10:11am

Hi @punna0001

I updated the UI generator value to PB_USR_$(uniqueCounter), but still there is an error:

Error: Please contact your administrator
Request failed
An unexpected error occurred: org.apache.bsf.BSFException: The application script threw an exception: java.lang.IllegalStateException: Unable to find unique account ID after incrementing 50 on accountID = PB_USR_50 BSF info: Create Unique Account ID at line: 0 column: columnNo

Could you please share a simple example for UUID-based or target-generated IDs, including where to configure them and how to set them up?

I’m also not clear on what you mean by “ISC must generate the IDs” and how to use the transform approach for that. Please share one simple and easy way to do this.

I tried these options for accountId mapping, and a manual task is raised for all of them instead of account provisioning:

Identity Attribute
Static
Disabled
Generator → Create Unique Account ID

Also, in Generator → Create Unique Account ID, if I remove ${uniqueCounter} or $(uniqueCounter), a manual task is raised there as well.

So I’m not clear what the correct configuration should be for this case.

Tried both create and lookup from Postman.

Create Account worked successfully and returned 200 OK with the account created:

Body Input:

{
    "accountId": "PB_USR_01",
    "entitlementValue": "PB_ACCESS_SUPERVISOR",
    "identityId": "sakshi.sharma",
    "userName": "sakshi.sharma",
    "email": "sakshi.sharma@example.com",
    "accountType": "User"
  }

Response:

{
    "operation": "CREATE_ACCOUNT",
    "status": "SUCCESS",
    "message": "Account created or updated for demo connected app.",
    "timestamp": "2026-04-28T09:02:08.087589336Z",
    "account": {
        "accountId": "PB_USR_01",
        "identityId": "sakshi.sharma",
        "userName": "sakshi.sharma",
        "email": "sakshi.sharma@example.com",
        "accountType": "User",
        "status": "ACTIVE",
        "createdAt": "2026-04-28T09:02:08.087536050Z",
        "updatedAt": "2026-04-28T09:02:08.087536050Z",
        "entitlements": [
            "PB_ACCESS_SUPERVISOR"
        ]
    }
}

Get Object

When an account exists

Response Code: 200 Success

{
    "operation": "GET_ACCOUNT",
    "status": "SUCCESS",
    "message": "Account fetched from demo connected app.",
    "timestamp": "2026-04-28T09:58:46.448610316Z",
    "account": {
        "accountId": "PB_USR_01",
        "identityId": "sakshi.sharma",
        "userName": "sakshi.sharma",
        "email": "sakshi.sharma@example.com",
        "accountType": "User",
        "status": "ACTIVE",
        "createdAt": "2026-04-28T09:02:08.087536050Z",
        "updatedAt": "2026-04-28T09:02:08.087536050Z",
        "entitlements": [
            "PB_ACCESS_SUPERVISOR"
        ]
    }
}

When an account does not exist

Response Code: 404 Not Found

{
    "operation": "GET_ACCOUNT",
    "status": "FAILED",
    "message": "Account not found for accountId: PB_USR_99999",
    "timestamp": "2026-04-28T09:06:06.312090789Z",
    "account": null
}

baoussounda · April 28, 2026, 4:51pm

Have you added the “PROVISIONING” feature as well ?

punna0001 · May 6, 2026, 9:37am

If the 404 uniqueness check is still failing & ISC is the source of truth, the cleaner workaround is to stop using the UI “Create Unique Account ID” generator and define a usernameGenerator directly on the accountId field in the Create Account provisioning policy.

This uses sourceCheck: false, so ISC checks uniqueness only against accounts already aggregated into ISC instead of calling GET ACCOUNT on the target for every generated value.

Steps:

In the UI, remove the current “Create Unique Account ID” generator from accountId and save.
Get the source ID: GET /v2026/sources.
GET /v2026/sources/{sourceId}/provisioning-policies/CREATE.
Copy the full response.
In the fields array, find the accountId field and replace only that field with:

{
  "name": "accountId",
  "transform": {
    "type": "usernameGenerator",
    "attributes": {
      "sourceCheck": false,
      "patterns": [
        "PB_USR_$uniqueCounter"
      ]
    }
  },
  "attributes": {
    "cloudMaxSize": "100",
    "cloudMaxUniqueChecks": "50",
    "cloudRequired": "true"
  },
  "isRequired": true,
  "type": "string",
  "isMultiValued": false
}

PUT the full provisioning policy JSON back to: PUT /v2026/sources/{sourceId}/provisioning-policies/CREATE Do not send only the accountId field. Send the full policy response with only accountId changed.
Open the Create Account operation and confirm the request body sends accountId to the target API.
Trigger a new create from ISC.

Expected result:

ISC will generate PB_USR_1, PB_USR_2, PB_USR_3, and so on, without calling GET ACCOUNT for every candidate.

Important notes:

Use $uniqueCounter, not $(uniqueCounter) or ${uniqueCounter}.
sourceCheck: false is only safe if ISC knows all existing PB_USR accounts through aggregation.

Username Generator docs | Provisioning Policy API

shsakshi · May 7, 2026, 4:11am

Hi @punna0001

Thanks for the guidance; it worked

Topic		Replies	Views
Create Account IntraID failed ISC Discussion and Questions identity-security-cloud , provisioning , connectors	17	215	May 19, 2025
Webservice VA connector account creation ISC Discussion and Questions webservice-connector , apis , identity-security-cloud , provisioning	16	189	November 11, 2024
Create Policy - Create Unique Account ID Generator ISC Discussion and Questions identity-security-cloud , provisioning	4	367	June 7, 2025
Usernamegeneration ISC Discussion and Questions transforms , identity-security-cloud , provisioning	20	535	September 14, 2024
usernameGenerator ISC Discussion and Questions identity-security-cloud , provisioning	3	45	April 2, 2026

Web Services SaaS: provisioning not enabled and Create Unique Account ID pattern not working

Related topics