Native Identity Issue with Web Service Connector

[sita_ram (Sita Ram K)]

Hi everyone,

I’m working with a web service connector and have created an “Create Account” HTTP operation. I’m logging the provisioning plan in the “Before Provisioning” rule, and I’m seeing something strange.

I have two “Native Identity” attributes showing up:

• One (nativeIdentity) within the provisioning plan itself is coming back as NULL.
• The overall log shows a “Native Identity” populated with the sandbox User ID.

LOG:

“BeforeOperation-Logger:provisioningPlan:{args={requester=xx, identityRequestId=xx, source=xx, accessRequestType=GRANT_ACCESS}, identity=xx, accounts=[{op=Create, instance=null, application=xx [source], attributes=[{op=Add, name=application_role_name, value=[xx xx, xx, xx, xx]}, {op=Add, name=security_profile, value=xx}, {op=Add, name=user_first_name, value=xx}, {op=Add, name=user_last_name, value=xx}, {op=Add, name=user_email, value=xx}, {op=Add, name=user_name, value=xx}, {op=Add, name=federated_id, value=xx}, {op=Add, name=user_language, value=English}, {op=Add, name=user_locale, value=en_US}, {op=Add, name=user_timezone, value=America/New_York}, {op=Add, name=security_policy, value=xx}, {op=Add, name=license_type, value=xx}, {op=Add, name=license_qualityqdocs, value=xx}], nativeIdentity=null}]}”,“pipeline”:“1.12.2”,“@timestamp”:“2024-09-30T03:41:01.850Z”,“NativeIdentity”:“xx”,

My account schema is set up like this:

• username mapped to Account Name
• id mapped to Account ID

My question is:

Is there a specific “Native Identity” attribute that I should be mapping for provisioning in this scenario? Why am I seeing the discrepancy between the provisioning plan and the overall log?

Any help would be greatly appreciated!

Thanks,

[margocbain (Margo Bain)]

Hi Sita,
In your body for your Create operation, you can reference the native identity using $plan.nativeIdentity$ .
e.g., {"UserID": "$plan.nativeIdentity$" ....}

[jade-townsend]

Hi there, would you be able to share your rule?

[udayputta]

Hi @sita_ram, Since it is a create account operation i would expect account nativity identity to be blank because since the account is not created native identity will not be there. I hope you are using create account profile and you are able to pass the values in body. Are you facing any challenges in creating account. Validate once if you are able to pass the values from create account profile using this script.

Sample if you have firstName in create profile and you need to pass it while creating account.

"firstName": "$plan.firstName$"

[sita_ram (Sita Ram K)]

@udayputta

I’m seeing that $plan.nativeIdentity as null both in the “Create Account” plan and in my “Add Entitlement” operation afterwards. So, technically it won’t work in “Create Account” plan, but it should work in “Add Entitlement” plan. Is this correct understanding?

[udayputta]

Yes that is correct. In Add Entitlement just use “$plan.nativeIdentity$” to get that account native identity it will work.

[bcariaga (Braden Cariaga)]

As stated, the expectation is that the native identity shouldn’t exist during the create account. You should have a native identity in the add entitlement.

What does your response mapping look like for the create account? If you are not mapping the id attribute in the response of the create, the add entitlement will still fire off, but will not have the attribute value to supply.

If your create account does not return an account id, check out this post for options to handle such case: Webservice Connector - Create Account Operation - Empty Response

[sita_ram (Sita Ram K)]

So here is my account schema:

Here is my Account Aggregation response mapping:

Here is how I want to use it in my “Add Entitlement” operation:

When I use it here, it is coming as null.

[bcariaga (Braden Cariaga)]

I see your response mapping is configured correctly. After the account creation, are you able to see that the Account ID is populated on the account?

[udayputta]

This looks good you should be able to add the group.

[sita_ram (Sita Ram K)]

yes, Account ID is populated on the account. But The “Add entitlements” API call fails because the “user__v” attribute value is not populated in the request body, because the native Identity is coming as null.

[bcariaga (Braden Cariaga)]

This should work as you have put it with the Form Data, but can you give it a try as a raw JSON?

{
    "user__v": "$plan.nativeIdentity$",
    "blinding__c": "blinded__v",
    "status__v": "active__v"
}

[udayputta]

Can you put your context url for add entitlement?

[jrossicare (Jason Ross)]

Hi Sita

Just create a dummy attribute to use instead of nativeIdentity, then configure that dummy attribute in the provisioning plans so that its value is set to the identity attribute

$plan.dummyAttribute$

GET /beta/sources/<id>/provisioning-policies
[
    {
        "name": "MYSOURCE_CREATE_PP",
        "description": null,
        "usageType": "CREATE",
        "fields": [
            {
                "name": "dummyAttribute",
                "transform": {
                    "type": "identityAttribute",
                    "attributes": {
                        "name": "email"
                    }
                },
                "attributes": {},
                "isRequired": false,
                "type": "string",
                "isMultiValued": false
            },