Updating a user's email in ShotGrid : behind the scenes with Autodesk Identity

This is an often recurring situation : the email of a someone needs to be updated.

That seems simple enough… unfortunately if your first reflex is to update the value in ShotGrid, please do not.

The proper way to phrase the situation is : the email of the existing Autodesk Identity user needs to be updated.

With Autodesk Identity, the ShotGrid user is actually bound to a specific Identity account. That link is in the form of a non-mutable ID recorded in ShotGrid that maps to the Autodesk Identity account. That account is the authoritative source for the email and name. What is shown in ShotGrid is the information from the bound user.

When an Autodesk Identity user needs to have their email modified, there are 2 possible paths to achieve that:

  • if the user is on a SSO-using domain, the email change needs to be done on that side (in Active Directory or whatever system is used by the IdP). To save that change in Autodesk Identity, the user MUST log-out of Identity and log back in again. The IdP changes are propagated to Identity at login time.
  • if SSO is not used, then the user must update their email on profile.autodesk.com. That will generate an email with a link for them to confirm their new address.

In both cases, once the email update is saved in Autodesk Identity, the user’s email in ShotGrid will be updated automatically:

  • for sites bound to a subscription, this will happen within a few seconds/minutes after the change,
  • for Eval and Educational sites, this will happen when the user signs-in in ShotGrid.

And now, you may ask: but why can’t I just update the ShotGrid user’s email ?

Before getting to the answer, two important details:

  • at any given time, only one email can only be associated to one Autodesk Identity account (and vice-versa).
  • the act of enabling (or inviting) a user in ShotGrid will do a lookup in Identity using the email and will automatically create a user for them if that email is not yet bound. The ShotGrid user will then be linked to that account.

By updating the email in ShotGrid you may end up creating a new Autodesk Identity user bound to that email.

That new (and undesired) user will effectively block the email change meant for the original user.

As things currently stands, should you unfortunately encounter this problem, the only solution is to open a support ticket. And because this issue is at the level of Autodesk Identity, the ShotGrid support team cannot fix this and need to escalate that issue up to the Identity team.

The only moment when it is safe for you to edit a user’s email in ShotGrid is if you invited the wrong person or used a non-existent email. That is usually the case when there was a typo in the email entered initially.

One example of a case where it is definitely NOT correct to fix the email in ShotGrid :

  • a new employee is hired, but their user is created with the wrong email in the company’s systems
  • the mistake goes un-noticed until the employee’s first day,
  • at that point, the Autodesk Identity user has been created with the incorrect email, and the ShotGrid user shows that incorrect email,

If that happens, the SSO/non-SSO guidelines stated at the beginning of the message must be followed.

We are looking at ways to make the update/fix email process clearer. We realize that the current implementation needs to be improved.

Hopefully sheds some light on the behind the scenes side of things,



Thanks for the explanation, Patrick! We recently got burned by this, so having this flowchart to follow when making corrections to user details is good to have.

While the team is looking into ways to make the process clearer, could some sort of more verbose messaging for errors/warnings be put in place? Either when trying to make an update directly in SG and getting a warning, or at the Identity error page having more details about why they aren’t being allowed to log in (e.g. theres some sort of mismatch). That could help cut down on support having to deal with this situation if users can self-serve or catch themselves before making a change that’ll put the user in a bad state.


FYI @brandon.foster , Jira SG-26099 has been created, related to the improvements needed for this situation.