Announcing the Saviynt Knowledge Exchange unifying the Saviynt forums, documentation, training,
and more in a single search tool across platforms. Read the announcement here.

Saviynt creating 2 manually provisioned account when provisioning new account REST connector

Robbe_Cronos
Regular Contributor II
Regular Contributor II

Hello,

We have noticed a problem when provisioning a new account to our gitlab-DEV environment through Saviynt. 

When we make a new account request through the ARS, approve the task and run the provisioning job, a new account is created in Saviynt with status "manually provisioned" (Screenshot).

Robbe_Cronos_1-1664438339241.png

When we then run the import accounts job for our gitlab-DEV environment, another account is created in Saviynt with status "active". This second account is the one we want to have, but the first one isn't supposed to be automatically created (Screenshot).

Robbe_Cronos_2-1664438353489.png

How can we make sure Saviynt does not automatically create the manually provisioned account?

7 REPLIES 7

rushikeshvartak
All-Star
All-Star

Reason is accountid of both account might not be same. Account must be provisioned but with blank accountid

Share create account & import mapping json


Regards,
Rushikesh Vartak
If you find the response useful, kindly consider selecting Accept As Solution and clicking on the kudos button.

Thank you for the reply.  I don't really understand what you mean by "with blank accountkey" seeing as the accountkey is the Primary key. 

Here is our createAccountJSON:

 

{
    "accountIdPath": "call1.response.id",
    "responseColsToPropsMap": {
      "displayname": "call1.response.username~#~char",
      "name": "call1.response.username~#~char"
    },
    "call": [
      {
        "name": "call1",
        "connection": "acctAuth",
        "showResponse": true,
        "url": "https://URL/api/v4/users",
        "httpMethod": "POST",
        "httpParams": "{\"email\": \"${user.email}\", \"name\": \"${user.firstname}\", \"username\": \"${user.username}\", \"force_random_password\": \"true\"}",
        "httpHeaders": {
          "Authorization": "${access_token}",
          "Accept": "application/json",
        },
        "httpContentType": "application/json"
      }
    ]
}
 
ImportMappingJSON:
"accountParams": {
    "connection": "acctAuth",
    "processingType": "SequentialAndIterative",
    "call": {
      "call1": {
        "callOrder": 0,
        "stageNumber": 0,
        "http": {
          "url": "https://URL/api/v4/users",
          "httpHeaders": {
            "Authorization": "${access_token}",
            "Accept": "application/json"
          },
          "httpContentType": "application/json",
          "httpMethod": "GET"
        },
        "listField": "",
        "keyField": "accountID",
        "colsToPropsMap": {
          "accountID": "id~#~char",
          "name": "username~#~char",
          "status": "state~#~char",
          "customproperty2": "email~#~char",
          "customproperty3": "created_at~#~char"
        },
        "pagination": {
          "nextUrl": {
            "nextUrlPath": "${headers?.link?.split(',').size()==4?headers.link.split(',')[1].replace('<','').replace('>; rel=\"next\"','').trim():(headers?.link?.split(',')?.size()==3 && headers?.link.contains('next'))?headers.link.split(',')[0].replace('<','').replace('>; rel=\"next\"','').trim():null}"
          }
        }
      }
    }
  }
 
Hope you can figure out what we're doing wrong.

Its acountid, can you validate using data analyzer compare both account & their columns


Regards,
Rushikesh Vartak
If you find the response useful, kindly consider selecting Accept As Solution and clicking on the kudos button.

Yes we had already realized that the accountID of both accounts is different (screenshot).

Robbe_Cronos_0-1664536965587.png

Robbe_Cronos_1-1664536991910.png

But we don't know why it is different, as we tell the createAccountJSON to use the ID it gets from the response of our gitlab environment. 

Do you know how we can change it so it makes an account with accountID equal to the accountID we get when creating the account in gitlab-dev?

Update your Create Account JSON

 

{
    "accountIdPath": "call1.response.username",
    "responseColsToPropsMap": {
      "displayname": "call1.response.username~#~char",
      "name": "call1.response.username~#~char"
    },
    "call": [
      {
        "name": "call1",
        "connection": "acctAuth",
        "showResponse": true,
        "url": "https://URL/api/v4/users",
        "httpMethod": "POST",
        "httpParams": "{\"email\": \"${user.email}\", \"name\": \"${user.firstname}\", \"username\": \"${user.username}\", \"force_random_password\": \"true\"}",
        "httpHeaders": {
          "Authorization": "${access_token}",
          "Accept": "application/json",
        },
        "httpContentType": "application/json"
      }
    ]
}

Regards,
Rushikesh Vartak
If you find the response useful, kindly consider selecting Accept As Solution and clicking on the kudos button.

@Robbe_Cronos,

The response you are storing when creating an account seems different from what youre getting when you are importing.

You Provisioning mapping says : 

{
    "accountIdPath": "call1.response.id",
    "responseColsToPropsMap": {
      "displayname""call1.response.username~#~char",
      "name""call1.response.username~#~char"
    }
 
Your Import maping says : "accountID": "id~#~char",
 
Though, in both cases the Saviynt attribute AccountID is mapped to the application value id, we are seeing different behavior.
 
Validate using postman, the responses when you get when you create an account and when you are importing to understand why the values are different.
 
The solution provided by @rushikeshvartak on using the username in accountIdPath should work to resolve this issue.
 
 
 
 
Regards,
Avinash Chhetri

I just noticed i put "call1.response.id" in the accountidPath when the gitlab integration guide says it should be "call1.message.id". 

This fixed the problem we had. Is there any way you could explain why it should be .message and not .response?

Kind regards,

Robbe