Web Services Configuration Variables

mike.lim · May 29, 2025, 7:34am

I’m currently configuring “Add Entitlement” HTTP operation to add a user to a group.
To do this, I need to use the PATCH method with the following URL format: https://example.com/Groups/id ← this ID is from the entitlement.

I’ve configured the response mapping for entitlement aggregation as shown in the image below, and ID is configured as Entitlement ID on entitlement types page.

For the request body, the format needs to be:

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "add",
      "path": "members",
      "value": [
        {
          "value": "id" <-- this ID is from the account.
        }
      ]
    }
  ]
}

I’ve configured the response mapping for account aggregation as shown in the image below, and ID is not configured as Account ID on account schema page.

How can I correctly configure the use of variables so that:

The id in the URL is pulled from the entitlement, and
The id in the body is pulled from the account?

sidharth_tarlapally · May 29, 2025, 8:07am

Hi @mike.lim,

Could you please clarify what the entitlement attribute represents in the account schema?
Also, what does the accountID attribute refer to in the same context?

Just a reminder — only attributes marked as ID (such as Entitlement ID and Account ID) can be used in the request body.

Assuming the following on the Account Schema :
Account ID attribute - ID
Entitlement Attribute - Groups

URL should be : https://example.com/Groups/$plan.groups$

$plan.groups$ Is the value which is mapped as Entitlement ID .

Body Should be :

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "add",
      "path": "members",
      "value": [
        {
          "value": "$plan.nativeIdentity$" <-- this ID is from the account.
        }
      ]
    }
  ]
}

Hope this gives you an Idea !

Thanks
Sid

mike.lim · May 29, 2025, 8:27am

Entitlement attribute on account schema page is shown in the image below - this is the ID of the group, which is the same ID that needs to be used in the URL.

Account ID is configured as Username, which is a different attribute - not the same ID required in the request body.

Given this, should I change Account ID mapping from Username to ID so that I can use the variable in the request body?

sidharth_tarlapally · May 29, 2025, 8:41am

Yes. use account name for username and account Id for id

mike.lim · May 30, 2025, 3:18am

I followed your guide, and it appears that $plan.nativeIdentity$ is working as expected.
However, $plan.groups$, which needs to be part of the request URL, is not working as expected - the error message indicates that the ID is missing from the URL:

Provisioning
Exception while updating account.Url: https://example.com/Groups/, Message: 405

I need to be able to include the ID shown in the image below as part of the request URL. This ID is set as Entitlement ID in the configuration.

Would using $plan.entitlement$ instead resolve this issue?

sidharth_tarlapally · May 30, 2025, 3:30am

@mike.lim
Sorry , I overlooked. Try
$plan.Group ID$

mike.lim · May 30, 2025, 7:06am

Thank you so much for your help.
Using $plan.Group ID$ in the URL resolved the issue!

Now, I’m working on configuring the “Update Account” HTTP operation using PUT method with the following URL format:

https://example.com/Users/$plan.nativeIdentity$

The account schema attributes I’ve configured are:

ID (Account ID), Username, Type, Family Name, Given Name, Email, Display Name (Account Name)

The request body is structured as follows:

{
	"emails": [
		{
			"primary" : true,
			"value": "$plan.Email$"
		}
	],

	"active": true,
	"userType" : "employee",
	"name": {
		"givenName": "$plan.Given Name$",
		"familyName": "$plan.Family Name$"
	},
	"displayName" : "$plan.Display Name$",
	"userName": "$plan.Username$",
	"schemas": [
		"urn:ietf:params:scim:schemas:core:2.0:User",
		"urn:ietf:params:scim:schemas:extension:sap:2.0:User"
	]
}

This works when the values (variables in the body) are hardcoded (e.g., using [email protected] instead of $plan.Email$), but fails when I use variables.

Could you please advise if I’m referencing these variables incorrectly?

sidharth_tarlapally · May 30, 2025, 7:08am

@mike.lim

Configured this section ?

mike.lim · May 30, 2025, 7:21am

Yes, I’ve configured the following account attributes for Create Account:

Display Name, Family Name, Given Name, Email, Username

I’ve already tested the “Create Account” operation, and it completed successfully.
However, “Update Account” operation is not working as expected.

sidharth_tarlapally · May 30, 2025, 7:55am

Could you please clarify when this operation is typically used?
What is the purpose of the “Update Account Attributes” operation — are we syncing identity attributes to account attributes in this case?

Also, how are you currently testing this operation?

mike.lim · May 30, 2025, 8:10am

“Update Account” operation would be used for synchronizing attributes as you mentioned.

The API used for “Update Account” operation is the same as the one used for “Disable Account” and “Enable Account” operations - the only difference is the modification of the “Active” status in the request body.
So I’ve been testing this by attempting to enable/disable the account, but the operation is failing.

Below is the error message I’m receiving:

There was an error trying to disable the account

Exception occurred while performing ‘Disable’ operation on identity ‘example-account-id’: Error: Error disabling user for native identity example-account-id.Url:
https://example.com/Users/example-account-id, Message: 400 : Bad Request : {“schemas”: [“urn:ietf:params:scim:api:messages:2.0:Error”],“status”:“400”,“detail”:“Missing required creator property ‘userName’ (index 4)”}, HTTP Error Code: 400