Invite User Limitations

There are known limitations with the automated user invitations to register user’s access to SailPoint:

• When initially turned on, an email will be sent to all active users that have not registered yet (not just those that have changed LCS)
• Those will expire after seven days and another invitation will be sent

We are looking to send invitations only to new accounts (so that users can change their initial generated password), Are there any options to send the invitation to only new users?

One thought we had was to use Event Triggers to invoke the invite users API (cc/api/user/invite) but the invitation needs to go to their personal email. Is this possible using the API and, if so, what body needs to be provided to send it to their personal email?

1 Like

Hi @justinrhaines,

I see two courses of action here. One is to submit an idea to ideas.sailpoint.com so our product team is aware of this issue and can build native support for inviting new users directly into the UI.

The second course of action is to fulfill your immediate need with our triggers and APIs. Are you thinking about using the identity created trigger to listen for new users? If so, then your authoritative source will need to have an attribute mapped for personal email address so you can get it from the trigger response.

1 Like

Yes, we will use the Identity Created trigger but because I can’t find any documentation on /cc/api/user/invite API, I am not sure what needs to be passed in order to send it to the personal email, which will be mapped in the new users’ identities.

1 Like

Yes, the /cc API isn’t documented as it is meant for internal use only. However, there is no equivalent public API for inviting users, so we have to use it for now. I went ahead and created an idea in our developer ideas portal at https://developer-sailpoint.ideas.aha.io/ideas/API-I-11. Please give it an upvote when you get a chance.

Unfortunately, I don’t think it’s possible to send an invite to a new identity’s personal/alternate email address via the API. When you trigger a manual invite, either via the UI or the API, it only sends to the primary email address.

That being said, I was able to reverse engineer what the IDN UI is doing to invite users by using my browser inspector and inspecting the API call it makes. /cc/api/users/invite takes a form-data request body. Here’s some example code in a couple of languages so you can see how to do it:

curl

curl --location --request POST 'https://{org}.api.identitynow.com/cc/api/user/invite' \
--header 'Authorization: Bearer {your access token}' \
--form 'ids="1797782"' \
--form 'ids="1675056"'

python

import requests

url = "https://{org}.api.identitynow.com/cc/api/user/invite"

payload={'ids': '1797782',
'ids': '1675056'}

files=[

]

headers = {
  'Authorization': 'Bearer {your access token}'
}

response = requests.request("POST", url, headers=headers, data=payload, files=files)

print(response.text)

You’ll notice that the user IDs you provide in the request body aren’t the same IDs you will receive from the Identity Created event trigger. In order to convert the ID from the event trigger into something /cc/api/users/invite will understand you need to use the following request:

GET /cc/api/user/list

This will return a body like this:

{
    "total": 11,
    "items": [
        {
            "id": "201783",
            "name": "John Doe",
            "displayName": "john.doe",
            "alias": "john.doe",
            "email": "john.doe@sailpoint.com",
            "status": "ACTIVE",
            "enabled": true,
            "pending": false,
            "externalId": "2c91808375c8e80a01b5e1f38a575221",
            "processingDetails": null
        },
        {
            "id": "201766",
            "name": "Jane Gray",
            "displayName": "jane.gray",
            "alias": "jane.gray",
            "email": "jane.gray@sailpoint.com",
            "status": "UNREGISTERED",
            "enabled": true,
            "pending": false,
            "externalId": "2c01808475b4334aa875e1e004d463ff",
            "processingDetails": null
        },
        ...
    ]
}

If you have more than 250 users (the max number of users per API call), you will have to use pagination to get the full list. For example GET /cc/api/user/list?start=0&limit=250 will return the first 250 users, and /cc/api/user/list?start=1&limit=250 will return the next 250 users.

To put it all together, you will need to monitor the Identity Created event trigger for new users joining your organization. For each event you receive, you will need to compare the ID from the event to the externalId from /cc/api/user/list until you find a match, paginating through the results if necessary. Once you find a match, get the short id and use that in your request body to /cc/api/user/invite.

However, this will only send to the primary email address. Please upvote the idea I created so we can have our product team address this issue.

Thanks @colin.mckibben , I did create the Idea last night as well. Because we cannot send the invitation registration to the private email address, this negates the usefulness of using the password generator because we don’t want to send invitations to existing users using their personal email addresses and new users cannot access their work email until they reset their password.

We are going to try a workaround using the Identity Created event trigger and have a third-party application send the username to the user.

Thanks!

hey Justin,
The assumption you made here is wrong:
When initially turned on, an email will be sent to all active users that have not registered yet (not just those that have changed LCS)

Check the documentation here:

Inviting Users Automatically

If you choose an automatic invitation option, an email invitation to register with IdentityNow will be sent automatically whenever a source aggregation adds a new user to the identity profile.

If you also select a specific lifecycle state, the invitation will be sent after the user enters that particular lifecycle state, only. Invitations will not be sent to identities that are already in that state at the time you save this invitation option.

Hi @chirag.patel, we have reviewed this documentation and our expectation was that the system would function as you noted, but in our experience with several different clients it does not. We have opened tickets with ES on this and they confirmed that it is not working as documented.

Thanks!

That’s interesting, I had one client in past which wanted to send email also for existing users who are active and they wrote script for those users because IdentityNow was not sending invite emails for them :thinking:.

We are going to handle this using the New Account Provisioned enablement API which allows us to send a copy of the message to the Personal Email address.

Hey @justinrhaines ,

Do you happen to have information for that new api you can share?

-Tbui

Hi Thomas–

2 Likes